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 <kibi@debian.org> (2023-05-26):

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,