* Ben Hutchings <ben@decadent.org.uk> [Tue Aug 24, 2010 at 03:45:36PM +0100]: > On Tue, 2010-08-24 at 16:24 +0200, Michael Prokop wrote: > > * Ben Hutchings <ben@decadent.org.uk> [Tue Aug 24, 2010 at 03:09:06PM +0100]: > > > On Tue, 2010-08-24 at 14:54 +0100, Colin Watson wrote: > > > > Consider building a filesystem image inside a chroot which one is about > > > > to build into a live filesystem image with mksquashfs or something. In > > > > the event that it contains flash-kernel, then the flash-kernel hook > > > > (once such a thing exists; in the meantime, the hardcoded flash-kernel > > > > code in run_bootloader) will write to the host system's flash memory. > > > > (Take another similar example if you disagree with the precise details > > > > of this one; LILO may well have similar properties.) > > > If the live filesystem image includes a boot loader package with a > > > kernel or initramfs hook, you're already running the risk of breaking > > > the user's machine by installing a boot loader they never wanted. > > > Protecting the build machine only hides the problem. > > So what's the proper way to disable the kernel or initramfs hook in > > your opinion? > You're asking the wrong question here. > What I think you want to know is 'how do I make sure that the boot > loader is not installed where it's not wanted'. The obvious answer is > 'don't install the package'. The user needs to configure it, in any > case, and why not let them do that through the usual package > configuration mechanism i.e. debconf? > 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? 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? regards, -mika-
Attachment:
signature.asc
Description: Digital signature