non working gpt labels

Bug #107326 reported by Bernhard J. M. Grün on 2007-04-17
Affects Status Importance Assigned to Milestone
parted (Ubuntu)
Colin Watson
Nominated for Feisty by Bernhard J. M. Grün
Colin Watson

Bug Description

Binary package hint: parted

The ubuntu parted that is on the feisty (64bit) installation cds has a bug when creating gpt labels (at least on large disk arrays). We tried to create a gpt label and one XFS partition on a 10,5 TB RAID6-Array.
Notice: Exactly the same procedure worked on grml 0.9 (32 bit distribution). So it is a bug on the ubuntu side for sure.
Also the grml-version of parted shows the following warning when we print the partition table (print command):
Warning: /dev/sdc contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. (and so on)
So it seems parted is not able to create correct gpt labels.

We never saw a similar warning with the ubuntu parted. And this warning is only shown when we create the partition and the label with ubuntu's parted.

Here is the way we can reproduce that error:
parted /dev/sdc mklabel gpt
parted /dev/sdc rm 1
parted /dev/sdc mkpart primary 0 10500G
mkfs.xfs -f /dev/sdc1
mount /dev/sdc1 /mnt/sdc1
df -h [size should be 9.6T]
umount /mnt/sdc1
hdparm -z /dev/sdc[a restart of the system does the same!]
mount /dev/sdc1 /mnt/sdc1

Then you should see the following error on ubuntu. With grml it works correctly:
I/O error in filesystem ("sdc1") meta-data dev sdc1 block 0x4c65c46ff ("xfs_read_buf") error 5 buf count 2
mount: /dev/sdc1: can't read superblock

Also notice: You'll lose all your data on that partition because of that error! grml uses the same parted version 1.7.1(but without some ubuntu patches)

Related branches

description: updated
NowakPL (nowak) wrote :

I can confirm this bug.

Happened for me with Edgy 32bit.

The included gnu parted 1.7.1 is broken. I created a 2.7 TB GTP partition, and initialized it with ext3.
On reboot fsck reported that the file system was larger then the partition, and it was unuseable.

I compiled/installed parted 1.8.8 directly from GNU ftp, recreated the GTP label and partition, and this time it is ok and working.

Typo. I meant GPT instead of GTP in the above comment.

for reference:

7Tb XFS partition lost on reboot:

Issues with very large partitions:

Richard Laager (rlaager) wrote :

This is still a problem with Gutsy. I have a 64-bit machine with a 2.25 TB array (hardware RAID 5 of four 750 GB drives). The installer is "syncing" the GPT label into an msdos label. I think everyone agrees this is wrong, but it was supposedly done for compatibility with Apple's software. See bug #46853 as NowakPL pointed out. In that bug report, there's a comment [0] which says, "Until an EFI-aware GRUB installation is possible, it would be best if Ubiquity would sync MBR and GPT and ensure the proper boot partition type is set." The key part is the first phrase.

The sync patch was accepted for parted 1.7.1-3ubuntu3 on 2007-03-07 [1]. The next day [2], the grub GPT patch was accepted. I'm not sure the former is needed, as the latter works--grub supports GPT now.

I was able to install and use grub on this drive (greater than 2 TB) with Gutsy, as follows:
1. I booted the Gutsy installer and went through the partitioning screen to set things up the way I wanted them (mainly so the installer saved my settings).
2. When prompted for the timezone, I dropped into the shell in the installer, turned off the swap partition, and dismounted the stuff under and including /target. (I was just using one partition, but if you had others, you'd have things mounted under /target.)
3. I copied over /sbin/parted and /lib/ (I hope I got those names right) from a Dapper installer that I booted on another machine.
4. I made the appropriate symlink in /lib: ->
5. I ran the copied Dapper parted. I ran "mklabel gpt" to start over. I then re-created my partitions, being careful to make sure the partition numbers matched what I did in the installer.
6. I remounted /target and turned the swap back on.
7. I continued the install through to the grub installation phase, which strangely failed. I'm not sure why.
8. I dropped back into a shell and chroot'ed myself into /target. I then started bash, but that probably wasn't required for this to work.
9. I ran grub-install /dev/sda, copied over a /boot/grub/menu.lst from another working system, and ran update-grub.
10. I exited the chroot environment, flipped back to the installer, and rebooted. The system came up fine using GPT. I have a protective MBR, *NOT* a synched one.

There are two problems here: First, parted is synching the MBR, which violates the standard. IF (and I have no way of testing this), Macs can work with the patched grub, the sync patch should be reverted. If they can't, then those changes need to be conditionalized so that the MBR is syched ONLY if the *drive* is less than 2 TB (and presumably if there are 4 or less partitions, but that's unrelated to the problem here). Second, grub failed to install from the installer, but worked fine from the target environment. I don't know what is going on there.


Changed in parted:
status: New → Confirmed
Richard Laager (rlaager) wrote :

The failure of grub to install from my last message may be related to the various testing we did. At this time, it's not reproducible. I've boiled the work-around steps to: Install, wait until the end, run Dapper's parted and let it fix the corrupt (i.e. synced) GPT, re-install grub, and finish the reboot as normal. I've attached parted from a booted Dapper CD (on the amd64 architecture) here for others to use.

Quesar (rick-microway) wrote :

I had the same problem working with a 3TB array. I created 7 partitions on a gpt label with parted from 7.10 64bit desktop. I then used hdparm -z /dev/sda to reread the partitions, but the OS only saw the first 4. I then chrooted into SLES 10 and used the parted from it. It gave the same error message regarding the bad gpt label that has been reported already. I made 1 small change so that the SLES10 version of parted would rewrite the partition table, and then hdparm -z /dev/sda correctly read the partition table after that.

