Updating linux-aarch64 does not lead to a newer kernel

[purejava]

Hi,

I am a little stuck and confused on this. As dynamic resolution for the display failed in my UTM VM after a common kernel update, I noticed that updating linux-aarch64 does not work as expected.

First I though, that mkinitcpio has a problem, as running the hooks shows these error messages:

==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -k 6.8.1-1-aarch64-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: '6.8.1-1-aarch64-ARCH'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [microcode]
==> WARNING: architecture 'aarch64' not supported, skipping hook
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
==> WARNING: Possibly missing firmware for module: 'msm'
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: 'wd719x'
==> WARNING: Possibly missing firmware for module: 'qla1280'
==> WARNING: Possibly missing firmware for module: 'qla2xxx'
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly

But these result from the hook "kms" exiting with 1.

After a sudo pacman -S linux-aarch64 I'd expect to run on a newer kernel after a reboot. The first kernel that was installed on installing the VM from the Archboot ISO image was 6.7.5-1. So until I updated from this kernel version, everything was fine.

When I run sudo pacman -S linux-aarch64 now, it updates to 6.8.1-1, but after a reboot, uname -r still shows 6.7.5-1, kernel modules cannot be loaded and problems arise.

What I am missing here? Does upgrading the kernel require special treatment?

Thanks.

[tpowa]

This sounds like your /boot or /efi is not mounted while you update the kernel.

[purejava]

Well, /boot is, /efi not:

ralph@arch ~ % mount | grep efi     
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
ralph@arch ~ % mount | grep boot
/dev/vda2 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

ralph@arch ~ % cat /etc/fstab 
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# DEVICE DETAILS: /dev/vda2 PARTUUID=760d5a71-4edc-4f7c-8c1c-2880ba13cb2f PARTLABEL= UUID=69F0-6220 LABEL=NONE
# DEVICE DETAILS: /dev/vda3 PARTUUID=9adabfb2-dee4-4d44-a353-944ed79899cc PARTLABEL= UUID=05b9aa23-f122-42de-af4b-510eb2479b5b LABEL=arch
PARTUUID=760d5a71-4edc-4f7c-8c1c-2880ba13cb2f /boot vfat defaults 0 1
share /mnt/share 9p  trans=virtio,version=9p2000.L,rw,_netdev,nofail 0 0

ralph@arch ~ % mount           
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=4019368k,nr_inodes=1004842,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/vda3 on / type ext4 (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2654)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/vda2 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
share on /mnt/share type 9p (rw,relatime,access=client,trans=virtio,_netdev)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=812092k,nr_inodes=203023,mode=700,uid=1000,gid=984)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=984)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=984)

[purejava]

It's single boot (a VM). Maybe no /efi then?

And it is EFISTUB.

[tpowa]

Yes that is your issue, if you update your kernel you need to copy initrd and kernel to efi partition. Archboot installer should have added a pacman hook that takes care of it. If you have not mounted /efi this hook will fail. If you installed manually you need to add this it's documented in the arch wiki.

[tpowa]

Ok looked at your output, your filesystems are correct mounted, then it can only be the bootloader that loads the wrong kernel from /boot

[purejava]

Thank you @tpowa for your immediate help!

I installed a new Archboot VM that does not show the issue.

Differences to the VM showing the issue are:

• issue VM was built from an "2.2 UKIs - Unified Kernel Images" ISO, the new VM from an "2.1 ISOs - USB / CD / Virtual Machine" ISO
• on issue VM "update --full-system" was not issued after finishing the installation wizzard
• the new VM has systemd-boot

I don't know if you have a Macbook and UTM available, but I uploaded the issue VM, in case you are interested in taking a look. I deleted my personal data before uploading the VM and created a new user.

I'll send you the URL and credentials via E-Mail. No obligation is associated with this, just in case.

[coquizen]

Uncertain if related to this issue, but I have a similar set up to @purejava. Installation goes without a hitch. However, after

1. initrd-aarch64.img from Ramdisk parameter in UTM
2. add console=hvc0 root=/dev/vda4 to boot arguments
3. boot

I noted that the installed kernel does not have modules for virtio (so can't use virtio_net to connect the VM to the network. Should i have also removed the Kernel Image parameter? and chose UEFI as a bootloader? If so, I believe the problem cause the VM to not boot.

@purejava: can you share the link to the working VM?

[tpowa]

Sure if the virtio drivers are missing it cannot work with /dev/vdX then your hd is /dev/sdX, better you use UUID for your device.

[purejava]

@purejava: can you share the link to the working VM?

@coquizen There is no VM to download. I downloaded an ISO image from here and started the contained installation wizzard / installer to create the VM myself.

[coquizen]

I installed again using the iso instead of the kernal/ramdisks and still came across thes same problem. Even though it shouldn't have been necessary, I also pacman -S linux-headers.

Did you have any issues with linux modules not being installed? Specifically virtio_net? While I was able to connect during install, upon booting straight to the install, the module couldn't be found. However, i am able to access /dev/vdax devices.

[purejava]

No, I did not experience such problems.

[coquizen]

So as it turns out, it was because the udev hook was not specified in mkinitcpio.conf by default. Inserting it before autodetect resolved the issue.

[tpowa]

Closing this, I don't think it is still valid anymore.

[tpowa]

See above.