[Bug 232175] Re: Partition tables sometimes misdetected as single large FAT file system

[dino99]

outdated flavor, report about a newer active version if needed

** Changed in: parted
   Importance: Unknown => Undecided

** Changed in: parted
 Remote watch: Parted tracker #14 => None

** Changed in: parted
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to parted in Ubuntu.
https://bugs.launchpad.net/bugs/232175

Title:
  Partition tables sometimes misdetected as single large FAT file system

Status in GNU Parted - Partition manager:
  Invalid
Status in parted package in Ubuntu:
  Fix Released
Status in parted source package in Hardy:
  Fix Released

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/parted/+bug/232175/+subscriptions