Arch Linux

sherrellbc

Member

Registered: 2014-05-26

Posts: 112

[SOLVED] Issues generating ramdisk for new kernel

I recently pulled download mainline (5.9.0-rc4) and built it using an Arch config (5.8.0-1). Of course there were new options, but they seemed pretty benign. I was consulting instructions from the wiki along the way. In general the build is simple, just as with any distribution. The trouble came when I was trying to build the initramfs for the new kernel:

$ mkinitcpio -k5.9.0-rc4-ARCH+ -g /boot/initramfs-linux-5.9.0-rc4.img
==> Starting build: 5.9.0-rc4-ARCH+
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [keyboard]
  -> Running build hook: [fsck]
==> WARNING: No modules were added to the image. This is probably not what you want.
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-5.9.0-rc4.img
==> Image generation successful

I proceeded anyway to validate my kernel build, which worked. I was able to boot fully into userspace. But when there I noticed that no kernel modules were loaded (`lsmod` was empty). I suspected the ramdisk issues might have something to do with this. After spending some time looking through the `mkinitcpio` script I tracked down one key difference between generating a build for the currently running version (5.8.0-1):

$ mkinitcpio -k5.8.0-1-ARCH -g /tmp/out.img

And the new version (5.9.0-rc4)

$ mkinitcpio -k5.9.0-rc4-ARCH+ /tmp/out.img

When running the build hook autodetect (in particular `/usr/lib/initcpio/install/autodetect`) I noticed that it was returning a different number of elements in the list between the versions. So I decided to take a peek. And as it turns out, modprobe just was not finding the same number of modules for 5.9.0 as it was for 5.8.0-1. So I got the list of modules for 5.8.0-1 and attempted to find them manually on the cmdline for both versions. Here are a few from the list

hci_uart
panfrost
pwm_fan
dw_wdt
cpufreq_dt
dw_hdmi_cec
dw_hdmi_i2s_audio
efivars
efi_pstore
xhci_plat_hcd

And so I tried to load them for each:

$ modprobe -aRS5.9.0-rc4-ARCH+ dw_wdt
modprobe: FATAL: Module dw_wdt not found in directory /lib/modules/5.9.0-rc4-ARCH+

$ modprobe -aRS5.8.0-1-ARCH dw_wdt
dw_wdt

Odd. So it worked for 5.8.0-1 (and indeed this module is loaded when booting this kernel), but not for 5.9.0. But it _is_ there on the filesystem for both versions:

$ find /lib/modules -name "*dw_wdt*" -type f
/lib/modules/5.9.0-rc4-ARCH+/kernel/drivers/watchdog/dw_wdt.ko.gz
/lib/modules/5.8.0-1-ARCH/kernel/drivers/watchdog/dw_wdt.ko.gz

And as it happens, I can even manually `insmod` it

$ sudo insmod /lib/modules/5.9.0-rc4-ARCH+/kernel/drivers/watchdog/dw_wdt.ko.gz

$ lsmod
Module                  Size  Used by
dw_wdt                 20480  0

So generally the issue seems to be with `modprobe` not properly finding my modules from the new kernel's directory under `/lib/modules`. Am I missing something during install?

Last edited by sherrellbc (2020-09-11 18:51:42)

sherrellbc

Member

Registered: 2014-05-26

Posts: 112

Re: [SOLVED] Issues generating ramdisk for new kernel

I took a look at modprobe under strace to see what it was doing between the two versions. It appeared to not be scanning the directory at all, but rather mmap'ing the contents of the modules* files in each respective directory

openat(AT_FDCWD, "/lib/modules/5.8.0-1-ARCH/modules.dep.bin", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=478965, ...}) = 0
mmap(NULL, 478965, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffa5072000
close(3)                                = 0
openat(AT_FDCWD, "/lib/modules/5.8.0-1-ARCH/modules.alias.bin", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=969322, ...}) = 0
mmap(NULL, 969322, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffa4f85000
close(3)                                = 0
openat(AT_FDCWD, "/lib/modules/5.8.0-1-ARCH/modules.symbols.bin", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=439280, ...}) = 0
mmap(NULL, 439280, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffa4f19000
close(3)                                = 0
openat(AT_FDCWD, "/lib/modules/5.8.0-1-ARCH/modules.builtin.alias.bin", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=58930, ...}) = 0
mmap(NULL, 58930, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffa4f0a000
close(3)                                = 0
openat(AT_FDCWD, "/lib/modules/5.8.0-1-ARCH/modules.builtin.bin", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=29948, ...}) = 0
mmap(NULL, 29948, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffa4f02000
close(3)                                = 0
openat(AT_FDCWD, "/sys/module/dw_wdt/initstate", O_RDONLY|O_CLOEXEC) = 3

The difference with the 5.9.0 version was that it rather prints the failure message after the final operations on `modules.builtin.bin`. I took a peek at those files and there are differences ...

$ grep -rn "dw_wdt" /lib/modules/*/modules.* | grep -v Binary
/lib/modules/5.8.0-1-ARCH/modules.alias:14099:alias of:N*T*Csnps,dw-wdtC* dw_wdt
/lib/modules/5.8.0-1-ARCH/modules.alias:14100:alias of:N*T*Csnps,dw-wdt dw_wdt
/lib/modules/5.8.0-1-ARCH/modules.dep:1852:kernel/drivers/watchdog/dw_wdt.ko.gz:
/lib/modules/5.8.0-1-ARCH/modules.order:1852:kernel/drivers/watchdog/dw_wdt.ko

/lib/modules/5.9.0-rc4-ARCH+/modules.order:1850:kernel/drivers/watchdog/dw_wdt.ko

So .. what could cause this discrepancy in the builds?

In fact, I noticed that both `modules.dep` and `modules.alias` for the new kernel are completely empty files. What could cause this? I feel as if this may be the root issue here.

Last edited by sherrellbc (2020-09-11 18:30:40)

sherrellbc

Member

Registered: 2014-05-26

Posts: 112

Re: [SOLVED] Issues generating ramdisk for new kernel

In fact, I noticed that both `modules.dep` and `modules.alias` for the new kernel are completely empty files. What could cause this? I feel as if this may be the root issue here.

The solution was to manually run `depmod` on the target to generate the dependency and alias (probably among other things) files. I'm not sure where this gets run ordinarily. Perhaps it doesn't for the case where custom kernels are being used. In any case, I had to bootstrap the new kernel using the old ramdisk that (somehow) actually worked. Then run `depmod` and `mkinitcpio` manually to generate a proper ramdisk for the new kernel. Then reboot to use it.

Thanks for the suggestions on IRC.

Last edited by sherrellbc (2020-09-11 18:51:54)