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

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

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.

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

@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.

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.

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.