latest grub2 renders gpt based system unbootable

I have a 17" Unibody Macbook Pro that had a fresh install of Ubuntu done with Lucid alphas, regularly updated, and I attempted to upgrade grub2 and the system booted fine.

So at least on my machine, I cannot reproduce this bug.

Emmet pinged me on this bug as part of the SRU regression process.

After careful analysis, this bug doesn't seem to impact a large user base.

I run grub2 ubuntu6 on a GPT system myself, and I don't seem to be affected (but it ain't a MacBook, and these systems might be special). John Dong on IRC also tried reproducing, but couldn't. I suggested he backups his /var/cache/debconf before upgrading to the ubuntu6 update though.

I considered simply fixing the bug tonight, but it doesn't seem easy to reproduce on non-MacBook systems, and the code is subtle, so it seemed sensible to defer for 8 hours to get Colin to have a look.

I considered reverting the fix, but the bug addressed by the SRU seems much more severe than this one (breaking widely available Dell pre-installed 9.10 Ubuntu systems), so we seem to be better off with breaking a smaller number of MacBooks.

I will mail cjwatson to tell him about the bug and will ping him tomorrow morning about this regression.

@John Dong: I suspect one needs to upgrade from karmic to reproduce though

What strikes me here is the clear warning message about the
unreliability of grub related to the gpt partition, that could be seen
on the aptitude console. As if the pre or post install scripts had
detected something fishy. What happened there?

If boot from a usb drive, how can I redo this test before trying a
grub-install?

On Fri, May 7, 2010 at 1:07 AM, Loïc Minier <email address hidden> wrote:
> @John Dong: I suspect one needs to upgrade from karmic to reproduce
> though
>
> --
> latest grub2 renders gpt based system unbootable
> https://bugs.launchpad.net/bugs/576662
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “grub2” package in Ubuntu: New
>
> Bug description:
> Binary package hint: grub2
>
> system version : upgraded form Karmic to beta Lucid then regurlarly updated
> package version: unknown (system unbootable at this time ...)
>
> The hardware is an Apple Macbook computer with gpt partitions instead of a bios boot partitions (all the recent Apple hardware). The gpt partitions support by grub is more recent than the support for the bios. Bootcamp is installed on the hardware and provides a choice to boot either Linux or Macosx.
>
> steps:
>
> 1. aptitude update && aptitude upgrade
> 2. watch the console output, notice a capital warning about grub2 being unreliable on gpt partition (i know it is vague)
> 3. reboot the machine
> 4. watch the bootcamp menu
> 5. click on the linux
>
> The result expected is the grub menu, but the bootcamp menu stays on, and it is frozen.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/576662/+subscribe
>

Can anyone get me the exact, unparaphrased error message here? Also, the output of 'sudo debconf-show grub-pc' wouldn't hurt.

I'm not sure I see how this could have anything to do with my fix for bug 508173, personally. That new code is clearly guarded such that it would not have been run on an upgrade from Lucid release. Perhaps any change to grub2 would have caused this?

If the message you are seeing is "This GPT partition label has no BIOS Boot Partition; embedding won't be possible!", then see http://grub.enbug.org/BIOS_Boot_Partition

On Fri, May 7, 2010 at 2:44 AM, Colin Watson <email address hidden> wrote:
> If the message you are seeing is "This GPT partition label has no BIOS
> Boot Partition; embedding won't be possible!", then see
> http://grub.enbug.org/BIOS_Boot_Partition

During the upgrade, I also read "When GRUB can't be embedded, its only
option is to use blocklists, which are unreliable and discouraged. "

If I understand well, as my system used to boot:

1. either my system used a GPT BIOS boot partition instead of an MBR
to embed the core.img
2. or there was no BIOS boot partition and my system used the block
lists, unreliable but functional

Using "parted" in some read or query mode might help me check if I
have a BIOS boot partition or not. I do not know how boot camp comes
into play in this setup. Maybe it is just a procedure to create a BIOS
boot partition, which would contain the OS choice and icon. If my
system was in setup 1. above, then the core.img _and_ the apple code
would have co-existed inthe GPT BIOS partition. Or maaybe bootcamp is
located in the first bytes of the device and grub is installed on the
first bytes of the partition?

Now, the failed upgrade:
1. the upgrade did not recognized the existing GPT BIOS partition and
decided to go with the blocklist method then 2,
2. the blocklist methods failed this time due to one og the reasons
listed on the wiki,

To turn my brick back into my gold, I can :
1. boot on an alternate media, use parted to diagnose and eventually
create a gpt BIOS boot partition, and try re-install grub.
2. boot on an alternate cd, backup and reinstall making sure the linux
partitions is not formatted and my /home is kept intact
3. backup and re-install from scratch

Any hints welcome, thanks in advance,

>
> --
> latest grub2 renders gpt based system unbootable
> https://bugs.launchpad.net/bugs/576662
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “grub2” package in Ubuntu: New
>
> Bug description:
> Binary package hint: grub2
>
> system version : upgraded form Karmic to beta Lucid then regurlarly updated
> package version: unknown (system unbootable at this time ...)
>
> The hardware is an Apple Macbook computer with gpt partitions instead of a bios boot partitions (all the recent Apple hardware). The gpt partitions support by grub is more recent than the support for the bios. Bootcamp is installed on the hardware and provides a choice to boot either Linux or Macosx.
>
> steps:
>
> 1. aptitude update && aptitude upgrade
> 2. watch the console output, notice a capital warning about grub2 being unreliable on gpt partition (i know it is vague)
> 3. reboot the machine
> 4. watch the bootcamp menu
> 5. click on the linux
>
> The result expected is the grub menu, but the bootcamp menu stays on, and it is frozen.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/576662/+subscribe
>

Marked the bug as invalid (I am the original reporter). I can't reproduce the problem again. After a day, the system rebooted fine. I am performing different tests (smartctl tests) on the hard drive.