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.

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.

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)

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.

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

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.

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.

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.

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

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.

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

Is the Linux disk still visible in your UEFI firmware?

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.

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.