EndeavourOS broken after update: missing kernel modules, EFI issues, no WiFi/audio

General system Kernel, boot, graphics & hardware
1

Hey,

after a sudo pacman -Syu on EndeavourOS my system ended up in a pretty broken state and I’m trying to figure out how to recover it.

What happened:

  • update completed without obvious errors

  • after reboot:

    • EFI mount errors (Failed to mount EFI system partition)

    • unstable/partial boots

    • later WiFi completely disappeared

Current symptoms:

  • iwlwifi module missing

  • modprobe iwlwifi → module not found

  • no wireless interface in NetworkManager

  • rfkill doesn’t show expected devices

  • dmesg hints at missing firmware/modules

Kernel state also looks wrong:

  • running kernel: 6.19.13-arch1-1

  • /usr/lib/modules/ contains mixed versions (6.1.x + 7.x leftovers)

  • current kernel modules seem incomplete/mismatched

  • modprobe iwlwifi returns:

modprobe: FATAL: Module iwlwifi not found in directory /lib/modules/6.19.13-arch1-1

Hardware:

  • ThinkPad T480

  • encrypted LUKS setup

  • Intel Wireless-AC 8265

Current situation:

  • system ONLY boots through:
    Boot Menu -> Linux Boot Manager -> GRUB -> EndeavourOS

  • direct “EndeavourOS” EFI entry hangs at:
    A start job is running for /dev/mapper/cryptroot

Additional findings:

  • lsmod | grep iwl → no output

  • dmesg | grep -i iwlwifi → no output

  • aplay -l → no soundcards found

  • NetworkManager service is running

  • WiFi hardware IS detected by lspci

So the hardware itself seems visible, but matching kernel modules appear missing/broken.

I also ran into additional EFI problems during recovery:

  • unknown filesystem type 'vfat'

  • GRUB repair attempts did not complete cleanly

  • bootloader state now seems inconsistent (GRUB/systemd-boot confusion in EFI entries). we have:

    • EndeavourOS

    • endeavouros

    • grub

    • multiple Linux Boot Manager entries

Recovery attempts so far:

  • edited /etc/fstab

  • recreated /boot/efi

  • rebuilt initramfs via mkinitcpio

  • booted from EndeavourOS live USB

  • manually unlocked/mounted LUKS

  • bind-mounted /dev, /proc, /sys, /run

  • used arch-chroot

At this point I’m unsure whether this is:

  • broken kernel/modules

  • broken EFI setup

  • corrupted package state

  • incomplete update

  • or some combination of all of them

Any ideas appreciated.

2

Hey! Good to have you with us!

That’s a whole heap of modules not found or missing modules. I think the key bit is that the crypt process essentially hangs.

What’s the output of

sudo lsblk -a

Assuming this is the only OS on the device.

3

Thanks! I’m glad to be here, and usually really happy with my EndeavorOS, but this one’s a tough one!
Here’s a picture of the outputs. And yes, this is the only OS on the laptop.

image
image1920×1440 428 KB

4

Awesome, - so it’s detecting your drives consistently, which is good. The luks-encrypted drive is the bit that’s clearly failing over.

Can you boot from the live USB install of EndeavourOS and run

sudo cryptsetup open /dev/sdXy luks_root

where the sdXy bit is your actual partition, sorry not wearing my glasses, but I think that’s nvme0n1p2

Once you’ve done that, mount the partition

sudo mount /dev/mapper/luks_root /mnt

then mount the boot bit? (Sorry doing this from memory)

sudo mount /dev/sdX1 /mnt/boot or /boot/EFI

Assuming that works, it’s going to have to be an arch chroot and then repair/reinstall boot and update/fix packages. There are hopefully more technical people here who can help add to this, but this seems like a good place to start. Apologies coming off a 13 hour day but wanted to try this first, good luck!

5

EOS uses dracut, not mkinitcpio.

6

Thanks. I did that, but direct “EndeavourOS” EFI entry still hangs at cryptroot. Only Linux Boot Manager -> GRUB -> EndeavourOS boots and WiFi/audio still missing after reinstall attempt, I should mention that I already rebuilt initramfs multiple times before this (initially via mkinitcpio, because I didn’t realize EOS was using dracut here).

The rebuild process appeared to complete partially, but WiFi/audio modules still remained missing afterwards..So this dracut/kernel-install issue seems persistent.

During rebuild I noticed

dracut --regenerate-all --force fails with:

Can't write to /boot/<machine-id>/<kernel-version>

Current /boot contents look like this:

  • normal kernel images exist:

    • vmlinuz-linux

    • vmlinuz-linux-lts

    • initramfs-linux.img

    • initramfs-linux-lts.img

but there is also a strange directory:

/boot/5ed63287e1d646859a084a400b60a834

dracut tries to generate images inside that directory and fails.

So now I’m wondering whether dracut config/kernel-install is broken, the boot layout is inconsistent or if EOS should even still use dracut here..

image
image1920×1440 534 KB

7

thanks for the tip! see my reply above..

8

It looks to me like you tried a bunch of things to fix your problem and now you have some strange frankensystem.

You have both grub and systemd-boot and it looks like you installed mkinitcpio which forced the removal of all your boot automation.

On top of that, your EFI partition is mounted as /boot which we don’t do in any configuration.

At this point, you need to decide if you want to run grub or systemd-boot and then we need to work your system back into a working state.

9

Update: system recovered.

Sharing what worked in case it helps someone with a similar mess.
My setup got into a state where the running kernel had no module tree on disk, so WiFi, audio, and most drivers were “missing”, but they weren’t really; I was just booting a stale kernel image whose modules had been deleted on the next update. The scary symptom list collapsed into one root problem once I saw that.

The reason it happened: I had mkinitcpio installed alongside dracut, kernel-install-for-dracut was missing, and both GRUB and systemd-boot were on the ESP with stale NVRAM entries. Kernel upgrades were building /boot/initramfs-linux.img via mkinitcpio’s hook, but nothing was writing a proper dracut initramfs or updated loader entry to the ESP. So the bootloader kept pointing at an old kernel image.

What I did, from an EOS live USB chroot with the ESP mounted at /efi:

Fixed /etc/fstab to mount the ESP at /efi (not /boot), added nofail to the options.
Removed GRUB and its leftover directories from the ESP.
pacman -S kernel-install-for-dracut and pacman -Rns mkinitcpio.
Deleted the stale loader entry and ESP kernel directory for the phantom kernel.
pacman -S linux linux-lts linux-firmware sof-firmware intel-ucode — with the dracut glue in place, this regenerated proper initramfs and BLS entries onto the ESP.
Outside the chroot: bootctl --esp-path=/mnt/efi install, then efibootmgr -B on the stale GRUB/duplicate entries. (Heads up: bootctl install may reuse a freed slot, so watch you don’t delete the new one. If you do, just rerun bootctl install.)

The thing I almost missed, which would have set me up to land here again on the next update: efi.mount was masked (my bad from an earlier recovery attempt). With the ESP not auto-mounting, future kernel updates would write modules to root but couldn’t write the kernel image to the ESP. systemctl unmask efi.mount && systemctl daemon-reload fixed that.

Big thanks to everyone on the thread. The early pointer at the dracut/mkinitcpio conflict was the key. I wouldn’t have found it on my own.

10

Great to hear! Glad you’ve managed to sort it, and appreciate the comprehensive remediations description. May well help someone in the future!