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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
