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.

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.

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.

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.

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)

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

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, where I could provide better help, but I think the kernel is your best suspect for this crime.

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

Holy shit, are you me?

https://forum.endeavouros.com/t/boot-stuck-at-a-start-job-is-running-for-dev-disk-by-uuid-uuid-not-familiar/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.

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

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.

This sounds like could be 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.

If that is the case. Maybe something like ntfsfix command.

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

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.

Is the Linux disk still visible in your UEFI firmware?

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.