My Linux won't boot anymore because it can't find the boot drive?

2026-07-27 14:53 UTC

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

Replies (17)

@ThunderComplex@lemmy.today 2026-07-27 14:55

I took a picture of the grub screen maybe that helps idk

Open ##4139638
@TruePe4rl@lemmy.ml 2026-07-27 15:20

Not sure if my suggestion will be any help, but in the past I found out that macOS installer changes drive flags and removed some flags from my partitions. Fixed with efibootmgr.

Open ##4140159
@lime@feddit.nu 2026-07-27 15:24

can windows see the ssd? did you shut windows down the normal way or the hard way? because there’s one way to shut down windows that is basically a hard hibernate, where it keeps control of the drives. i don’t remember exactly how it works but it can lock other oses out.

Open ##4140212
@BCsven@lemmy.ca 2026-07-27 15:24

Smarter people than me can answer, but I had two similar issues before. 1) I added nofail to fstab because in my situation it wasn’t finding a certain drive and getting stuck, and 2) windows fastboot or hybernate had somehow made drive locked or appear dirty to linux

Open ##4140220
@OR3X@lemmy.world 2026-07-27 15:42

Is the Linux disk still visible in your UEFI firmware?

Open ##4140592
@SavvyBeardedFish@reddthat.com 2026-07-27 16:06

Did you also update systemd at the same time? It might be worth reverting that update to see whether it’s that causing the issues. To me, this sounds more like an fstab/systemd-automount issue rather than a bootloader/initrd issue

Open ##4141105
@Adverse_Reaction@anarchist.nexus 2026-07-27 16:27

Just a passing thought, but have you checked if the root partition has any space left?

Open ##4141590
@Neuromancer49@midwest.social 2026-07-27 16:35

Holy shit, are you me? forum.endeavouros.com/t/…/80086 One minor update I have from this experience, after building a new rig and restoring from a backup of the original system, I tried plugging in my SSD to my new computer and it isn’t even recognized in BIOS. I was under the impression my drive failed.

Open ##4141725
@ScoffingLizard@lemmy.dbzer0.com 2026-07-27 16:36

This sounds like the bit locker function that windows usea. I had this issue with it locking my extra ntfs drive when I installed Linux over my whole primary partition. However, your Windows Drive should not be able to read your Linux drive. If Windows bit locker function still caused the trouble, there is a way to fix it but it will continue to happen until you remove Windows.

Open ##4141781
@corsicanguppy@lemmy.ca 2026-07-27 16:44

Yeah so grub can see the disk but then the kernel can’t. Efi and other tricks aren’t involved. I think your route is to find out why the kernel hates your ass. Probably an upd pulled a driver … But who removes the SATA or nvme stuff? Either way, it’s in the kernel and not the boot or the core apps. I don’t use endeavour because I’m a huge proponent of SLSA and iso27002, but I think the kernel is your best suspect for this crime.

Open ##4141912
@Fleppensteijn@sh.itjust.works 2026-07-27 17:02

Check again whether windows reenabled fast boot. Maybe disable secure boot in bios as well. In grub recovery mode, see which drives are there and try to cd into them.

Open ##4142243
@jwt@programming.dev 2026-07-27 19:03

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 -a inside 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 lsblk or blkid in rescue mode to give some hints? You could compare them to live usb outputs of those commands)

Open ##4144577
@WhiteOakBayou@lemmy.world 2026-07-27 23:00

Have you tried to boot from the grub shell manually? Here’s a guide if trying that is something that interests you. It seems like you’ve tried most everything else.

Open ##4149425
@savvywolf@pawb.social 2026-07-27 23:55

Just for testing purposes, have you removed every device except the root device and sys/dev/tmp from fstab? I know Linux can get a bit upset when a NTFS filesysyem is marked as needing chkdsk’d and might be blocking other disks from mounting.

Open ##4154490
@stuner@lemmy.world 2026-07-28 06:29

This sounds like a rather weird issue. I agree with your take that grub is not the problem. It seems that there is some issue with the kernel, or the initramfs systemd… Downgrading the kernel didn’t resolve it, so maybe it is a corrupted disk after all? Some suggestions: Run fsck on the partition from a live USB if you haven’t already Enable more verbose logs from the kernel and the initramfs systemd. The LLM suggests removing quiet splash and adding rd.debug systemd.log_level=debug systemd.log_target=console ignore_loglevel (best check the actual parameters yourself). If possible for you: Copy the install to another drive, change the UUIDs, and try again with that.

Open ##4157114
@ThunderComplex@lemmy.today 2026-07-28 07:08

Update: I’m giving up. I tried every solution I could find. Tried the LTS kernel, fucking around with dracut options. I don’t know what the issue is or how to fix it. I’ll be backing up my shit now and will move back to windows until I can find the brain power necessary for a reinstall. Don’t know yet if I’ll stick to EndeavourOS or try nix or something, EOS worked out of the box with my NVIDIA card. I want to thank everyone for your support. I would not have guessed for this issue to be so deep that it couldn’t be fixed, it is what it is I guess.

Open ##4157263
@mvirts@lemmy.world 2026-07-29 17:34

Afaik, those by-* paths are symlinks created by udev during boot (before switching to the real root fs) The kernel creates the actual device files directly in /dev. My guess is that Windows left an NTFS volume in an unmountable state or something and udev got stuck processing this disk before processing rules for your boot disk. This probably requires you to have a fstab entry for mounting your windows disk, but I’m not sure. When you boot into a live distro again (I know you’re done, but maybe someone else has this problem) check if the disk has a block device file directly in /dev. Maybe check the other disk, see if you can mount it or remove references to it in fstab or unplug the device entirely.

Open ##4206454