(Removed [e]lilo@packages.debian.org from Cc) * Colin Watson <cjwatson@debian.org> [Tue Aug 24, 2010 at 04:55:28PM +0100]: > 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 <ben@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. ACK, I'd like something like that as well. > > > 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. FullACK. Sorry for the AOL style mail :) - I just want to express that I fully agree with Colin's wish. It's exactly what I consider interesting for live systems (and chroots) without having to work around any possible dangerous package. regards, -mika-
Attachment:
signature.asc
Description: Digital signature