On Tue, Aug 24, 2010 at 04:08:47PM +0100, Ben Hutchings wrote: > On Tue, 2010-08-24 at 16:55 +0200, Michael Prokop wrote: > > * Ben Hutchings <b...@decadent.org.uk> [Tue Aug 24, 2010 at 03:45:36PM > > +0100]: > > > If you insist on installing such a package in the live system then it > > > needs to support a safe configuration where it won't do anything until > > > the user configures it to. It doesn't matter whether it's invoked by > > > the kernel, initramfs-tools, or anything else. It *must* require user > > > configuration. > > > > Jepp. But isn't this (possibility for user configuration) exactly > > what Colin is requesting? > > No, he was asking for a way to disable hook invocation (which is > something of a blunt tool).
Actually, what I want is a consistent way to disable bootloader invocation for all bootloaders, without necessarily requiring the bootloader package not to be installed (since that's sometimes extremely awkward to arrange). Exactly where this goes I can't say I mind. If the result is an extension to the bootloader/kernel policy that needs to be implemented in each bootloader package, that would be fine too. > > I'm for example shipping lilo and grub with the live system (so the > > binaries as well as its documentation is available to the user), but > > nowadays the build process fails due to errors like: > > > > run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 > > [...] > > run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 > > > > So the IMHO open question is what's a proper way to disable such > > stuff on request? > > Report a bug on lilo; I suppose it should warn but still 'succeed' if > /etc/lilo.conf is missing. elilo should do the same. This is my bug > and I can fix it. :-) No idea about zipl but I doubt you care about > s390 live media. What I specifically do not want is for top-level client programs to have to keep track of the different ways to ensure that each individual bootloader is disabled. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824155518.go12...@riva.ucam.org
