[10.10 - Alpha 3 (candidate)] Prompts misleading grub dialogs during UEC Node installation.

[Dave Walker]

bzr1218-0ubuntu1 introduced a new depends for the node controller. This causes two dialogs to be presented to the installer, but it seems the data isn't really required and the real grub installation is handled later (end of process).

The first one asks for a "Linux Command", which can be left blank.

The second, more concerning one is grub asking which device you want grub installed on. When selecting a device, grub returns a confirmation that "you don't want to install grub?".. This is false, as it can be safely ignored.

[Scott Moser (smoser)]

This bug is present now because eucalyptus-nc added a dependency on grub-pc. I believe that this caused grub-pc to get installed earlier in the installation process, before some other things were properly set up.

The reason for the dependency on grub-pc is that eucalyptus-nc is creating a boot floppy (no, I'm not kidding) using grub-mkrescue. That is done in mk-mb-loader [1]. grub-rescue depends on a functional grub-mkimage, and to create bootable content for a "pc" system, that depends on files inside grub-pc (the content of /usr/lib/grub/i386-pc/).

One solution to this would be to provide the contents of /usr/lib/grub/i386-pc in a separate package , and maybe in general all of the /usr/lib/grub/<format> directories. Ie, if there was a package called grub-pc-modules, then eucalyptus-nc could depend on that package and on grub-common (for grub-rescue). That would have the added benefit of not explicitly requiring a bootloader in eucalyptus-nc (for a case where grub-pc wasn't the right boot loader for the host system).

It seems to me that the content of /usr/lib/grub/<dir> is useful of simply being a host's bootloader. It may well make sense to have all of /usr/lib/grub/* installed on a system, but grub not used as the host's bootloader at all.

--
[1] http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/maverick/eucalyptus/devel/annotate/head%3A/tools/mk-mb-loader

[Colin Watson (cjwatson)]

I see that people are asking around on IRC for somebody else to deal with this. Could you please be patient instead until I get back from holiday next week? Getting out of sync with Debian here would be very painful, and Daniel Baumann and I already have plans to put together a new bootloader-common package containing a debconf question so that you can select which (or none) of multiple installed boot loaders owns the MBR. I'm leaning towards this rather than having to more or less double the number of binary packages generated by grub2, but if that turns out not to be good enough to fix eucalyptus' problem then I would like to spend some time thinking about it and have the chance to make a change in consultation with other folks in Debian, since sooner or later d-i is going to need something similar and therefore this needs a considered change that solves the whole problem.

Given the linked script, there should be no reason why you can't abandon your current approach and instead depend on grub-rescue-pc, take the pregenerated rescue floppy image that's already there, and use mtools to insert your loader.img and replacement configuration file. I advised Scott to this effect at the sprint and I haven't seen any explanation of why this wouldn't work.

[Launchpad Janitor (janitor)]

This bug was fixed in the package eucalyptus - 2.0~bzr1224-0ubuntu1

---------------
eucalyptus (2.0~bzr1224-0ubuntu1) maverick; urgency=low

  [ Dave Walker (Daviey) ]
  * New upstream merge, r1224, should fix LP: #610259, #609112, #613033
  * debian/patches/10-disable-iscsi.patch: Removed, we should now be
    supporting iscsi.
  * debian/control: Promoted tgt from Recommends to Depends for
    eucalyptus-sc. (LP: #614503)

  [ Scott Moser ]
  * work around kvm virtio bug with -kernel by using boot floppy LP: #615529
  * remove the listing of dependency on grub-pc for workaround. LP: #613463
 -- Dave Walker (Daviey) <email address hidden> Wed, 11 Aug 2010 13:46:50 +0100

[Scott Moser (smoser)]

@Colin,
  Sorry, I just saw this your comment 2 now.
  The reason I can't use mtools and grub-rescue-pc is that the grub rescue images are ISO9660 filesystem, so they're not writable.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.