41
submitted 17 hours ago by ThunderComplex@lemmy.today to c/linux@lemmy.ml

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

you are viewing a single comment's thread
view the rest of the comments
[-] stuner@lemmy.world 2 points 1 hour ago* (last edited 1 hour ago)

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:

  1. Run fsck on the partition from a live USB if you haven't already
  2. 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).
  3. If possible for you: Copy the install to another drive, change the UUIDs, and try again with that.
[-] ThunderComplex@lemmy.today 1 points 1 hour ago

Ehh I’ll just back up my stuff and pack my bags for now. A reinstall is just gonna be faster at this point.

this post was submitted on 27 Jul 2026
41 points (91.8% liked)

Linux

66638 readers
421 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 7 years ago
MODERATORS