Boot failing after update - Kernel modules not loading?

After I update my system the boot process fails, saying the EFI partition failed to mount, and switches to emergency mode (the pc freezes).

I already found out how to fix the problem in a chroot environment:

  1. reinstall kernel
  2. depmod -a /lib/modules/version (current kernel version)

Running the depmod command right after the system update before rebooting does not help.

This issue occurs after every system/kernel update. I’m not sure what I did before this problem came up since I haven’t used the system for a few weeks…

Great! Did you also follow the system’s suggestion?

Log in as root and check the journal, or continue to default (to check logs and troubleshoot).

FWIW, the reported partitions that fail are not crucial for the system to work in a basic way.

In addition yo what petsam wrote it would be interesting to know what bootmanager you are using.

1 Like

The system just freezes, so I can’t login, but I do have a journal from last boot now after having the system fixed:
Though I don’t think it has any relevant information

I’m using the Refind bootmanager

Will you share how?

I already mentioned that in the first post, reinstalling kernel in chroot and running depmod -a

I now also tried to update the kernel again to see if there are any errors, log is here:
Obviously there is a problem with the kernel modules

Try/install another kernel.

Did try to install current linux-lts and zen kernels, both give the same error when installing

But you have to find something. :person_shrugging: These things do not happen. Do your research in pacman and journal log and add something to the story.

Look into your kernels’ modules folders and see if the lost modules are there, or not.
For example:

# Get path and info from a module
modinfo mtip32xx

# Check paths for files
ls -l /lib/modules/$(uname -r)/kernel/drivers/block/drbd/
ls -l /lib/modules/$(uname -r)/kernel/drivers/block/
ls -l /lib/modules/$(uname -r)/kernel/drivers/

# Get verbose info
sudo mkinitcpio -v -p linux 

When posting terminal output, logs, etc, post complete, and with the input command as well.

1 Like

You’re not making it easy to help you.

Can you, in one post, state clearly what is the problem you’re having right now?

1 Like

Boot live ISO flash or boot any another good arch os ::::: applied only for grub, not for ‘dracut’

Check /dev/sdx1 (vfat32) for the two directory:
/EFI/boot – bootx64.efi
/EFI/endeavouros – grubx64.efi (or whatever os you may have)

Check uuid of /dev/sdx1 and /dev/sdx2 in /etc/fstab
$ edit /etc/fstab (using ‘sudo thunar’ in terminal and using mousepad in ‘sudo thunar’ window)
adjust the correct uuid for sdx1 and sdx2

$ sudo mkdir /boot/efi (if not exists in sdx2, using ‘sudo thunar’ window)

$ sudo mount /dev/sdx2 /mnt

$ sudo arch-chroot /mnt mkinitcpio -p linux (yay -S arch-install-scripts)
$ sudo arch-chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg (check again the uuid in /boot/grub/grub.cfg in ‘sudo thunar’ window)

$ sudo mount /dev/sdx1 /mnt/boot/efi

$ sudo pacman -S grub efibootmgr os-prober (if not exists, install it )

$ sudo grub-install --target=x86_64-efi --bootloader-id=GRUB --boot-directory=/mnt/boot --efi-directory=/mnt/boot/efi --no-nvram --removable

$ reboot

If the reboot still fails, I can only guess the following two directories may be damaged (They are created during installation through hardware detection).
/EFI/endeavouros (/dev/sdx1)
/boot/grub/x86_64-efi (/dev/sdx2)
I have overcome many arch based os’s installation or booting failures, even ever migrated one-partition legacy bios boot to reproduce into two-partition uefi boot in the above same procedure, but the reboot failure now is beyond my help.

Sorry, I will try to describe my problem more precisely with the information I found:

Updating the kernel of my EndeavourOS system using pacman leads to a unbootable system.

During the installation/update process of the kernel the initramfs is re-generated using mkinitcpio.
This is where I think the problem is coming from.
mkinitcpio can’t find any kernel modules (see log of installation) and thus creates a initramfs missing important kernel modules for a bootable system.

I do know how to fix the problem. However, this fix is only temporary and needs to be done every time I update the kernel:
After updating the kernel using pacman before rebooting or in a backup system with chroot (when it is already to late) run:

depmod -a 6.2.1-arch1-1 // or whatever the newest installed kernel name is
mkinitcpio -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img

I don’t know what depmod does, however after running it mkinitcpio can find the modules which were previously missing and my system boots normally next boot.

Seems like all ‘missing’ modules are in lib/modules/…
Output of mkinitcpio -v doesn’t give any useful error messages aside from the ones about missing modules.

It is updating module dependencies. And it seems like either you are lacking the pacman-hook for depmod or it is for some reason not running.

In your installation log it seems like the hook is not executed.

Here in this part

reinstalling linux…
:: Running post-transaction hooks…
(1/3) Arming ConditionNeedsUpdate…
(2/3) Updating linux initcpios…

between Arming ConditionNeedsUpdate... and Updating linux initcpios... there should be the line Updating module dependencies... which indicates that the hook /usr/share/libalpm/hooks/60-depmod.hook is run.
Please check if you have this hook-file.
It should look like that:

Type = Path
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/lib/modules/*/
Target = !usr/lib/modules/*/?*

Description = Updating module dependencies...
When = PostTransaction
Exec = /usr/share/libalpm/scripts/depmod

And as you can see it executes the script /usr/share/libalpm/scripts/depmod which should look like that by default:


while read -r f; do
  if [[ -e ${f}modules.order ]]; then
    depmod $(basename "$f")
  elif [[ -d $f ]]; then
    rm -f "${f}"modules.{alias,alias.bin,builtin.alias.bin,builtin.bin} \
    rmdir --ignore-fail-on-non-empty "$f"

# vim:set ft=sh sw=2 et:

Edit: further information on depmod:


OT has nothing to do with boot failure :wink: .

Really sharp eye!! :+1: Awesome!!

In continuation…

@yuki158 is it possible you left your PC after a broken update, or did a partial update?
Did you run a standard sync, or tried to update only the kernel?


Thank you all! I was able to resolve the issue.

This hook as well as the script didn’t exist. I reinstalled the package kmod and both files have been restored
and the depmod hook now gets executed when installing a kernel.

I think that is likely what might have happened. I will make sure to avoid such situations in the future.

1 Like

Thanks for the reply. Nice that it is working now

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