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: > > " 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.