Partition tables sometimes misdetected as single large FAT file system

[David Balažic]

When a FAT file system is written to a whole disk device, it appears rather like a DOS partition table in some ways. libparted therefore needs to detect this situation and explicitly bail out of treating it as a DOS partition table. However, its detection is a bit broken at the moment and has some false positives. Specifically, if the disk previously had a FAT file system covering its entire extent, but then had a partition table written to it, it can happen that the FAT signature is left around and confuses libparted.

Both the Linux kernel and fdisk use a more reliable method, namely checking the boot indicator byte of all four partitions in the primary partition table to ensure that each one is either 0 or 0x80. libparted should be in sync with these. I sent a patch upstream (http://lists.alioth.debian.org/pipermail/parted-devel/2008-May/002243.html and thread) which has been accepted, and I uploaded this to intrepid as parted 1.7.1-5.1ubuntu10.

Attached is the diff between 1.7.1-5.1ubuntu9 in hardy and the proposed 1.7.1-5.1ubuntu9.1.

TEST CASE: This is a bit tricky to set up. The most obvious way is probably to replicate the reporter's partition table on a loopback device. To do this, download http://launchpadlibrarian.net/14818962/232175, then:

  dd if=/dev/zero of=parted-test bs=1024 count=$((1100*1024))
  dd if=232175 of=parted-test bs=512 count=1 conv=notrunc
  parted -s parted-test print

With the old libparted1.7-1, this erroneously prints:

Disk /home/cjwatson/parted-test: 1153MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number Start End Size File system Flags
 1 0.00kB 1153MB 1153MB fat32

The new one correctly prints:

Disk /home/cjwatson/parted-test: 1153MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 16.4kB 751MB 751MB primary boot
 2 751MB 1027MB 276MB primary

Please also check that parted still understands your own partition table correctly: 'sudo parted -s /dev/sda print', replacing /dev/sda with each of whichever disk devices you have.

Regression potential: We'll have to watch out for new partitioner bugs of the form "partitions on this disk not recognised at all". However, given that we're now in sync with the Linux kernel, I suspect that it's more likely that any regressions would be FAT file systems erroneously detected as partition tables (i.e. the other way round). It might be worth trying this out with USB sticks.

[Colin Watson (cjwatson)]

Could I get a dump of the partition table, please? The output of 'sudo od -tx1 -Ax -N512 /dev/sdc' should be sufficient.

[David Balažic (xerces8)]

000000 eb 58 90 4d 41 4b 45 42 4f 4f 54 00 02 08 40 00
000010 01 00 00 00 00 f8 00 00 20 00 40 00 00 00 00 00
000020 00 98 1e 00 a5 07 00 00 00 00 00 00 02 00 00 00
000030 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000040 80 00 29 e3 19 dd 47 52 49 50 4c 69 6e 75 58 20
000050 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d8 8e
000060 c0 8e d0 bc 00 7c fb fc 89 e6 bf 00 06 b9 00 01
000070 f3 a5 ea 77 06 00 00 88 16 00 08 be 9b 07 f6 c2
000080 80 74 03 be 9f 07 e8 c7 00 b4 08 cd 13 31 c0 88
000090 f0 40 a3 74 07 80 e1 3f 88 0e 76 07 be be 07 31
0000a0 c0 b9 04 00 f6 04 80 74 03 40 89 f7 83 c6 10 e2
0000b0 f3 83 f8 01 74 03 e9 88 00 8a 16 00 08 b8 00 41
0000c0 bb aa 55 31 c9 30 f6 f9 cd 13 72 2e 81 fb 55 aa
0000d0 75 28 f6 c1 01 74 23 be a3 07 e8 73 00 57 be 64
0000e0 07 8b 5d 08 89 5c 08 8b 5d 0a 89 5c 0a 8a 16 00
0000f0 08 8c d8 8e c0 b8 00 42 eb 34 be a9 07 e8 50 00
000100 57 8b 45 08 8b 55 0a f7 36 76 07 42 89 d1 31 d2
000110 f7 36 74 07 88 c5 d1 e8 d1 e8 24 c0 08 c1 88 d6
000120 8a 16 00 08 8c d8 8e c0 bb 00 7c b8 01 02 cd 13
000130 72 16 5e 81 3e fe 7d 55 aa 75 08 fa ea 00 7c 00
000140 00 77 05 be 78 07 eb 03 be 8e 07 e8 02 00 eb fe
000150 ac 20 c0 74 0c b4 0e 8a 3e 62 04 b3 07 cd 10 eb
000160 ef c3 00 00 10 00 01 00 00 7c 00 00 00 00 00 00
000170 00 00 00 00 00 00 00 00 4e 6f 20 6f 70 65 72 61
000180 74 69 6e 67 20 73 79 73 74 65 6d 0d 0a 00 44 69
000190 73 6b 20 65 72 72 6f 72 0d 0a 00 46 44 44 00 48
0001a0 44 44 00 20 45 42 49 4f 53 0d 0a 00 00 00 00 00
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01
0001c0 01 00 06 3f a0 cb 20 00 00 00 e0 5f 16 00 00 00
0001d0 81 cc 06 3f e0 d2 00 60 16 00 00 38 08 00 00 00
0001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
000200

[Colin Watson (cjwatson)]

It looks like this disk originally had a FAT filesystem on it, and was then overwritten with a normal partition table; however, a fresh boot sector was never written, and so the remnants of the old FAT filesystem are still hanging around. This makes a safety check in libparted kick in, because it thinks that the whole disk is a single FAT filesystem and so it shouldn't do anything with it.

The Linux kernel uses a different check for this, namely checking the active flag for each entry in the partition table and bailing out if it's neither 0 nor 0x80. I'll check this with upstream.

[Colin Watson (cjwatson)]

I've sent a proposed patch:

  http://lists.alioth.debian.org/pipermail/parted-devel/2008-May/002243.html

I'll wait until it attracts some upstream comment, though.

[Launchpad Janitor (janitor)]

This bug was fixed in the package parted - 1.7.1-5.1ubuntu10

---------------
parted (1.7.1-5.1ubuntu10) intrepid; urgency=low

  * fat-partition-table.dpatch: Instead of checking for FAT file system
    signatures (which has false positives), check whether the boot indicator
    on each partition is 0 or 0x80 (LP: #232175). This matches the behaviour
    of both the Linux kernel and fdisk.

 -- Colin Watson <email address hidden> Thu, 29 May 2008 12:09:09 +0100

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here

[Steve Langasek (vorlon)]

confirmed that the updated version fixes the output with the provided test case; copying to -updates.

[David Balažic (xerces8)]

This bug is still marked Status: New for "GNU Parted".
Why ?

[dino99 (9d9)]

outdated flavor, report about a newer active version if needed