There wasn't any LVM involved, it's AFAIK pretty rare outside of MBR installs (as GPT typically lets you have more than enough partitions).

sorry for the late reply, the command 'lsblk' can output it:

"sudo lsblk -o +uuid,name"

check "man lsblk" to see all possible combinations if needed.

there is also 'blkid' but I'm unsure whether that package is installed by default on all Linux releases, so that's why I chose 'lsblk'

if 'blkid' is installed, the syntax would be:

"sudo blkid /dev/sda1 -s UUID -o value"

glad you got it fixe, and hope this answers your question

(edit pga big thumbs and autocorrect... )

Your title mentioned GPT as in the partition table. The other user thought about ChatGPT.

I'm confused. You say that you're booting off that drive that it can't find. Like, this is your root drive?

But I believe that the kernel finding the root drive should happen much earlier than this. Like, you've got systemd stuff there on the screen. For that to happen, I'd think that you'd need to have your root drive already up and mounted. Grub hands that off to the kernel, believe that it's specified in /etc/default/grub on my Debian system, then gets written out when you run sudo update-grub.

If I'm not misunderstanding that you are saying that the drive in question is your root drive, are you sure that this isn't happening because there's a reference to the drive -- maybe another partition or something -- in /etc/fstab is failing to find something?

Or maybe I'm just misunderstanding what you're saying.

EDIT: if you just want to get it working, unless you've got some kind of exotic setup, I expect that you can probably boot into a very raw mode by, from grub, passing init=/bin/sh on the kernel command line. A lot of stuff won't be functional if you do that, since you'll just be running a shell and the kernel, but as long as you have a root filesystem, it'll probably come up. Then I'd mount -o remount,rw / so that you can modify your root drive, and then fiddle your /etc/fstab into shape. Probably a live distro is more comfortable to work in, but if all you need is to get the regular system up, I'd think that fiddling with /etc/fstab is likely all you need to do that.

EDIT2: and then I'd probably compare the output of blkid to your fstab, from within the boot in your regular system, if that isn't what you already did.

In my case, it was just too many technology changes from what I was used to, and simply wasn't familiar enough with. It doesn't help that every distro seems to do everything slightly differently, rather than just agreeing on a standard. The egotistical NIH may be the most frustrating thing about distro builders.

EFI and dracut are both novel to me; efi I'm starting to become more comfortable with, but dracut is new and I'm not entirely sure how it works and where it puts all of its config stuff. It's still better than systemd-boot, which was mostly a catastrophe for me; it worked fine until you wanted to draw outside of the lines a little and then you discover a mountain of spaghetti. I probably should have just stayed with grub, but I wanted snapshot booting, and grub is beginning to struggle with some of these new modalities.

Anyway, I don't want to have to rely on a custom specialized distro, and I figured out my problem in a couple of days; I only have to screw it up two or three more times and then I'll be comfortable with it :-)