linux-libre-arm64-generic with %base-initrd-module => kernel module not found "ahci"

  • Open
  • quality assurance status badge
Details
2 participants
  • Richard Sent
  • Tom Fitzhenry
Owner
unassigned
Submitted by
Tom Fitzhenry
Severity
normal
T
T
Tom Fitzhenry wrote on 11 Jun 2022 16:13
(address . bug-guix@gnu.org)
87o7yze19b.fsf@tom-fitzhenry.me.uk
When building linux-libre-arm64-generic with %base-initrd-modules, the
linux-modules derivation fails with `kernel module not found "ahci"'.

Here's the steps to reproduce:

Toggle snippet (41 lines)
$ cat minimal.scm
(use-modules
(gnu packages linux)
(gnu bootloader)
(gnu bootloader grub)
(gnu system file-systems))

(operating-system
(host-name "foobar")
(timezone "Australia/Sydney")
(locale "en_AU.utf8")
(bootloader (bootloader-configuration
(bootloader grub-efi-removable-bootloader)
(targets '("/boot/efi"))))
(kernel linux-libre-arm64-generic)
(file-systems (cons* (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
(file-system
(device (file-system-label "boot"))
(mount-point "/boot/efi")
(type "vfat"))
%base-file-systems)))
$ guix time-machine --commit=a99015c8783eb5281618173779a0550b15a79617 --
system reconfigure minimal.scm
$ zcat /var/log/guix/drvs/f3/2ljaayhsdlza6napn6d62ra1x5cm5f-linux-modules.drv.gz
Backtrace:
5 (primitive-load "/gnu/store/bpaj7mfbws69b7pfwrdl7dw5pzs?")
In ice-9/eval.scm:
619:8 4 (_ #f)
626:19 3 (_ #<directory (guile-user) 5ebc80>)
293:34 2 (_ #(#<directory (guile-user) 5ebc80> #<procedure loo?>))
In srfi/srfi-1.scm:
586:17 1 (map1 ("ahci" "usb-storage" "uas" "usbhid" "hid-gene?" ?))
In gnu/build/linux-modules.scm:
257:5 0 (_)

gnu/build/linux-modules.scm:257:5: kernel module not found "ahci" "/gnu/store/lvdihzd96kwqf31gs37n2b8ykdv1jp07-linux-libre-arm64-generic-5.17.14/lib/modules"

This fails beacuse %base-initrd-modules expects the "ahci" module, but
linux-libre-arm64-generic has that built in[0].

Workarounds for users include:

* use linux-libre-5.17, which has the disadvantage that
linux-libre-5.17 is built from aux-files/linux-libre/*.conf rather
than defconfig, thus making it less clear how much linux-libre-5.17
has deviated from mainline's defconfig.
* don't use %base-initrd-modules, which has the disadvantage that users
have to figure out which modules should be in their initrd
* disabling the check (?), which has the disadvantage that the check can be useful

Ideally users could use linux-libre-arm64-generic with
%base-initrd-modules. To do this, we could:

* replace "CONFIG_SATA_AHCI=m" with "CONFIG_SATA_AHCI=y" in
gnu/packages/aux-files/linux-libre/*.conf .
* remove "ahci" from %base-initrd-modules

This amounts to converging aux-files/linux-libre/* towards the mainline
defconfigs. Is this a goal?

Thoughts?

R
R
Richard Sent wrote on 23 May 21:03 +0200
Re: Converging aux-files/linux-libre/* towards mainline defconfigs
(address . 55909@debbugs.gnu.org)
87jzjkuz8v.fsf@freakingpenguin.com
I would be in favor of building more initrd modules into the kernel when
done so upstream. To my understanding the distinction between
linux-libre and linux-libre-*-generic is to have both:

a) A kernel with options that support the various Guix services OOTB,
such as CONFIG_BINFMT_MISC and qemu-binfmt-service-type.

b) A kernel that matches upstream defconfigs as much as possible, with
the exception of a subset of flags considered essential. See
%default-extra-linux-options or linux-libre-riscv64-generic.

With this model, linux-libre should avoid diverging from upstream
defconfigs whenever possible, particularly when toggling a module from y
to m. linux-libre would become a superset of *-generic kernels.

Obviously I'm not packaging linux-libre myself. I might misunderstand
the purpose of these variants. :)

On a related note, the *-generic kernels seem to also have encapsulated
"add support for a specific board on this platform", which to me feels a
bit like a hacky solution. See linux-libre-arm64-generic and the
Pinebook Pro comments. I'd think that would belong in a
linux-libre-pinebook-pro or similar.

--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 55909@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 55909
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch