Kernel changes for initramfs generation

[Jeff Bailey]

On mar, 2005-11-29 at 10:48 +0000, Colin Watson wrote:
> That said, what will happen if initramfs-tools and its other
> dependencies are unpacked but not configured? This is quite likely on
> initial installation or on upgrades from earlier versions of the
> distribution. Will update-initramfs bomb out (this would be OK) or would
> it generate an incorrect initramfs (this would be rather less good)?

update-initramfs just copies pieces around, so it has no reasonably way
of knowing this.  What happens now?  I suspect most of the pieces
already just cope in some useful way, since mkinitrd was already being
called at some random point - Whenever the kernel was unpacked.

> Also, what is the correct error handling behaviour for postinst scripts
> calling update-initramfs? Should errors from update-initramfs cause the
> postinst to abort, or should they be ignored? The above question is
> relevant here too, since packages that are dependencies of
> initramfs-tools may not be able to generate a correct initramfs yet.

Hmm.  My initial reaction is that failures from u-i should be ignored,
since they most likely just indicate that the user has a custom
initramfs and u-i is being a coward and refusing the break the system.

If each package that has something to do with the initramfs regenerates
it, then by the time everything is unpacked and configured, the
initramfs will be correct.

There could be an issue processing a config file or a hook script which
should result in a more serious failure.  Unless the code has changed
much since I wrote it, that case wasn't trapped.

Tks,
Jeff Bailey