I already found out how to fix the problem in a chroot environment:
reinstall kernel
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…
The system just freezes, so I can’t login, but I do have a journal from last boot now after having the system fixed: https://0x0.st/HzmB.txt
Though I don’t think it has any relevant information
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: https://0x0.st/HzBC.txt
Obviously there is a problem with the kernel modules
But you have to find something. 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.
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 )
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.
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:
@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?
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.