Public bug reported:
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.
** Affects: ubiquity (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "/var/log/partman file"
https://bugs.launchpad.net/bugs/1351071/+attachment/4167042/+files/partman
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1351071
Title:
When GPT minimally replaced by MBR, Ubiquity resurrects GPT data
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1351071/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
