Bug#623577: please allow grub-pc/install_devices_empty warning to be disabled

[Colin Watson]

On Thu, Apr 21, 2011 at 01:31:16PM +0200, Marc Haber wrote:
> as part of an automatic installation process, I would like to install
> grub-pc without installing it anywhere, and non-interactively. This
> doesn't work as grub insists on displaying its
> grub-pc/install_devices_empty warning at critical priority after
> resetting the seen flag. It thus makes sure to disrupt the automatic
> process.
> 
> Please implement a possibility to get grub-pc and its dependencies
> installed non-interactively even without writing the actual grub to
> any disk.

Can you tell me more about how you're doing your automatic install and
what your goals are, so that I can think about how to design this?  Are
you using d-i?  The difficulty has of course always been in
distinguishing intentional preseeding from honest mistakes on answering
the question interactively.  An extra debconf template could do the
trick, but I like to try to avoid even more profusion of debconf
templates if I can avoid it.

I've been thinking about a change which might have the side-effect of
helping you in an entirely different way, but it does depend on the
details of what you're doing.  The common case is certainly that people
install grub-pc (or another of the platform-specific packages) with the
intent that it should be their primary boot loader.  However, there are
two other significant cases I can think of: firstly, there are people
with unusual arrangements for /boot who need to run grub-install and
update-grub manually; and secondly, if you're building disk images and
making them bootable using GRUB, then you need the binaries but don't
necessarily want it to become your primary boot loader.

A solution for this could be to split each of the platform packages
(grub-pc, grub-efi-amd64, etc.) into two: grub-<platform>-bin would ship
the actual images, modules, and tools, but would not do any significant
work in its maintainer scripts; while grub-<platform> would have the
maintainer script complexity it has today, and installing it would
generally imply that it should become the primary boot loader.  You
could then perhaps solve your problem by simply installing grub-pc-bin
rather than grub-pc.

The main wrinkle is that for the disk image case it would be beneficial
for the -bin packages to be coinstallable: for instance, you might
reasonably want to build a dual BIOS/EFI image and so need both
grub-pc-bin and grub-efi-amd64-bin.  Up to now I've been solving this in
my own projects by shipping grub-rescue-efi-amd64 and extracting files
from those rescue images, but this is a hack and I'd prefer a different
approach.  This implies that the -bin packages would need to ship their
conflicting binaries in /usr/lib/grub/<target_cpu-platform>/ rather than
/usr/bin or /usr/sbin, so you'd need to run
/usr/lib/grub/i386-pc/grub-install rather than just grub-install.  Would
this be tolerable?

I may have misunderstood your requirements, so please do explain if this
wouldn't fit your needs; but it would be nice to be able to fix both
problems in one go, seeing as my next grub2 upload is going to need to
go through NEW anyway.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]