Cyril Brulebois <k...@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. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
