cfdisk gives fatal error, should I bother?

relatime · 2013-08-31 13:36:26

I recently checked my disk with cfdisk, and it gives the following error:

# cfdisk -Pt /dev/sda
FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap

However, my everything on my system works well and I've never had a problem mounting any of my partitions.

fdisk seems to be happy too and I cannot find an overlap of /dev/sda6 with any other partition (385865234 < 385867776 and 524472319 < 524474055)

# fdisk -l /dev/sda
Disk /dev/sda: 320.1 GB, 320072933376 bytes, 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x9986ab1b
Device Boot Start End Blocks Id System
/dev/sda1 63 268430084 134215011 83 Linux
/dev/sda2 * 285201945 385865234 50331645 83 Linux
/dev/sda3 385865728 625141759 119638016 5 Extended
/dev/sda4 268430085 285201944 8385930 82 Linux swap / Solaris
/dev/sda5 524474055 625137344 50331645 83 Linux
/dev/sda6 385867776 524472319 69302272 83 Linux
Partition table entries are not in disk order

Is there something wrong with my partition table or can I safely ignore this message? It gives me a strange feeling.

srs5694 · 2013-08-31 16:07:10

I don't see any problems, either, although the partition table order is weird. There is, however, a comment in the cfdisk source code where this message is generated that may explain what's going on:

/* the enlarged logical partition starts at the
   partition table sector that defines it */

I'd need to trace through the code to figure out how the internal data structures are being used to fully understand this, but if the comment is correct, it means that the data structure that defines the partition (the extended boot record, or EBR) resides in the first sector of the partition that it defines. This is potentially bad because an operation like mkfs on the partition would wipe out its own partition definition and leave the linked list of logical partition definitions hanging at the end.

If this analysis is correct, I recommend you do the following:

