non working gpt labels

Bug #107326 reported by Bernhard J. M. Grün
36
Affects Status Importance Assigned to Milestone
parted (Ubuntu)
Fix Released
High
Colin Watson
Nominated for Feisty by Bernhard J. M. Grün
Hardy
Fix Released
High
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
Revision history for this message
NowakPL (nowak) wrote :
Revision history for this message
M. O. (marcusoverhagen) 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.

Revision history for this message
M. O. (marcusoverhagen) wrote :

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

Revision history for this message
M. O. (marcusoverhagen) wrote :

for reference:

7Tb XFS partition lost on reboot:
http://ubuntuforums.org/showthread.php?p=3730925

Issues with very large partitions:
http://ubuntuforums.org/showthread.php?t=429986

Revision history for this message
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/libparted-1.6.so.13.11.1 (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: libparted-1.6.so.13 -> libparted-1.6.so.13.11.1
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.

[0] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/46853/comments/8
[1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/46853/comments/14
[2] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/46853/comments/15

Changed in parted:
status: New → Confirmed
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Richard Laager (rlaager) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Pau Garcia 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: https://launchpad.net/~pgquiles/+archive

Revision history for this message
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 https://bugs.launchpad.net/ubuntu/+source/parted/+bug/107326/comments/5 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)
Changed in parted:
importance: Undecided → High
Revision history for this message
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(); }

Revision history for this message
johannes (j00hannes) wrote :

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ò!).

Revision history for this message
Pau Garcia 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).

Revision history for this message
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.

Revision history for this message
Carl Richell (carlrichell) wrote :

Hey Colin,

This bug is nagging us as well. http://system76.com/servers

Revision history for this message
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
Revision history for this message
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  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.