Context:
I am running EndeavourOS on my X200S that has Libreboot. I have one drive that is encrypted. A while ago I had issues with my system not booting at all and had to switch to the Linux LTS kernel. I ran sudo pacman -Syu recently and after rebooting I’ve consistently had this issue.
So far I’ve tried:
-
Reinstalling the linux-lts and linux-lts-headers packages and running mkinitcpio -P. This seems like the typical fix for only being able to boot in intramfs.
-
Switching GRUB to loglevel 7 and when trying to boot normally it seems to get stuck on “timed out waiting for device /dev/disk/UUID/the UUID of EndeavourOS”. The messages afterwards are about dependencies failing like /sysroot and United Root File System. From what I could find online this seemed like an issue with my drives being mounted so I tried regenerating fstab with genfstab -U -p / >> /etc/root.
Does anyone have an idea of where things went wrong?
This issue feels like a stack problem, peeling back the layers.
Most of the information I’m finding about this flavour of arch doesn’t reveal much about libreboot’s role in this issue. I’m not familiar with the device and online results are vague about what the specs are.
My main thought is If you’re using a Nvidia GPU or other proprietary software to run hardware, did you reinstall its software after changing the kernel? I’m not sure if your distro automatically does that for you.
Are you using shim for anything?
I’m wondering if something went funny with your mok enrolment or if it failed to use the key to sign the module? Could test by temporarily disabling secure boot. (But would continue to fail if not the problem; such as the modules are compiled against the wrong kernel)
My other thought was that I’m under the impression that endeavourOS uses pinned versions and swapping out the kernel puts you in an undefined state.
You might have some luck jailing it on an working os with the configuration you desire and regenerating the boot files. Same idea as using the rescue environment on a livecd. The last time I had this idea it was a big waste of effort. When I realized I could just roll back using a backup.
Edit: maybe the drive is dying try testing it?
Thanks for replying.
Most of the information I’m finding about this flavour of arch doesn’t reveal much about libreboot’s role in this issue. I’m not familiar with the device and online results are vague about what the specs are.
My main thought is If you’re using a Nvidia GPU or other proprietary software to run hardware, did you reinstall its software after changing the kernel? I’m not sure if your distro automatically does that for you.
I do not believe I reinstalled any Nvidia drivers but I am unsure. I do have the linux-firmware-nvidia package installed. I am just using the integrated graphics that are on the X200S. Maybe that’s part of the issue considering it released around 2008?
Are you using shim for anything?
I’m wondering if something went funny with your mok enrolment or if it failed to use the key to sign the module? Could test by temporarily disabling secure boot. (But would continue to fail if not the problem; such as the modules are compiled against the wrong kernel)
If by shim you are referring to the EFI preloader I do not have it installed.
My other thought was that I’m under the impression that endeavourOS uses pinned versions and swapping out the kernel puts you in an undefined state.
You might have some luck jailing it on an working os with the configuration you desire and regenerating the boot files. Same idea as using the rescue environment on a livecd. The last time I had this idea it was a big waste of effort. When I realized I could just roll back using a backup.
I am not too sure about how to test this.
Edit: maybe the drive is dying try testing it?
I have my doubts that it is the drive considering it seems to work fine within initramfs. I can run my X200S for days without issues as long as I boot that way.
Arch recently moved legacy Nvidia support to the AUR. That might have left you with a broken install.
You would probably have an easier time with a mainstream distro like kubuntu LTS. They tend to be better suited for older equipment.
It can be challenging to fix the bootloader once it dumps you into this situation. On a UEFI secure boot installation the EFI shim is responsible for allowing the modules to load each time there’s a change.
If you have a legacy MBR installation the Nvidia modules might just need to be reinstalled. This was a common issue when updating the kernel.
Edit: switching it to the Nouveau drivers might get you back into the OS. Would need to tweak your environment from a working one with a live environment potentially.
When I run inxi -G I get the following output
Graphics:
Device-1: Intel Mobile 4 Series Integrated Graphics driver: i915 v: kernel
Display: x11 server: X.Org v: 21.1.21 driver: X: loaded: modesetting dri: crocus gpu: i915 resolution: 1: N/A 2: 1366x768~60Hz
API: EGL v: 1.5 drivers: crocus,swrast platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.5 compat-v: 2.1 vendor: intel mesa v: 25.3.3-arch1.1 renderer: Mesa Mobile Intel GM45 Express (CTG)
Info: Tools: api: eglinfo,glxinfo de: xfce4-display-settings
x11: xdpyinfo, xprop, xrandr
It seems like I am using the laptops integrated graphics. I don’t think it has any nvidia graphics.


