Bug#1036780: hw-detect: detect and add bochs/cirrus to the initramfs

[Cyril Brulebois]

Control: clone -1 -2
Control: reassign -2 finish-install
Control: retitle -2 finish-install: detect and add bochs/cirrus to the initramfs

Cyril Brulebois  (2023-05-26):
> Therefore, I'm considering detecting when bochs.ko and/or cirrus.ko are
> loaded, adding them to /etc/initramfs-tools/modules, and requesting an
> update-initramfs call (see #1036019).

This last reference was meant to be #1036779 instead, which I've just
followed up to. Since there is no easy/quick fix for the reasons
mentioned there, I'm going to:
 - keep -1 against hw-detect for the long term (it still feels better
   to have hw-detect be knowledgeable about HW problems…), once we
   implement factorization.
 - implement -2 in finish-install, and make sure to avoid a double u-i
   run if we happen to have both LUKS and bochs/cirrus.

This means a single upload, keeping track of an extra variable within a
single finish-install script, and coming up with a better long term
solution later.


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


signature.asc
Description: PGP signature

Bug#1036780: hw-detect: detect and add bochs/cirrus to the initramfs

[Cyril Brulebois]

Package: hw-detect
Severity: important

Hi,

This is another expression of the problem I've started documenting in
#1036019: under UEFI/SB, using the std (bochs) or cirrus graphics
drivers leads to corrupted graphics.

[ I'm even able to get a 800×599 resolution via cirrus! ]


I've implemented a workaround in the installer by shipping the two
relevant DRM modules (bochs.ko, cirrus.ko), which makes the install
process itself run fine.

Unfortunately, upon rebooting, since the initramfs doesn't contain
bochs.ko or cirrus.ko by default, the LUKS passphrase prompt is
corrupted as well (efifb, which is built-in, is likely in charge at this
point). Once LUKS has been unlocked, the console becomes readable, and
one can type login and password normally.

The LUKS prompt is worrying on its own, but I'm also worried one might
be missing critical messages, even on non-LUKS systems, if the boot
sequence breaks early.


Therefore, I'm considering detecting when bochs.ko and/or cirrus.ko are
loaded, adding them to /etc/initramfs-tools/modules, and requesting an
update-initramfs call (see #1036019).

The cost/benefit ratio makes it look like a no-brainer to me, but I'm
happy to hear about other opinions.


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