Bug#1036779: finish-install: factorize update-initramfs calls
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 (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Reply to: