Update made kernel unable to mount EFI

My issue is basically this : https://bbs.archlinux.org/viewtopic.php?id=178358

TL;DR After an update which included kernel updates (I use the zen kernel), I think I left my PC on for too long or something, and now boot fails with the message “failed to mount /efi” and “unknown file system type vfat” which is a symptom that there’s a difference between the installed kernel on the EFI and the kernel modules on the hard drive (if I understand it correctly).

I found this where the issue was apparently that the depmod script was not being run after kernel installs.

For me the hook and script seem to be intact, but when I run depmod (in chroot) I get :

[root@EndeavourOS ~]# depmod
depmod: ERROR: could not open directory /usr/lib/modules/6.9.6-arch1-1: No such file or directory
depmod: FATAL: could not search modules: No such file or directory

Here’s the folder in question :

[root@EndeavourOS ~]# ls /usr/lib/modules
6.10.6-arch1-1  6.10.6-zen1-1-zen  6.6.10-arch1-1

As you can see, these are all up to date. I just don’t understand why depmod is looking for older versions. I have tried running depmod 6.10.6-zen1-1-zen which seemed to work but it still didn’t boot.

And here is my EFI (normally mounted in /efi) (I don’t have a bootloader, I use EFISTUB):

[root@EndeavourOS efi]# tree
.
├── aa703f77a36049f4a1bd0d1d235318a4
│   ├── 6.10.6-arch1-1
│   │   ├── initrd
│   │   ├── initrd-fallback
│   │   └── linux
│   └── 6.10.6-zen1-1-zen
│       ├── initrd
│       ├── initrd-fallback
│       └── linux
├── EFI
│   └── Microsoft
│       [windows things]
├── initramfs-linux-zen-fallback.img
├── initramfs-linux-zen.img
├── intel-ucode.img
├── loader
│   └── entries
│       ├── aa703f77a36049f4a1bd0d1d235318a4-6.10.6-arch1-1.conf
│       ├── aa703f77a36049f4a1bd0d1d235318a4-6.10.6-arch1-1-fallback.conf
│       ├── aa703f77a36049f4a1bd0d1d235318a4-6.10.6-zen1-1-zen.conf
│       ├── aa703f77a36049f4a1bd0d1d235318a4-6.10.6-zen1-1-zen-fallback.conf
│       └── nixos-generation-1.conf
└── vmlinuz-linux-zen

Again, nothing here to suggest that kernel installation would have gone wrong. I did reinstall-kernels from chroot several times but that did not change anything.

If anyone has an idea what’s wrong, please tell me. Thanks !

It looks like your efistub isn’t built properly and still contains the old kernel.

The new kernel is properly installed, it just isn’t in your efistub.

This is my efi table :

[root@EndeavourOS /]# efibootmgr --unicode

BootCurrent: 0003

Timeout: 2 seconds

BootOrder: 0002,0001,0000,0003

Boot0000* Windows Boot Manager HD(1,GPT,b8190915-6b3f-4215-aa95-b5f91c074b3d,0x800,0x206c000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI䥗䑎坏S

Boot0001* EndeavourOS-Fallback HD(1,GPT,b8190915-6b3f-4215-aa95-b5f91c074b3d,0x800,0x206c000)/\VMLINUZ-LINUX-ZENroot=UUID=2de28c63-4a4d-43e6-b142-2f8c5ead1067 rw initrd=\intel-ucode.img initrd=\initramfs-linux-zen-fallback.img

Boot0002* EndeavourOS HD(1,GPT,b8190915-6b3f-4215-aa95-b5f91c074b3d,0x800,0x206c000)/\VMLINUZ-LINUX-ZENroot=UUID=2de28c63-4a4d-43e6-b142-2f8c5ead1067 rw quiet splash memmap=1$0x1c80b1c84 initrd=\intel-ucode.img initrd=\initramfs-linux-zen.img

What do I need to change ? Isn’t this made to still work after updates with \VMLINUZ-LINUX-ZEN ? I see no reference to kernel versions…

How are you updating these:

├── initramfs-linux-zen-fallback.img
├── initramfs-linux-zen.img
├── intel-ucode.img
└── vmlinuz-linux-zen

Those aren’t files that EOS is putting there.

Those are files that you must have created somehow.

Also, why are you loading intel-ucode manually? That should already be in the initramfs that dracut creates.

I suspect what you want to do is:

  • Remove kernel-install-for-dracut
  • Install eos-dracut
  • Make sure you don’t have mkinitcpio installed
  • Reinstall your kernel packages.

Alternatively, just switch to the boot manager we provide that takes care of everything for you.

How are you updating these

I don’t know. I did not put them there myself, that’s for sure.

Also, why are you loading intel-ucode manually? That should already be in the initramfs that dracut creates.

I didn’t know that was already included.

What’s the difference between EOS-dracut and kernel-install-for-dracut ?

I don’t have mkinitcpio

kernel-install-for-dracut uses kernel-install(part of systemd-boot) to install your kernels in these locations:

Those are the kernels and initrams that EOS creates by default.

eos-dracut, writes the kernels to /boot using a consistent naming scheme.

Nothing in a default EOS install would write the files you are currently using to boot which is likely why your boot is failing.

Did you recently switch from a different arch-based distro?

No, this was EndeavourOS from the start…

For EFISTUB, I just followed the steps in https://wiki.archlinux.org/title/EFISTUB, which is really just one step : generating the UEFI entries. But it assumes vmlinuz is already there. And this did work until that kernel update so these files would have to have been generated for the previous kernel right ?

Yes. You clearly have files there. You can see them in the above output. However, we don’t generate those. I don’t know how they got there or what you did to put them there.

These files were generated just 4 days ago, but aren’t updated when I reinstall the kernels. This is so strange.

Why would it put them there if my ESP is at /efi ?

Oh yeah, that would be an issue. You would need to remount it at /boot if you want to use that package.

Realistically, is there a reason you aren’t just using the standard systemd-boot setup which would avoid all these issues?

I just don’t think it makes sense to have a bootloader when the UEFI just already does that. I don’t even know why that’s still a standard.

Unless you have knowledge to write your own custom script that automatically rebuilds a initramfs and updates the EFISTUB entry (removing the old entry and creating a new one with correct kernel name, changing boot order) directly on your motherboard without needing a third-party bootloader after every kernel update or installation.

Alright, figured it out. I still have NO IDEA what put those files there before, but I was able to add a hook to generate them on kernel upgrades with dracut by following these instructions.

That’s the thing, you don’t actually need to regenerate the EFI entry because it only points to vmlinuz-linux, which doesn’t have a version in its name. So you only needs to rebuild the initramfs, which this hook does.

Solved !

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.