Bug#1036779: finish-install: factorize update-initramfs calls

[Cyril Brulebois]

This isn't going to be fully addressed for Bookworm, or even at all.

Cyril Brulebois  (2023-05-26):
> At the moment, and only looking at our packages, there are several
> finish-install hooks that might trigger an update-initramfs call:
>  - hw-detect might deploy a CPU microcode package;

There's actually an explicit u-i call here, but only to adjust a
modprobe blacklist, in some Oracle-related code path.

The u-i call via microcode installation, directly from their postinst
script, so we couldn't really skip them, unless we were to cheat and
temporarily make /usr/sbin/update-initramfs -x (which seems fragile).

So this part wouldn't benefit directly from this factorization.

> Additionally, due to #1036019, one might get a garbled LUKS prompt, and
> I'm considering adding some kind of detection. This would likely be
> along the way of “if bochs or cirrus are loaded, add them to i-t's
> modules and rebuild the initramfs”, making sure the LUKS prompt would be
> readable, and increasing chances of seeing error messages if the boot
> breaks early. First instinct was hw-detect's finish-install script, but
> thinking a bit more and filing the actual report still remain to be
> done.

This is https://bugs.debian.org/1036780 now. It really feels like
hw-detect is a better place than finish-install itself… but maybe I'll
paper over it via a single finish-install tweak for now, and revisit the
whole thing once we implement factorization.

> (Of course, this doesn't change the fact there might be multiple runs
> earlier; I'm only looking at the “final” run, within finish-install's
> realm.)

And as mentioned above, this is also the case when installing
*-microcode packages… :/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1036779: finish-install: factorize update-initramfs calls

[Cyril Brulebois]

Package: finish-install
Severity: important

Hi,

At the moment, and only looking at our packages, there are several
finish-install hooks that might trigger an update-initramfs call:
 - hw-detect might deploy a CPU microcode package;
 - finish-install might detect cryptsetup and console-setup, and “play
   safe” to make sure the selected keymap is available for the LUKS
   prompt at start-up.

I know there's at least open-iscsi-udeb with a similar hook, and we
might have some other packages out there — this is definitely not a
complete survey.

Additionally, due to #1036019, one might get a garbled LUKS prompt, and
I'm considering adding some kind of detection. This would likely be
along the way of “if bochs or cirrus are loaded, add them to i-t's
modules and rebuild the initramfs”, making sure the LUKS prompt would be
readable, and increasing chances of seeing error messages if the boot
breaks early. First instinct was hw-detect's finish-install script, but
thinking a bit more and filing the actual report still remain to be
done.


To avoid update-initramfs calls piling up, I'm tempted to have a
specific file where each package/hook could write a reason for
requesting an update-initramfs call, and finish-install's
10update-initramfs would (1) still perform its own cryptsetup vs.
console-setup detection, queueing a call if needed, (2) look at the
queue, logging reason(s) for the call, and (3) lump all calls together,
only running update-initramfs once.


(Of course, this doesn't change the fact there might be multiple runs
earlier; I'm only looking at the “final” run, within finish-install's
realm.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant