I pulled down mainline and built it with latest arch config. I was able to successfully boot this new kernel as well, except after logging into userspace I noticed that no kernel modules were loaded. In other words, `lsmod` was empty. This is the workflow that I followed
I initially bootstrapped this machine with the kernel/ramdisk/rootfs from here, where the kernel version as of yesterday is 5.8.0-1.
$this->bbcode_second_pass_code('', 'wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz')
I am doing this work on an x86 (non Arch Linux) machine, so I didn't have a simple way to make the new kernel's initramfs. On a whim tried the one provided for the 5.8.0-1 kernel. And, to my surprise, it booted to userspace.
$this->bbcode_second_pass_code('', '$ uname -a
Linux alarm 5.9.0-rc4-ARCH+ #1 SMP Thu Sep 10 12:57:23 EDT 2020 aarch64 GNU/Linux')
But no kernel modules were loaded, so the only access I had was via serial
$this->bbcode_second_pass_code('', '$ lsmod
Module Size Used by')
What might cause this? I'm not intimately familiar with the depth of ram disks these days. I imagine this could cause issues (e.g. the use of an older ramdisk) if an initial hardware probe is done while still in the ramdisk boot phase and no (matching) modules are found. Followed by no subsequent checking and module loading _after_ the real rootfs is mounted.
In any case, I only intended to use the "old" initramfs to bootstrap this kernel to userspace so I can create a matching one:
$this->bbcode_second_pass_code('', '
$ mkinitcpio -k`uname -r` -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')
So you will note that it reports no modules were added to the image. But the modules exist, of course:
$this->bbcode_second_pass_code('', '$ ls -l /lib/modules/
total 12
drwxr-xr-x 4 root root 4096 Aug 9 02:09 5.8.0-1-ARCH
drwxr-xr-x 3 root root 4096 Sep 10 18:02 5.9.0-rc4-ARCH+
drwxr-xr-x 2 root root 4096 Aug 9 02:08 extramodules-5.8-aarch64')
Naturally, if I supply a bad kernel version the script reports it cannot find such a directory. So it's looking in the right place, at least.
$this->bbcode_second_pass_code('', '$ mkinitcpio -kaaa
==> ERROR: '/lib/modules/aaa' is not a valid kernel module directory')
There are exactly the same number of kernel modules in the 5.8.0 directory than there are in the 5.9.0 directory
$this->bbcode_second_pass_code('', '$ find /usr/lib/modules/5.8.0-1-ARCH/ -name "*.ko.gz" | wc -l
3195')
$this->bbcode_second_pass_code('', '$ find /usr/lib/modules/5.9.0-rc4-ARCH+/ -name "*.ko.gz" | wc -l
3195')
----------
The wiki is pretty clear on the operations for installing a new kernel. In fact, the only thing I had to do differently (since I was doing this from another machine with the target disk mounted) was supply a module directory for installation: https://wiki.archlinux.org/index.php/Kernel/Traditional_compilation#Installation
$this->bbcode_second_pass_code('', '
$ mount /dev/sdc2 /mnt
$ make INSTALL_MOD_PATH=/mnt modules_install')
This appeared to work, otherwise I wouldn't see the new kernel's modules at `/lib/modules/` as I've shown above. Any idea?
What could cause no kernel modules to load at boot?
Does the ramdisk play a role in all initial kernel modules load (not just the ones force-loaded by the conf)?