[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kernel module build error with system image cross-build
From: |
Frank Terbeck |
Subject: |
Re: Kernel module build error with system image cross-build |
Date: |
Tue, 23 Aug 2022 18:57:50 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
I looked into this over the weekend.
Frank Terbeck wrote:
> […] like this:
>
> guix system image --target=arm-linux-gnueabihf
> ~/src/guix/gnu/system/examples/beaglebone-black.tmpl
>
> After a while, this breaks like this:
>
[…]
> guix system: error: build of
> `/gnu/store/lqwjj7fjf235psw2br5i8y10cm22pq4l-disk-image.drv' failed
[…]
> Backtrace:
> 5 (primitive-load "/gnu/store/axmhy07daha215gwbqghh39k7ja?")
> In ice-9/eval.scm:
> 619:8 4 (_ #f)
> 626:19 3 (_ #<directory (guile-user) 7ffff3fd7c80>)
> 293:34 2 (_ #(#<directory (guile-user) 7ffff3fd7c80> #<procedu?>))
> In srfi/srfi-1.scm:
> 586:17 1 (map1 ("omap_hsmmc" "ahci" "usb-storage" "uas" "usbh?" ?))
> In gnu/build/linux-modules.scm:
> 257:5 0 (_)
>
> gnu/build/linux-modules.scm:257:5: kernel module not found "omap_hsmmc"
> "/gnu/store/rslz7zlq11wjnvixzfasyvr4b6rv2m7j-linux-libre-5.18.14/lib/modules"
Yeah, so the build-process here, as far as I can see, works like this:
Build the kernel, then to build the initrd, use the kernel installation
directory. The list of modules is just a list of strings, for which the
system tries to find corresponding ‘.ko’ files in the kernel's module
tree for. If the module can't be found, this is what you end up with.
The ‘beaglebone-black.tmpl’ file is basically just an ‘operating-system’
specification:
(operating-system
;; …
;; This module is required to mount the SD card.
(initrd-modules (cons "omap_hsmmc" %base-initrd-modules))
;; …
)
There's also a ‘beaglebone-black-installation-os’ specification in
‘gnu/system/install.scm’. It uses the deprecated ‘#:extra-modules’ to
add ‘omap_hsmmc’ to its list of initrd-modules. So it'll fail similarly.
Odd. So I took a look at the actual kernel build result. When you check
for ‘omap_hsmmc’ you'll notice that it comes up in ‘modules.builtin’, an
output from ‘kbuild’:
This file lists all modules that are built into the kernel. This is
used by modprobe to not fail when trying to load something builtin.
This would suggest that this feature is not built as a module, but in-
stead is a fixed part of the kernel build. And indeed, looking at the
corresponding ‘.config’ file for the kernel build, you'll find this:
CONFIG_MMC_OMAP_HS=y
…which is the Kconfig option, that controls the inclusion of this fea-
ture. Clearly something changed with time and this setting is no longer
valid. Fair enough. Take it out and you should be golden, right?
Not quite — it'll break again, complaining about another module. The
rest of the modules is take from ‘default-initrd-modules’, which is
identifier-syntax'd to ‘%base-initrd-modules’.
It's value for the ‘arm-linux-gnueabihf’ target is:
ahci, usb-storage, uas, usbhid, hid-generic, hid-apple, dm-crypt,
xts, serpent_generic, wp512, nls_iso8859-1, pata_acpi, pata_atiixp,
isci, virtio_pci, virtio_balloon, virtio_blk, virtio_net,
virtio_console, virtio-rng
Of these, the modules that are available as actual modules:
uas, xts, virtio_pci, virtio_balloon, virtio_blk, virtio_net
Features that are builtin, and thus not available as a ‘.ko’ file:
ahci, usb-storage, usbhid, hid-generic, nls_iso8859-1,
virtio_console
Unavailable features:
hid-apple, dm-crypt, serpent_generic, wp512, pata_acpi, pata_atiixp,
isci, virtio-rng
With all that in mind, I used this specification; mostly based on what's
in ‘beaglebone-black.tmpl’:
#+begin_src scheme
(use-modules (srfi srfi-1)
(gnu)
(gnu bootloader u-boot))
(use-service-modules networking)
(use-package-modules bootloaders screen ssh)
(operating-system
(host-name "bbb-test")
(timezone "Europe/Berlin")
(locale "en_GB.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-beaglebone-black-bootloader)
(targets '("/dev/mmcblk1"))))
(initrd-modules
(map symbol->string
'(uas xts virtio_pci virtio_balloon virtio_blk virtio_net)))
(file-systems (cons (file-system (device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account (name "ft")
(home-directory "/home/ft")
(group "users")
(supplementary-groups '("wheel" "audio" "video")))
%base-user-accounts))
(packages (cons* screen openssh %base-packages))
(services (cons* (service dhcp-client-service-type)
(agetty-service (agetty-configuration (extra-options '("-L"))
(baud-rate "115200")
(term "vt100")
(tty "ttyO0")))
%base-services)))
#+end_src
This builds.
Not sure of it boots, because of course none of my micro-sd cards work.
I'm building a VM image now and will try to see if QEMU can boot the
thing.
Regards, Frank
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
- Re: Kernel module build error with system image cross-build,
Frank Terbeck <=