[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Package: finish-install
Severity: important


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

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

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Reply to: