[Solved] Problems with Refind when updating Kernel

FriedrichNietzsche · 2021-03-17 06:55:46

Hi guys, I need your help!

I have been using Refind on my workstation since quite some while now and it always worked and still works nicely. Now I did a fresh install of Arch on my Matebook Pro with the same setup and for some reason Refind is not able to boot the OS anymore when I update the kernel. So basically: I install the system - everything works fine and boots. When I install the kernel update to the most recent kernel and reboot the system, I will be greeted with following error message:

Warning: /lib/modules/5.11.6-zen1-1-zen/modules.devname not found - ignoring
mount: /new_root/ unknown filesystem type 'btrfs'.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off

I am using a BTRFS filesystem with two subvolumes @ (root filesystem) and @home (home filesystem). My EFI partition is mounted at /boot/efi

NAME        FSTYPE UUID                                 MAJ:MIN RO RM   SIZE TYPE MOUNTPOINT LABEL
nvme0n1                                                 259:0    0  0 238.5G disk            
├─nvme0n1p1 vfat   E8DA-ED68                            259:1    0  0   512M part /boot/efi  EFI
├─nvme0n1p2 swap   e203c14f-1b70-4b2f-b0d7-65db8f401bfd 259:2    0  0     8G part [SWAP]     SWAP
└─nvme0n1p3 btrfs  8bb7876d-6a38-4118-8cbd-b2fca0efdda8 259:3    0  0   230G part /home      ARCH

The whole thing looks like this:

tree /boot
/boot
├── efi
│   └── EFI
│       ├── refind
│       │   ├── BOOT.CSV
│       │   ├── drivers_x64
│       │   │   └── btrfs_x64.efi
│       │   ├── icons
│       │   │   ├── [shortened]
│       │   ├── keys
│       │   ├── refind.conf
│       │   ├── refind_x64.efi
│       │   ├── themes
│       │   │   └── [shortened]
│       │   └── vars
│       │       └── PreviousBoot
│       └── tools
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── initramfs-linux-zen-fallback.img
├── initramfs-linux-zen.img
├── intel-ucode.img
├── refind_linux.conf
├── vmlinuz-linux
└── vmlinuz-linux-zen

My refind_linx.conf:

Boot using standard options"  "root=PARTUUID=86de4d90-c7a8-464e-a095-37c882c33372 rw rootflags=subvol=@ quiet splash loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0 net.ifnames=0"

So what is going wrong? And why don't I have this problem on my workstation, even though it using the exact same setup (I wrote myself a script doing the setup).

Thanks

Last edited by FriedrichNietzsche (2021-03-18 15:05:18)

ponyrider · 2021-03-17 08:18:04

your root partition has a different UUID:

nvme0n1p3 btrfs 8bb7876d-6a38-4118-8cbd-b2fca0efdda8 259:3 0 0 230G part /home ARCH
Boot using standard options" "root=PARTUUID=86de4d90-c7a8-464e-a095-37c882c33372 rw rootflags=subvol=@ quiet splash loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0 net.ifnames=0"

FriedrichNietzsche · 2021-03-17 08:45:54

Good point. I thought it came from lsblk not being able to handel btrfs subvolumes but now i had a look.

For linux_refind.conf I am taking the partuuid which is:

ls -lah /dev/disk/by-partuuid 
total 0
drwxr-xr-x 2 root root 100 Mar 17 09:22 .
drwxr-xr-x 8 root root 160 Mar 17 09:22 ..
lrwxrwxrwx 1 root root  15 Mar 17 09:22 86de4d90-c7a8-464e-a095-37c882c33372 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root  15 Mar 17 09:22 d8738264-477d-458c-9cfe-53dbbe327bd5 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root  15 Mar 17 09:22 e215c72d-4ac7-4cb4-b0fd-554877e3731d -> ../../nvme0n1p1

which is apparently different from the "normal" uuid:

ls -lah /dev/disk/by-uuid    
total 0
drwxr-xr-x 2 root root 100 Mar 17 09:22 .
drwxr-xr-x 8 root root 160 Mar 17 09:22 ..
lrwxrwxrwx 1 root root  15 Mar 17 09:22 8bb7876d-6a38-4118-8cbd-b2fca0efdda8 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root  15 Mar 17 09:22 E8DA-ED68 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root  15 Mar 17 09:22 e203c14f-1b70-4b2f-b0d7-65db8f401bfd -> ../../nvme0n1p2

And for the sake of completeness also my fstab:

cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p3 LABEL=ARCH
UUID=8bb7876d-6a38-4118-8cbd-b2fca0efdda8       /               btrfs           rw,nodev,noatime,compress=lzo,ssd,discard

# /dev/nvme0n1p3 LABEL=ARCH
UUID=8bb7876d-6a38-4118-8cbd-b2fca0efdda8       /home           btrfs           rw,nodev,noatime,compress=lzo,ssd,discard

# /dev/nvme0n1p1 LABEL=EFI
UUID=E8DA-ED68          /boot/efi       vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,sh

# /dev/nvme0n1p2 LABEL=SWAP
UUID=e203c14f-1b70-4b2f-b0d7-65db8f401bfd       none            swap            defaults        0 0

# network shares
nas.lan:/export/files                           /srv/files      nfs             defaults,soft,noatime,nofail,rw         0
nas.lan:/export/backup                          /srv/backup     nfs             defaults,soft,noatime,nofail,rw         0

So using the partuuid is wrong?

Last edited by FriedrichNietzsche (2021-03-17 08:51:17)

progandy · 2021-03-17 09:03:23

mount: /new_root/ unknown filesystem type 'btrfs'.

Is the btrfs kernel module available in the new initramfs image?

FriedrichNietzsche · 2021-03-17 09:27:14

I would guess so.