Back up the partition in question, and maybe the whole disk.
Run FixParts on the disk -- launch the program, type "p" to verify that all your partitions (except the extended partition, which FixParts doesn't display) are there, and then type "w" to save it back out. You might also use "s" to sort the primary partition order before typing "w", too. (The logical partitions will be sorted automatically.) FixParts works, in part, by discarding the original extended partition and EBR data structures and generating new ones when you save the data, so it should fix the problem. Most distributions put the "fixparts" binary in the gdisk or gptfdisk package, but I don't know offhand what package name Arch uses.
If you refer to partitions by device filenames in /etc/fstab, you'll probably have to edit that file, since those filenames will change.

You could do something similar by using sfdisk to back up the partition table ("sfdisk -d /dev/sda > sda-parts.txt") and then restoring it ("sfdisk /dev/sda < sda-parts.txt"). As with FixParts, this discards the original EBR definitions, and sfdisk creates new ones, so the problem should go away. (In fact, you might want to back up the partition table with sfdisk and store the file on a USB flash drive before you use FixParts.)

Note that any partition manipulation is potentially risky, and this one adds a bit to the risk factor because neither of us fully understands the nature of the problem. (My analysis might be wrong, or FixParts [or sfdisk, if you use that] might not handle this condition very well, in which case it's conceivable that FixParts will flake out.)

relatime · 2013-08-31 23:54:41

Hi srs5694, thanks for your post!

I fixed the partition table order with fdisk (Wiki: Fixing messed-up partition order), now fdisk shows

# fdisk -l /dev/sda
Disk /dev/sda: 320.1 GB, 320072933376 bytes, 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x9986ab1b
Device Boot Start End Blocks Id System
/dev/sda1 63 268430084 134215011 83 Linux
/dev/sda2 268430085 285201944 8385930 82 Linux swap / Solaris
/dev/sda3 * 285201945 385865234 50331645 83 Linux
/dev/sda4 385865728 625141759 119638016 5 Extended
/dev/sda5 385867776 524472319 69302272 83 Linux
/dev/sda6 524474055 625137344 50331645 83 Linux

cfdisk still fails with the same error message.

I loaded the source code and added

printf("extended partition: %lld to %lld offset %ld\n",
p_info[i].first_sector,
p_info[i].last_sector,
p_info[i].offset);
printf("new partition: %lld to %lld\n",
first, last);

where you found the comment, giving

# make && ./cfdisk -Pt /dev/sda
extended partition: 385865728 to 524472319 offset 2048
new partition: 385865729 to 625137344
FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap

Not sure why this still is partition 6.

srs5694 wrote:

if the comment is correct, it means that the data structure that defines the partition (the extended boot record, or EBR) resides in the first sector of the partition that it defines. This is potentially bad because an operation like mkfs on the partition would wipe out its own partition definition and leave the linked list of logical partition definitions hanging at the end.

As far as I see, this is not the case.

# hexdump -v /dev/sda4 | tail -n 5
00003c0 ffff fe83 ffff fec6 0842 fffa 05ff 0000
00003d0 0000 0000 0000 0000 0000 0000 0000 0000
00003e0 0000 0000 0000 0000 0000 0000 0000 0000
00003f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000400
# hexdump -v /dev/sda5 | head -n 10000 | grep aa55
<no output>

I have found a Debian Bug #464377 which seems to be about the same problem. So I guess this is just a cfdisk problem.

WonderWoofy · 2013-09-01 00:56:05

Seeing as the whole disk is made of of Linux filesystems, have you thought about converting the partition table to GPT? Srs5694's gptfdisk (gdisk) can do this quite easily for you.

srs5694 · 2013-09-01 04:26:37

relatime wrote:

I fixed the partition table order with fdisk (Wiki: Fixing messed-up partition order)

relatime wrote:

srs5694 wrote:
if the comment is correct, it means that the data structure that defines the partition (the extended boot record, or EBR) resides in the first sector of the partition that it defines. This is potentially bad because an operation like mkfs on the partition would wipe out its own partition definition and leave the linked list of logical partition definitions hanging at the end.
As far as I see, this is not the case.
# hexdump -v /dev/sda4 | tail -n 5
00003c0 ffff fe83 ffff fec6 0842 fffa 05ff 0000
00003d0 0000 0000 0000 0000 0000 0000 0000 0000
00003e0 0000 0000 0000 0000 0000 0000 0000 0000
00003f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000400
# hexdump -v /dev/sda5 | head -n 10000 | grep aa55
<no output>

Your tests don't address my hypothesis. You'd need to locate the EBR for partition #6 and identify where it is relative to partition #6. I don't know of a tool that does this in an obvious way, so I modified gdisk and FixParts to do so. Compiled 64-bit binaries are here:

http://www.rodsbooks.com/gdisk-test.tgz

FixParts is more likely to work than gdisk, since the latter links against libicu libraries that tend to vary a lot between distributions. You can compile this yourself, if you prefer; load basicmbr.cc and change:

      EbrLocations[partNum] = offset;
      if (myDisk->Seek(offset) == 0) { // seek to EBR record

...to:

      EbrLocations[partNum] = offset;
      cout << "Reading EBR from sector " << offset << "\n";
      if (myDisk->Seek(offset) == 0) { // seek to EBR record

...in lines 264-265. The result will be a message about the sector from which the EBR is being read when you first launch the program. You'll need to compare those values to the ranges consumed by the partitions. If any EBR is within any partition, then my hypothesis is correct.

Note that neither gdisk nor FixParts modifies on-disk data structures until you explicitly write changes back out with a 'w' command, so you can run these tools as diagnostics with no risk of damaging your disk.

I have found a Debian Bug #464377 which seems to be about the same problem. So I guess this is just a cfdisk problem.

Maybe, but not necessarily. It could be that there's a bug in another program (fdisk, parted, FixParts, or even a non-Linux tool) that's causing EBRs to be mislocated. Given that you re-wrote your partition table with fdisk, that seems like a good suspect for this.

WonderWoofy wrote:

Seeing as the whole disk is made of of Linux filesystems, have you thought about converting the partition table to GPT? Srs5694's gptfdisk (gdisk) can do this quite easily for you.

This action would certainly bypass this specific problem, whatever the cause. OTOH, some workarounds may be required when BIOS-booting from GPT disks on certain motherboards. My Web page on the topic covers this in more detail. I don't mean to discourage use of GPT on a BIOS-based computer; I just want to be sure you know how to work around problems, should you encounter them, before you begin.

Arch Linux

#1 2013-08-31 13:36:26

cfdisk gives fatal error, should I bother?

#2 2013-08-31 16:07:10

Re: cfdisk gives fatal error, should I bother?

#3 2013-08-31 23:54:41

Re: cfdisk gives fatal error, should I bother?

#4 2013-09-01 00:56:05

Re: cfdisk gives fatal error, should I bother?

#5 2013-09-01 04:26:37

Re: cfdisk gives fatal error, should I bother?

Board footer