You are not logged in.
I get the following error after performing pacman -Syu which involved updating Linux. Everything (The usual "Give root password for maintenance or press Ctrl+D to continue) gets frozen after and I had to boot from live USB and mount my partition arch-chroot into /mnt and install the Linux to fix the issue. The problem is, I encountered this problem the last three times I updated and I can't figure out what is broken given that I don't have much expertise about this, so I was wondering if anyone can help?
More details:
when I mount my partition from the live USB before reinstalling the linux kernel, I can see that the running kernel does not match the installed kernel
uname -a
gives
Linux archiso 5.11.16-arch1-1
but
pacman -Q linux
gives
Linux 5.14.10.arch1-1
here is the output of lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashfs 4.0 0 100% /var/lib/snapd/snap/core/9665
loop1 squashfs 4.0 0 100% /var/lib/snapd/snap/odrive-unofficial/2
nvme0n1
├─nvme0n1p1 vfat FAT32 BCF4-5195 8M 92% /boot
├─nvme0n1p2
├─nvme0n1p3 ntfs 6E3B001D3AFFE04F
├─nvme0n1p4 ntfs 32BAFCA5BAFC672F
├─nvme0n1p5 ext4 1.0 a1b0ab39-0c52-4cf5-b976-3a28829a5907 383.5G 52% /
└─nvme0n1p6 ntfs Shared B64A1DB74A1D7579 26.6G 15% /home/Linux_Windows
and my /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p5
UUID=a1b0ab39-0c52-4cf5-b976-3a28829a5907 / ext4 rw,relatime 0 1
# /dev/nvme0n1p1
UUID=BCF4-5195 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
#/swapfile none swap defaults 0 0
#UUID=1ADC8962DC893951 /mnt/1ADC8962DC893951 auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/nvme0n1p6 /home/Linux_Windows auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=myname /mnt/myname auto nosuid,nodev,nofail,noauto,x-gvfs-show 0 0
LABEL=someothername /mnt/someothername auto nosuid,nodev,nofail,noauto,x-gvfs-show,ntfs 0 0
I had installed Windows on the other partition prior to installing arch on nvme0n1p5 if that is related. I understand that I must have done something incorrectly and have broken everything but I can't figure out what is wrong from searching this problem online, though I read a few similar topics that I thought are relevant.
Last edited by rumirakhsha (2022-01-14 00:33:36)
Offline
From the live environment with only the system's root file system mounted to /mnt what is the output of `file /mnt/boot/vmlinuz-linux` then mount the system's /boot and execute the command again.
Last edited by loqs (2021-10-10 21:18:29)
Offline
Thanks for helping and sorry for the long delay, I had to wait for a new kernel update to be able to reproduce the issue. You are right the kernel versions are different; if I only mount the root file system with
mount /dev/nvme0n1p5 /mnt
Then file /mnt/boot/vmlinuz-linux is 5.14.16-arch1-1
But after I mount the system boot via
mount /dev/nvme0n1p1 /mnt/boot/
Then file /mnt/boot/vmlinuz-linux gives 5.15.2-arch1-1
5.15.2 is the one that was just released, and I installed with pacman -Syyu
Offline
The system's boot loader is not using the kernel from /boot but the one from the boot directory of the root filesystem.
You can either stop using a separate /boot filesystem or reconfigure the boot loader.
Offline
Thank you, so would something like this
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
be the correct approach?
I am reading the instruction from here . Should I do the grub-mkconfig part after each kernel update then?
Last edited by rumirakhsha (2021-11-13 03:29:42)
Offline
You only need to perform the commands once. Once grub is loading the kernel from the ESP you can unmount it and remove the no longer used files in the boot directory.
Last edited by loqs (2021-11-13 03:55:58)
Offline
The reason you lose the ability to boot after a kernel upgrade is because your bootloader is holding onto an old kernel and always booting that. After you upgrade the linux package, and reboot, your old kernel loads. It then looks for its modules in /usr/lib/modules and can't find them, because they were removed and replaced with the modules appropriate for the new kernel when you updated the linux package. Without its modules, the kernel is crippled and can't do very much, except for open a recovery shell.
You just need to tell grub to look for the kernel where the updated kernel is placed, which is usually at /boot/vmlinuz-linux when the system is running. Once you have done this, nothing will need manually changing on further upgrades. And don't forget to delete that old kernel that is still hanging around somewhere, after you're no longer booting from it, otherwise it'll (harmlessly) hang around forever.
Last edited by PBS (2021-11-13 04:37:21)
Offline
Thank you very much @logs and @PBS,
For anyone with a similar issue, I confirm that the solution discussed above and reconfiguring the bootloader fixed the issue. I just updated the new Linux kernel and everything is working as expected.
Offline
The reason you lose the ability to boot after a kernel upgrade is because your bootloader is holding onto an old kernel and always booting that. After you upgrade the linux package, and reboot, your old kernel loads. It then looks for its modules in /usr/lib/modules and can't find them, because they were removed and replaced with the modules appropriate for the new kernel when you updated the linux package. Without its modules, the kernel is crippled and can't do very much, except for open a recovery shell.
You just need to tell grub to look for the kernel where the updated kernel is placed, which is usually at /boot/vmlinuz-linux when the system is running. Once you have done this, nothing will need manually changing on further upgrades. And don't forget to delete that old kernel that is still hanging around somewhere, after you're no longer booting from it, otherwise it'll (harmlessly) hang around forever.
This very discussion got me saved during this upgrade! ?
Offline