Subject: [bug#59003] [PATCH 6/7] installer: Report known-unsupported PCI devices.

From: "pelzflorian (Florian Pelz)" <[email-masked]>
Date: Sat, 05 Nov 2022 18:55:21 +0100

This is great work.

To test, I reverted the (current-guix) patch and instead pointed the
guix package source to (url "/home/florian/src/guix") and doing

GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=y make update-guix-package

so I could test the patch.  I also had to guix pull from a channel with
this local checkout, because

./pre-inst-env guix system image -t iso9660 gnu/system/install.scm

still insists on authenticating

florian@floriandesktop ~/src/guix [env]$ ./pre-inst-env guix system image -t iso9660 gnu/system/install.scm 
;;; compiling /home/florian/src/guix/gnu/system/examples/bare-bones.tmpl
;;; compiled /home/florian/.cache/guile/ccache/3.0-LE-8-4.6/home/florian/src/guix/gnu/system/examples/bare-bones.tmpl.go
;;; compiling /home/florian/src/guix/gnu/system/examples/bare-bones.tmpl
;;; compiled /home/florian/.cache/guile/ccache/3.0-LE-8-4.6/home/florian/src/guix/gnu/system/examples/bare-bones.tmpl.go
;;; compiling /home/florian/src/guix/gnu/system/examples/bare-bones.tmpl
;;; compiled /home/florian/.cache/guile/ccache/3.0-LE-8-4.6/home/florian/src/guix/gnu/system/examples/bare-bones.tmpl.go
Updating channel 'guix' from Git repository at '/home/florian/src/guix/'...
Authenticating channel 'guix', commits 9edb3f6 to 8d31a8c (977 new commits)...
[                                                                              ]guix system: error: commit 8d31a8c042bcedf34d911047c628ee4290f0b3cd lacks a signature

Why does it authenticate?  This is a strange antifeature, but I can’t
tell where in the code the authentication is called.

Anyway, after `guix pull`ing a guix channel with the local checkout,
`guix system image -t iso9660 gnu/system/install.scm` went fine.

I digress.  About the patch:

Ludovic Courtès <[email-masked]> writes:
> Newer laptops are known to require
> non-free firmware a range of devices¹ and it would be nice to
> cover the important ones.
> 
> Thoughts?
> 
> Ludo’.
> 
> ¹ https://blog.einval.com/2022/04/19#firmware-what-do-we-do

In my limited experience, much hardware was always broken.
I don’t have modern hardware with iwlwifi, but my ancient laptop has
broken hardware, namely a SiS 191 Gigabit Ethernet Adapter.

While the adapter can download things with wget, when I use this
Ethernet controller to guix system init, Guix gets stuck immediately,
even though
<https://h-node.org/ethernetcards/catalogue/en/1/1/Silicon-Integrated-Systems-SiS/undef/undef/undef/ethernet-works/undef>
makes the dubitable claim that this Ethernet controller works fine.
Note that I have no issues with USB Ethernet adapters.  Therefore,

> +(define %unsupported-linux-modules
> +  ;; List of Linux modules that are useless without non-free firmware.
> +  '("iwlwifi"))

I added "sis190".  The patch works!  The install image prints:

Devices not supported by free software were found on your computer:

  - Silicon Integrated Systems [SiS] 191 Gigabit Ethernet Adapter
(networking device)

Yay!  Maybe you could add "sis190", maybe it doesn’t matter because it
is so old, maybe it is even just my laptop’s SiS that is broken.

By the way, looking for modern, working consumer wi-fi hardware (I
believe it does not exist), I find Realtek devices on h-node that it
claims are working with aircrack-ng, but recently there was a commit

commit b8f2eb286ec52c97048e23d326d94ae5772797e8
Author: Tobias Geerinckx-Rice <[email-masked]>
Date:   Sun Aug 14 02:00:00 2022 +0200

    gnu: Remove Realtek WiFi drivers with firmware blobs.
    
    rtl8821ce-linux-module contains, e.g., halhwimg8821c_fw.c and
    hal8821c_fw.c.  rtl8812au-aircrack-ng-linux-module has, e.g.,
    hal8814a_fw.c, hal8812a_fw.c, and hal8821a_fw.c.  Each of these
    examples contains non-free firmware blobs disguised as C arrays.
    
    * gnu/packages/linux.scm (rtl8821ce-linux-module)
    (rtl8812au-aircrack-ng-linux-module): Remove variables.
    
    Reported by Jacob K <[email-masked]>

But a warning for these Realtek devices can be added later when someone
actually has such hardware.  That would have been an external module
though.  Anyway, without realtek hardware I cannot judge.

Now, back to the patch:

> +(define unsupported-pci-device?
> +  ;; Arrange to load the module alias database only once.
> +  (let ((aliases (delay (known-module-aliases))))
> +    (lambda (device)
> +      "Return true if DEVICE is known to not be supported by free software."
> […]
> +(define (check-hardware-support pci-database)
> […]
> +  (let ((devices (pci-devices)))
> +    (match (filter unsupported-pci-device? devices)
> +      (()                                         ;no unsupported device
> +       #t)
> +      (unsupported
> +       (run-error-page (format #f (G_ "\
> +Devices not supported by free software were found on your computer:

In my view it would be better to lay the blame on the hardware
manufacturers, because they are the ones who should distribute free
drivers.  That is to turn it around and maybe say:

Devices with no support for free software were found on your computer:

or maybe at least “with” instead of “by”:

"Return true if DEVICE is known to not be supported with free software.

Either way, thank you!

Regards,
Florian