From: Frank Terbeck <ft@bewatermyfriend.org>
To: help-guix@gnu.org
Subject: Re: Kernel module build error with system image cross-build
Date: Tue, 23 Aug 2022 18:57:50 +0200 [thread overview]
Message-ID: <87lereoq29.fsf@ft.bewatermyfriend.org> (raw)
In-Reply-To: <87h732vypw.fsf@ft.bewatermyfriend.org> (Frank Terbeck's message of "Thu, 28 Jul 2022 02:59:39 +0200")
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
next prev parent reply other threads:[~2022-08-23 17:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 0:59 Kernel module build error with system image cross-build Frank Terbeck
2022-08-23 16:57 ` Frank Terbeck [this message]
2022-08-25 8:42 ` pelzflorian (Florian Pelz)
2022-08-25 23:08 ` Frank Terbeck
2022-08-26 14:50 ` pelzflorian (Florian Pelz)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lereoq29.fsf@ft.bewatermyfriend.org \
--to=ft@bewatermyfriend.org \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).