In /etc/mkinitcpio.conf I am including /usr/bin/btrfsck in BINARIES, but not the btrfs hook in HOOKS, since according to the wiki (https://wiki.archlinux.org/index.php/mkinitcpio) it is not needed, if I don't use btrfs on more than a single drive.

Last edited by FriedrichNietzsche (2021-03-17 09:31:02)

d_fajardo · 2021-03-17 09:40:00

So using the partuuid is wrong?

No but you have to choose what you will use UUID or PARTUUID. Either will work with rEFInd:

ls /dev/disk/by-uuid
ls /dev/disk/by-partuuid

And then tell rEFInd what you use i.e. root=UUID=... or root=PARTUUID=...

In /etc/mkinitcpio.conf I am including /usr/bin/btrfsck in BINARIES

Why add to the BINARIES? Just add btrfs to the MODULES list in mkinitcpio.conf.

MODULES=(... btrfs)

FriedrichNietzsche · 2021-03-17 09:50:42

Included btrfs to MODULES. Didn't help. Would have been weird anyway, since it was never needed so far ...

progandy · 2021-03-17 10:13:09

Warning: /lib/modules/5.11.6-zen1-1-zen/modules.devname not found - ignoring

That file should be part of the initramfs as well.
I have a sneaking suspicion for some reason the initramfs and the kernel are out of sync on your boot device, the new kernel tries to load an old initramfs and therefore cannot load the btrfs module.

d_fajardo · 2021-03-17 10:19:23

Included btrfs to MODULES.

Did you regenerate mkinitcpio after the changes?

FriedrichNietzsche · 2021-03-17 10:59:13

d_fajardo wrote:

Included btrfs to MODULES.
Did you regenerate mkinitcpio after the changes?

Yes. No problem or suspicious messages

Last edited by FriedrichNietzsche (2021-03-17 10:59:51)

d_fajardo · 2021-03-17 11:44:48

@FriedricheNietszche I forgot to ask, have you installed the btrfs_x64.efi driver and copied it to your esp partition?
https://wiki.archlinux.org/index.php/RE … ot_support

FriedrichNietzsche · 2021-03-17 12:21:59

According to the treeview above it's included in /boot/efi/EFI/refind/drivers_x64

d_fajardo · 2021-03-17 12:47:19

According to the treeview above it's included in /boot/efi/EFI/refind/drivers_x64

Yes apologies, I missed that.

d_fajardo · 2021-03-17 13:31:02

Another thing I can think of is have you allowed kernel auto detection on a Btrfs subvolume?

esp/EFI/refind/refind.conf
...
also_scan_dirs +,subvolume/boot
...

FriedrichNietzsche · 2021-03-17 13:54:00

This config option looks like following on my system:

also_scan_dirs @/boot

FriedrichNietzsche · 2021-03-17 15:34:18

progandy wrote:

Warning: /lib/modules/5.11.6-zen1-1-zen/modules.devname not found - ignoring
That file should be part of the initramfs as well.
I have a sneaking suspicion for some reason the initramfs and the kernel are out of sync on your boot device, the new kernel tries to load an old initramfs and therefore cannot load the btrfs module.

I now had a look in the emergency shell. I think it is provided the initramfs? Doing a uname -r shows me that it is using the new 5.11-6 ramfs. It is not able to mount the btrfs partition though. So I also think now, that rEFInd is actually working fine, but that there is a weird problem with the initramfs.

progandy · 2021-03-17 15:50:00

uname -r shows the version of the booted kernel, it doesn't mean the initramfs was built for that kernel.
Check the name of the directory in /usr/lib/modules for the initramfs version (in the emergency shell).
In a normal boot you can maybe compare

lsinitcpio /boot/initramfs-linux-zen.img | grep modules.devname
file /boot/vmlinuz-linux-zen

Last edited by progandy (2021-03-17 15:50:57)

FriedrichNietzsche · 2021-03-17 16:04:54

The folder name is 5.11.6-arch1-1

Edit: As an additional info: I also tried to mount boot in the emergency shell. Also vfat is among the unknown filesystems. So its not just btrfs related

Edit2: I copied the initramfs from my workstation (which has a similar setup) to my laptop. It worked flawlessly and the machine booted. So its definately the initramfs.

Last edited by FriedrichNietzsche (2021-03-17 16:37:37)

d_fajardo · 2021-03-17 16:51:07

The folder name is 5.11.6-arch1-1

I would think the folder should be named 5.11.6-zen1-1-zen? No?

FriedrichNietzsche · 2021-03-17 18:04:32

You, Sirs, were both on the right track! Thanks! The folder is indeed the one from the linux (vanilla) kernel. For now I ditched the nivida package so that I was able to uninstall the linux vanilla kernel. After rebuilding the initramfs the laptop was able to boot on its own.

Now I also have realized that rEFInd was always only offering me one boot option even though I had two kernels and two ramfs installed. I would have guessed, that it picks up every initramfs in the folder?

Anyway the vanilla kernel is there by an accident. It got pulled by the nvidia package as dependecy, I didn't know until today that it was installed. Meh.

progandy · 2021-03-17 18:33:37

refind has some issues with kernels without version numbers. I think refind could do a better job here matching kernel and initramfs, but I have no interest in trying to improve it since I use either efistub or systemd-boot.

https://www.rodsbooks.com/refind/linux.html wrote:

A kernel whose filename lacks a version string matches an initial RAM disk that also lacks a version string in its filename. Note that you can reliably use only one kernel and initial RAM disk per directory that lack version numbers in their filenames.

FriedrichNietzsche · 2021-03-18 08:07:33

For me its no problem, now that I know it. Thanks to all of you guys for your help and dedication!

Arch Linux

#1 2021-03-17 06:55:46

[Solved] Problems with Refind when updating Kernel

#2 2021-03-17 08:18:04

Re: [Solved] Problems with Refind when updating Kernel

#3 2021-03-17 08:45:54

Re: [Solved] Problems with Refind when updating Kernel

#4 2021-03-17 09:03:23

Re: [Solved] Problems with Refind when updating Kernel

#5 2021-03-17 09:27:14

Re: [Solved] Problems with Refind when updating Kernel

#6 2021-03-17 09:40:00

Re: [Solved] Problems with Refind when updating Kernel

#7 2021-03-17 09:50:42

Re: [Solved] Problems with Refind when updating Kernel

#8 2021-03-17 10:13:09

Re: [Solved] Problems with Refind when updating Kernel

#9 2021-03-17 10:19:23

Re: [Solved] Problems with Refind when updating Kernel

#10 2021-03-17 10:59:13

Re: [Solved] Problems with Refind when updating Kernel

#11 2021-03-17 11:44:48

Re: [Solved] Problems with Refind when updating Kernel

#12 2021-03-17 12:21:59

Re: [Solved] Problems with Refind when updating Kernel

#13 2021-03-17 12:47:19

Re: [Solved] Problems with Refind when updating Kernel

#14 2021-03-17 13:31:02

Re: [Solved] Problems with Refind when updating Kernel

#15 2021-03-17 13:54:00

Re: [Solved] Problems with Refind when updating Kernel

#16 2021-03-17 15:34:18

Re: [Solved] Problems with Refind when updating Kernel

#17 2021-03-17 15:50:00

Re: [Solved] Problems with Refind when updating Kernel

#18 2021-03-17 16:04:54

Re: [Solved] Problems with Refind when updating Kernel

#19 2021-03-17 16:51:07

Re: [Solved] Problems with Refind when updating Kernel

#20 2021-03-17 18:04:32

Re: [Solved] Problems with Refind when updating Kernel

#21 2021-03-17 18:33:37

Re: [Solved] Problems with Refind when updating Kernel

#22 2021-03-18 08:07:33

Re: [Solved] Problems with Refind when updating Kernel

Board footer