On Tue 06 Apr 2021 at 15:53:43 (+0300), Andrei POPESCU wrote: > On Ma, 06 apr 21, 12:00:53, Brian wrote: > > On Mon 05 Apr 2021 at 23:17:09 +0100, Brian wrote: > > > On Mon 05 Apr 2021 at 22:54:37 +0300, Andrei POPESCU wrote: > > > > On Sb, 27 mar 21, 10:48:43, Brian wrote: > > > > > > > > > > I did previously note the reiteration and acknowledge that video > > > > > hardware could require non-free firmware. However, does a d-i carrying > > > > > such firmware ever make any attempt to install it? As I understand it, > > > > > the installer is designed to probe for and load non-free firmware for > > > > > network hardware only. > > > > > > > > [citation needed] > > > > > > I think I asked my question first. > > My reply was needlessly harsh, though definitely not intended as such. > > I'm still curious where you got the impression that d-i loads firmware > for network hardware only. > > > However, perhaps the hw-detect udeb will shed some light on the matter. > > I'd assume that any firmware package present on the unofficial installer > is meant to be installed by d-i. It also seems much easier to me to just > install any firmware (package) needed than to specifically filter for > network devices only. > > At the moment I don't have the hardware to test any of this though.
I may do, but I had problems installing buster onto a stick (I think it's unreliable) so I don't have installer/syslog to check. I believe the laptop wants i915/kbl_dmc_ver1_04.bin from firmware-misc-nonfree. However, during installation, AFAICT, firmware-misc-nonfree wasn't installed. I think the reason is two-fold in this case. I suspect, without evidence, that the d-i is loading modules in a customised manner (perhaps AVAIL_MODULES in bin/hw-detect), and that it makes do with vga16fb rather than anything fancier, like i915. Secondly, even if i915 were to be loaded, I don't think the d-i could determine that the desired kbl_dmc_ver1_04.bin is actually available in firmware-misc-nonfree (which is on the non-official, firmware-inclusive media). Here's what I think the d-i actually does (very sketchy). The kernel finds bits of hardware and either loads the appropriate modules or hands a list back to the d-i (I'm not sure about that bit). Whenever modules are loaded, the d-i (bin/check-missing-firmware) scans dmesg¹, parses the failure messages in check_missing(), looks up the correct deb in /usr/share/hw-detect/firmware-map (not sure who, exactly, does that), finds it and "installs"² it. Here's a fragment of the (sorted) map³: lib/firmware/i915/bxt_dmc_ver1_07.bin firmware-misc-nonfree non-free lib/firmware/i915/kbl_dmc_ver1.bin firmware-misc-nonfree non-free lib/firmware/i915/kbl_dmc_ver1_01.bin firmware-misc-nonfree non-free lib/firmware/i915/skl_dmc_ver1.bin firmware-misc-nonfree non-free There's no entry for kbl_dmc_ver1_04.bin, so no firmware blob or .deb installation could occur. Sometime I'll get round to installing onto a more reliable device, so I can look in more detail⁴. Unfortunately, as has happened before, I have to preserve a Windows installation on the laptop's internal drive for the time being. ¹ It maintains a record of the timestamps, so it doesn't have to rescan what it's already read; see get_fresh_dmesg(). ² install_firmware_pkg() appears to cache the name of the deb for installing later, unpacks it, copies the firmware, then deletes the deb, thereby preventing installation of any dependencies prematurely. ³ The firmware-map is identical for the official d-i and the non-free firmware-inclusive buster versions, and the alpha3 version of bullseye. ⁴ I haven't yet checked why bin/check-missing-firmware didn't seem to be finding/copying loose firmware files in buster as it did in wheezy. I think the answer should lie in bin/check-missing-firmware. Cheers, David.
