Automatic partitioning corrupts GUID partition table (GPT)

Bug #837681 reported by Chad A. Davis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
parted (Ubuntu)
Fix Released
Critical
Colin Watson
Oneiric
Fix Released
Critical
Colin Watson

Bug Description

With a functioning Oneiric installation on a MacBookPro6,2 I installed Oneiric again and chose the automatic partition resize option. This corrupted the partition table, preventing booting of either operating system. It also doesn't appear possible to repair the system, as no tools can read the partition table to mount / fix the situation.

TEST CASE
Install Oneiric on a GPT machine (e.g. a Mac) with an empty partition table. Start by creating a swap partition of the size of the RAM. Then create an ext4 (the default) partition for the remaining space, but leave ~1MB for the GPT / bios_grub partition. The installer (partman-efi?) will place the GPT / bios_grub partition in this free space. This system boots correctly.

Now install a second instance of Oneiric and select automatic resize of existing partitions, leaving the default settings (50% of space allocated to each system)

That resulted in this partition table (from sfdisk -l) :

Disk /dev/sda: 38913 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start End #cyls #blocks Id System
/dev/sda1 0+ 497- 498- 4000000+ 82 Linux swap / Solaris
  start: (c,h,s) expected (0,0,35) found (1023,254,63)
  end: (c,h,s) expected (497,249,43) found (1023,254,63)
/dev/sda2 * 497+ 20035- 19538- 156933594 83 Linux
  start: (c,h,s) expected (497,249,44) found (1023,254,63)
/dev/sda3 20035+ 20035- 1- 977 ee GPT
/dev/sda4 20035+ 38408- 18374- 147583008 83 Linux

palimsest reports that the disk is unpartitioned.

gparted reports erros on the two ext4 partitions:

e2label: No such file or directory while trying to open /dev/sda2
Couldn't find valid filesystem superblock.
Couldn't find valid filesystem superblock.
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: No such file or directory while trying to open /dev/sda2

gparted reports for the bios_grub partition:

Unable to detect file system! Possible reasons are:
- The file system is damaged
- The file system is unknown to GParted
- There is no filesystem available (unformatted)
- The device entry /dev/sda3 is missing

The problem is not the result of having two systems installed. If you install a system with the partitioning option to use the entire disk and then install another system that automatically resizes existing partitions, then both systems boot correctly.

I don't think there was too little space left from my manual partitioning of the initial system, because the initial operating system booted fine.

Maybe the problem is having the GPT / bios_grub partition at the end of the partition table, since the default is to place it at the beginning of the partition table (when installing with the partitioning option to use the entire disk).

Unfortunately, I can no longer access the logs, as I cannot mount the partitions.

This is the ISO ubuntu-oneiric-alternate-amd64+mac.iso from 2011-08-29

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: ubiquity 2.7.17
ProcVersionSignature: Ubuntu 3.0.0-9.14-generic 3.0.3
Uname: Linux 3.0.0-9-generic x86_64
Architecture: amd64
CasperVersion: 1.279
Date: Tue Aug 30 20:11:08 2011
LiveMediaBuild: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64+mac (20110829)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Chad A. Davis (chadadavis) wrote :
Changed in ubiquity (Ubuntu):
importance: Undecided → High
Changed in ubiquity (Ubuntu):
importance: High → Critical
assignee: nobody → Ubuntu Installer Team (ubuntu-installer)
Changed in ubiquity (Ubuntu):
milestone: none → ubuntu-11.10-beta-1
Revision history for this message
Colin Watson (cjwatson) wrote :

I'm working on constructing my own test case. I rather suspect this is a parted bug, though; it reminds me of bug 757201.

affects: ubiquity (Ubuntu Oneiric) → parted (Ubuntu Oneiric)
Changed in parted (Ubuntu Oneiric):
assignee: Ubuntu Installer Team (ubuntu-installer) → Colin Watson (cjwatson)
milestone: ubuntu-11.10-beta-1 → none
milestone: none → ubuntu-11.10-beta-1
Revision history for this message
Chad A. Davis (chadadavis) wrote :

Even before installing the second system, simply doing a manual partitioning results in an odd partition table. The partition table generated when selecting 'use the entire disk' puts the GPT partition at the beginning. This shows up in gparted as the bios_grub partition.
When I manually partition and create one swap and one ext4 root partition, I'd figure the GPT partition would go at the end. Both fdisk and sfdisk show sda1 as being a GPT partition, however. And gparted doesn't see any bios_grub partition at all. Somehow the system boots but it seems that the partition table is inconsistent. That might explain why later resizing partitions to install another system fails.
I'm attaching the logs from a single installation using manual partitioning.

Revision history for this message
Chad A. Davis (chadadavis) wrote :
Revision history for this message
Chad A. Davis (chadadavis) wrote :
Colin Watson (cjwatson)
Changed in parted (Ubuntu Oneiric):
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package parted - 2.3-6ubuntu2

---------------
parted (2.3-6ubuntu2) oneiric; urgency=low

  * When creating a legacy MBR on Apple systems, only ever mark an existing
    partition as a fake protective partition if it is the first partition
    and it starts at LBA 1, otherwise GRUB and the Linux kernel respectively
    will fail to treat the disk as GPT; if there is no partition fitting
    these criteria, then fall back to creating a fake protective partition
    (LP: #837681).
 -- Colin Watson <email address hidden> Wed, 31 Aug 2011 23:39:36 +0100

Changed in parted (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Revision history for this message
Chad A. Davis (chadadavis) wrote :

For the record, running gptsync from a live CD won't rescue this situation because it doesn't understand the partition table and refuses to modify it.

  "Status: Analysis inconclusive, will not touch this disk."

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 837681] Re: Automatic partitioning corrupts GUID partition table (GPT)

On Thu, Sep 01, 2011 at 08:51:24AM -0000, Chad A. Davis wrote:
> For the record, running gptsync from a live CD won't rescue this
> situation because it doesn't understand the partition table and refuses
> to modify it.
>
> "Status: Analysis inconclusive, will not touch this disk."

Ah, OK. Do you still need help recovering, or are you just going to
reinstall? If the former, I could probably manage to do it by hand
given a raw dump of the first sector of the disk ...

Revision history for this message
Chad A. Davis (chadadavis) wrote :

Fix confirmed for parted-2.3-6ubuntu2
Thanks for asking, Colin, but this is just a test machine, made for breaking. Just wanted to try gptsync.
And thanks for the quick fix.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers