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

Bug#1036589: hw-detect: Investigate expanding virtualization detection

Cyril Brulebois <kibi@debian.org> (2023-05-23):
> This means a few additions compared to our detect_virt_dmi_entry()
> function. That being said, we're talking about a finish-install script,
> which tries to run systemd-detect-virt inside target, which is part of
> systemd. So in the general case, we shouldn't have to rely on our
> fallback…

Except I lost track of the reason why I was looking at this in the first
place: #1036523.

CPU microcode support is implemented via two steps:
 - detect whether installing is needed based on CPU information, queue
   installation and enable non-free-firmware accordingly (so that it
   can be picked up via apt-setup, so that we can install the queued
   package and its dependencies — see iucode stuff, we aren't talking
   about self-contained firmware packages here);
 - install the package via finish-install.

The finish-install script knows about virtualization so could skip the
queued installation, but in case there were no other reasons to enable
non-free-firmware, we would have still have that component active…

If we were to move virtualization code to some “shell library” that
could be used from both call sites, the former would be less likely (but
I didn't check at the moment) to have the relevant systemd bits in place
so the fallback mapping might be important.

Also, the current implementation mounts and unmounts some filesystems,
so this could have some side effects if we were to use that in the first
call site as well.

All of this reinforces my initial assessment: it seems safest to
investigate this once the trixie release cycle opens, then consider
backports via a point release if relevant.

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

Attachment: signature.asc
Description: PGP signature

Reply to: