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. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part