Also, I have a patched version of grub that works with gpt partition tables. I can provide it if necessary. This patched version also wouldn't work until I used the parted from SLES10. The parted from ubuntu 7.10 64bit desktop left the partition table in a state that would not work with my patched grub.

Richard Laager (rlaager) wrote :

Quesar, the bug I referenced includes a comment about GRUB in Ubuntu being patched with the GPT support.

don hardaway (don-hardaway) wrote :

Now sure but I think some of this discussion may explain my problem. I installed gusty on my macbookpro and both the Mac OS and Ubuntu would able to be launched from the Mac menu. Then I installed Linux Mint and then none of my Linux installations would boot. I was going to put Grub stage 1 on the partition with my installation as some instructions said but when using the alternative install cd you are not given a choice of advanced---so i guess it wrote grub to the MBR. Afterwards i have relauched ubuntu and Linux Mint cds and tried to install the stage1 bootloader to their respective partitions but it gives an error and will not let me. I am considering using dd to zero the first 446 bytes of the MBR since i keep getting three Linux icons upon boot when there is only two installs. I think the third one is coming from the one where it was installed to the MBR while the other two are from the partitions where my two linux installations are. I am trying to understand how the MBR and the gpt on this efi MAC works but I do not want to mess up my MAC booting. Any help you can provide so I can get multiple Linux distros to work with my Mac OS would be great. Thank You.

Richard Laager (rlaager) wrote :

don hardaway: This bug is about a change made to help support Macs breaking GPT labels for disks > 2 TB. This is not the right place to address your issue, unless you have a large disk. I would recommend you try some of the various Ubuntu forms or maybe the IRC channel. Given that you're asking for help, I would strongly recommend you NOT attempt to zero parts of your disk. You could blow things up in a real hurry that way.

Pau Garcia i Quiles (pgquiles) wrote :

Why is this bug unfixed yet? It destroyed 3TB of data for me, fortunately I still had a copy of the data at the original location.

Anyway, I built Gutsy packages of Parted 1.8.8 with the Debian/Ubuntu patches but not the Mac "compatibility" patch which is messing everything up. They are available in my PPA:

Colin Watson (cjwatson) wrote :

I'm pretty confident that the gptsync patch is still needed on Macs in order to make the firmware recognise it; the grub patch is necessary but not sufficient. Yes, it violates the standard, but that's Apple's fault ...

I think the suggestion in to conditionalise it on <2TB disks is reasonable. Another option would be to conditionalise it on whether the running system is a Mac. There are advantages and disadvantages to both. Just checking the disk size is a heck of a lot easier than messing about with DMI to figure out the running system, and wouldn't break the ability to pull out a disk and fiddle with it on another system. However, I suspect pulling out disks from Macs and partitioning them on non-Macs is really pretty rare, and I'd rather our behaviour on non-Mac systems were consistent between 1.9TB and 2.1TB disks.

Colin Watson (cjwatson) on 2007-12-18
Changed in parted:
importance: Undecided → High
Richard Laager (rlaager) wrote :

Colin, thanks for looking at this again. I think my suggestion for conditionalizing on < 2 TB is better than conditionalizing on Mac vs. non-Mac, because if a Mac had a 2 TB drive, I'm guessing it would suffer this same problem, as it is Linux that is preferring the msdos partition table to GPT, not the BIOS, so the hardware shouldn't matter. If you really want consistency on non-Macs, then you probably want to conditionalize as: if (mac && drive_size < 2 TB && number_of_partitions <= 4) { sync_gpt(); } else { protect_gpt(); }

i experienced the same problem on a 64 bit ubuntu 7.10 with a 4,5 tb hardware-raid which i formated as one whole partition. after rebooting the machine and mounting the partition there were only 95 gb left on it and running fsck i encountered a lot of errors.

as a solution (after two days of not finding this side or any other description of the problem) i used pau's ppa with the version 1.8.8 of parted and now everything works fine (moltes gracies per això!).

Pau Garcia i Quiles (pgquiles) wrote :

Hardy Beta is almost there and this bug is still unfixed. Please, fix this issue. Hardy is a LTS release, thus many people are going to be bitten by this bug. A few years ago > 2TB was crazy but nowadays is quite usual in servers and it will be usual in desktops in a couple of years (1TB hard disks are already usual in high end desktops).

Richard Laager (rlaager) wrote :

I agree. I've purchased a Mac to test this on, but I'm not sure if I'll be able to fix this by myself. Any help would be greatly appreciated.

Carl Richell (carlrichell) wrote :

Hey Colin,

This bug is nagging us as well.

Colin Watson (cjwatson) wrote :

I have a fix for this on my laptop now that makes the legacy MBR code conditional on whether the system is a Mac, with an environment variable override for cases where this is wrong. I'm actually on holiday right now, but when I get back next week I'll upload it for testing; there should be no problem with getting this fixed in 8.04 at this point. (I just wanted to let this bug know so that people don't get too worried over the next week.)

Changed in parted:
assignee: nobody → kamion
milestone: none → ubuntu-8.04
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

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

parted (1.7.1-5.1ubuntu9) hardy; urgency=low

  * gptsync.dpatch: Only write a synced legacy MBR on Apple systems;
    otherwise, write a protective MBR per the EFI standard (LP: #107326).
    This behaviour may be overridden by setting the environment variable
    PARTED_GPT_APPLE to 1 (always write synced legacy MBR) or 0 (always
    write protective MBR).

 -- Colin Watson <email address hidden> Sun, 30 Mar 2008 21:35:47 +0100

Changed in parted:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers