Comment 61 for bug 576724

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 576724] Re: Ubuntu Lucid grub2 dist-upgrades result in confusion

On Thu, Jul 01, 2010 at 03:18:03AM -0000, Erick Brunzell wrote:
> But I should have time to do the SRU testing for this and #580408 very
> soon (hopefully within 48 hours). Although I'm just a little unclear
> what exactly to do, sorry :^(

Note that my proposed upload hasn't yet been accepted or built. I'll
nudge another member of the SRU team about it in a bit, but we're quite
busy with Maverick Alpha 2 right now which is due today.

> To recap, in this thread you say, "The simplest way to force this
> confusing screen to appear is by running 'sudo dpkg-reconfigure grub-
> pc'. The broken state is that all partitions are offered, including
> Windows partitions which will be broken by installing GRUB to them; the
> desired state is described in comment 56."
>
> I do understand the command, but is it or is it not necessary to apply
> any patch first? If yes I'm a bit unclear how to apply the patch. I'm
> thinking it's applied on the Ubuntu server end but I'm just not sure.

I normally phrase the test case as "if you run this without the update,
it should fail; if you run this with the update, it should succeed", so
that if necessary a previously uninvolved observer can come in and
verify the fix. This is because it does no good to verify that you
don't see a bug with an update unless you also verify that you did see
the same bug without the update.

Once my upload is accepted, there'll be a message sent to this bug with
instructions on where to get the proposed fix; it will be built on our
servers.

> I do understand the commands, and I have no problem with using a two
> disk system, but would you prefer I use a two disk system with Windows
> on one disk? Maybe with a Win MBR on one disc and a grub 2 MBR on the
> other? Or does that even matter?

It doesn't matter what MBRs are present. Some partitions other than
Ubuntu should be present, although it doesn't matter what they are;
Windows is as good as any. It doesn't matter which operating system is
on which disk - I just need it to be a two-disk system because otherwise
you trigger some special cases in the grub2 packaging and it becomes
harder to reproduce this bug.

I was actually imagining that a tester would probably use a throwaway
virtual machine, but if somebody wants to use a real system then that's
even better.

> And once again, do I need to manually apply any patch first?

The way proposed updates work is that they're made available in
"lucid-proposed" until they've been verified, so it's possible to vary
what apt-get will install by adding or removing appropriate lines from
/etc/apt/sources.list and running 'sudo apt-get update'. Once my
proposed fix is published, turning on lucid-proposed and upgrading
grub-pc will pull it in. Full instructions are here:

  https://wiki.ubuntu.com/Testing/EnableProposed

> And regarding that latter command, "'echo SET grub-pc/install_devices
> /dev/hda | sudo debconf-communicate', should the "/dev/hda" not be
> "/dev/sda" for Ubuntu? Sorry to be a pain, I just want to be sure.

No - I deliberately made that "wrong" in order to trigger a certain
special case. ("/dev/ohdearnosuchdevice" would work just as well, so
maybe I should have been more explicit.)

> I do have one more "dumb" question. I've generally avoided using a
> separate "/boot" partition unless absolutely necessary to deal with
> BIOS partition size limits so I know little about such layouts. So this
> from your #grub conversation:
>
> "<cjwatson> Jordan_U: I thought about an Advanced option, but since I
> can't think of a good reason for people to install other than to the
> partition containing /boot (actually /boot/grub), there doesn't seem a
> need for it"
>
> sort of raised an eyebrow because I remember with legacy grub how I had
> to drop the "/boot" from "find /boot/grub/stage1" while using a grub
> shell to reinstall legacy grub if a separate "/boot" existed. But I'm
> sure you took that into consideration. Just thought I might as well
> display my ignorance :^)

You do have to handle paths differently if you have a separate /boot,
but I dealt with that. Mostly it doesn't make a big difference for the
purposes of this bug, though.

> Above all else please accept my thanks for taking care of this and also
> my apologies for being somewhat pushy.

No problem, and I appreciate the offer of testing.