Re: Kernel module build error with system image cross-build

[Frank Terbeck]

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