[Bug 1351071] Re: When GPT minimally replaced by MBR, Ubiquity resurrects GPT data

Mon Aug 4 17:46:23 UTC 2014

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: ubiquity (Ubuntu)
       Status: New => Confirmed

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

Title:
  When GPT minimally replaced by MBR, Ubiquity resurrects GPT data

Status in “ubiquity” package in Ubuntu:
  Confirmed

Bug description:
  When a GUID Partition Table (GPT) disk is partitioned with fdisk
  (without GPT support), with Microsoft's default partitioning tools, or
  with certain other GPT-unaware tools, the result is a valid MBR
  partition table and leftover GPT data. The GPT spec (part of the
  EFI/UEFI spec) is quite clear that such a disk should be treated as an
  MBR disk. Ubiquity, however, often resurrects the old GPT data. I've
  seen reports online that it will report that the disk is empty, but
  when I tried to reproduce the problem, I didn't see that behavior.
  Either result has the potential to completely trash a user's
  partitions, and so is extremely serious.

  Steps to reproduce:

  1. Create a disk with GPT partitions. For realism, put filesystems on them. To duplicate one common use case, make them NTFS and FAT partitions, similar to what a Windows 8.1 system might use.
  2. Use a GPT-unaware partitioning tool (such as Ubuntu's fdisk) to partition the disk. Delete the type-0xEE protective partition and create one or more new partitions that do NOT replicate the types and sizes of the original GPT partitions.
  3. Optionally create filesystem(s) on the new partition(s).
  4. Start an Ubuntu installation on the disk. (I used 14.04.1 desktop for this test.) When asked, select the "something else" partitioning option.

  Result:

  In my test, the old GPT partitions appear in the partition list. Some
  online reports I've seen indicate an empty partition list when steps
  equivalent to these are followed.

  Ultimately, the problem is in libparted, which does a poor job of
  handling this condition. Here are some program outputs:

  $ sudo fdisk -l /dev/sda

  WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util
  fdisk doesn't support GPT. Use GNU Parted.

  Disk /dev/sda: 111.0 GB, 111008546816 bytes
  78 heads, 13 sectors/track, 213820 cylinders, total 216813568 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 identifier: 0x00000000

     Device Boot      Start         End      Blocks   Id  System
  /dev/sda1            2048   216813567   108405760   83  Linux

  The disk has a single Linux partition. fdisk (which does not use
  libparted) complains about the presence of leftover GPT data
  structures (which is a reasonable precaution), but the EFI spec says
  that this is an MBR disk.

  $ sudo gdisk /dev/sda
  GPT fdisk (gdisk) version 0.8.8

  Caution: invalid backup GPT header, but valid main header; regenerating
  backup header from main header.

  Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
  on the recovery & transformation menu to examine the two tables.

  Warning! One or more CRCs don't match. You should repair the disk!

  Partition table scan:
    MBR: MBR only
    BSD: not present
    APM: not present
    GPT: damaged

  Found valid MBR and corrupt GPT. Which do you want to use? (Using the
  GPT MAY permit recovery of GPT data.)
   1 - MBR
   2 - GPT
   3 - Create blank GPT

  Your answer:

  gdisk (which does not use libparted) identifies the issue and offers
  the user a choice of what to do.

  $ sudo fixparts /dev/sda
  FixParts 0.8.8

  Loading MBR data from /dev/sda

  NOTICE: GPT signatures detected on the disk, but no 0xEE protective partition!
  The GPT signatures are probably left over from a previous partition table.
  Do you want to delete them (if you answer 'Y', this will happen
  immediately)? (Y/N): n

  The fixparts output identifies the issue and offers a chance to fix
  the problem. (I selected "n" so as to continue tests/demonstrations.)

  $ sudo parted /dev/sda
  GNU Parted 2.3
  Using /dev/sda
  Welcome to GNU Parted! Type 'help' to view a list of commands.
  (parted) print                                                            
  Warning: /dev/sda contains GPT signatures, indicating that it has a GPT table.
  However, it does not have a valid fake msdos partition table, as it should.
  Perhaps it was corrupted -- possibly by a program that doesn't understand GPT
  partition tables.  Or perhaps you deleted the GPT table, and are now using an
  msdos partition table.  Is this a GPT partition table?
  Yes/No? n                                                                 
  (parted)

  Here you can see that parted has detected and identified the issue,
  but when explicitly told that it's NOT a GPT disk, it ignores the
  valid MBR partition table and instead presents the disk as
  unpartitioned.

  (parted) print
  Warning: /dev/sda contains GPT signatures, indicating that it has a GPT table.
  However, it does not have a valid fake msdos partition table, as it should.
  Perhaps it was corrupted -- possibly by a program that doesn't understand GPT
  partition tables.  Or perhaps you deleted the GPT table, and are now using an
  msdos partition table.  Is this a GPT partition table?
  Yes/No? yes                                                               
  Error: The backup GPT table is corrupt, but the primary appears OK, so that will
  be used.
  OK/Cancel? ok                                                             
  Model: ATA VBOX HARDDISK (scsi)
  Disk /dev/sda: 111GB
  Sector size (logical/physical): 512B/512B
  Partition Table: gpt

  Number  Start   End     Size    File system  Name                  Flags
   2      2371MB  2505MB  134MB                Microsoft basic data  msftdata
   3      2505MB  77.7GB  75.2GB  ntfs         Microsoft basic data  msftdata

  This continues from before and shows what happens when parted is told
  to use the (technically invalid) GPT data structures.

  Potential consequences:

  Consider a user who has a computer with Windows 8 pre-installed in EFI
  mode (therefore using GPT) and and who then decides to install Windows
  7 in BIOS mode (therefore using MBR). The result will be similar to
  what's described here -- an MBR partition table with leftover GPT
  data, from which Ubquity will extract the GPT data (or perhaps show
  the disk as unpartitioned, if online reports are accurate). Worse, the
  user might not notice the problem until Ubiquity/libparted has
  resurrected the now-invalid GPT data, therefore trashing the new
  Windows 7 installation. Many similar scenarios are possible. I've seen
  reports of problems like this in the real world, but unfortunately I
  haven't saved URLs.

  I'm attaching log files from an attempt to install to the disk
  represented by the above partitioning tools' output.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1351071/+subscriptions