Alright I'm at the end of the rope with my Linux knowledge. So I need your help.
I'm on EndeavourOS and just recently upgraded to Linux 7.1.5, all upgrades thus far have been without issue. I am dual-booting but have Linux on its own SSD, and grub handles booting into Linux or Windows.
Now, after booting into Windows and back into Linux, Linux won't start.
The error:
A start job is running for /dev/disks/by-uuid/
Let me tell you what I've already done:
- Regenerate mkinitrd with dracut
- Regenerate grub.cfg and verified via diff it is identical to the current one
- On a live usb verified that the UUIDs in the grub and fstab files are correct using the KDE partition manager (they are)
- Verify on a live usb the SSD still works (data and everything is still there)
- Changed the grub boot option on boot to check that the UUID is not hardcoded somewhere and can be changed (this is true, inputting a garbage UUID changes the boot error to A start job is running for /dev/disks/by-uuid/garbage-uuid
One last idea I had was to drop myself into the dracut emergency shell and actually check what's actually under /dev/disks/by-uuid and lo and behold: it's actually missing the drive.
Here's whats nuts tho: grub loads the drive by UUID as well, loads the initrd, and all that works. When I regenerated the initrd with dracut I could also tell that grub was now loading the newer initrd.
WHAT THE FUCK???
Help?
At this point I REALLY don't know wtf to do. Why doesnt the initramfs detect the drive? The only useful info I can add here is that all drives listed under /dev/disks/by-uuid had that shorter UUID with no dashes like ABCD1234, whereas the UUID for the correct drive/partition is the longer type UUID like abc1234-1234-0000-defg
Did the problem begin right after a kernel upgrade? Slim chance, but only thing I can think of is maybe some module your boot process depends on is no longer built-in the kernel and needs to be added to initrd manually. I always have an LTS kernel installed as backup to be able to exclude these kind of fucky issues.
If you don't have an LTS kernel installed, you could try to boot a live usb, chroot into your EndeavourOS installation (don't forget to do a
mount -ainside the chroot environment to mount boot and efi partitions) and install the LTS kernel. If you're able to reboot with an LTS kernel that makes debugging a whole lot easier. Best of luck.(The 'shorter uuids' are probably the vfat boot and efi partitions btw. Maybe you have access to
lsblkorblkidin rescue mode to give some hints? You could compare them to live usb outputs of those commands)If the previous kernel is still available, can you boot that? That should help determine if the kernel is at fault.
Yeah I up upgraded the kernel, finished my song in windows, then Linux go boom.
Tried downgrading to 7.1.4 the previous version no luck, will try lts kernel tomorrow
The specific grub command wasn't listed in the OP, I don't think?
grub-mkconfig -o /boot/grub/grub.cfgThat's Gentoo syntax anyway, and your grub config may live elsewhere, but you should get the idea. It's supposed to find the new kernel.
I've never used an initrd, so I can't comment on that.
I did do that with a new cfg file then diff'd the current and newly generated cfg files and they were identical
Fascinating.
I'd like to recommend rEFInd once you figure this out.
Windows has never been able to squash it.
thanks but since my boot manager already doesn't live on the same drive as windows, it can't squash it anyway hehe