Does anyone here understand this

[Qqmike]

Boot0001* UEFI: USB, Partition 2  PciRoot(0x0)/Pci(0x14,0x0)/USB(22,0)/HD(2,GPT,e7e777e5-ba64-4290-a759-837b96feb4ed,0x7023fc,0x2130)..BO

I'm trying to make sense of that line (output from efibootmgr -v).
It almost looks like sda2 where I have my Kubuntu root filesystem (and GRUB etc.).
I ONLY have one SATA SSD, btw.
That number (looks like a GUID): e7e777e5-ba64-4290-a759-837b96feb4ed,0x7023fc,0x2130
does not correspond to any of my UUIDs or GUIDs on my only 4 partitions sda1 (ESP), sda2 (/), sda3 (/home), sda4 (swap).

Some kind of PCI root controller, ...
"PCIe root port, which is an internal PCIe port on the motherboard's root complex (more info here; it's basically what allows the CPU and RAM to talk to your PCIe devices)"
found that snippet on the Internet somewhere.

Why am I getting it as a boot NVRAM in firmware? Is it associated somehow with sda2. If sda2 were a PCI M.2, I might understand it. But sda2 on sda comes from a SATA SSD (trust me! I built the PC).
My SATA SSD: Samsung 870 EVO 500GB 2.5 Inch SATA III Internal SSD (MZ-77E500B/AM)

[Qqmike]

A Root Complex (RC) denotes the root of an I/O hierarchy that connects the CPU/memory subsystem to the I/O. It is the interface between the CPU and the PCIe bus.

So, conceptually, I kind of get it. It's a path from the root complex. But it seems to terminate at gpt2, my "/ Kubuntu" system.
Broadly speaking, I'm trying to figure out why UEFI created a NVRAM variable for this.
In this diagram, that bus system does have "legacy" endpoints, which I would take to mean SATA?
A software engineer could crack this easily, I'm sure!

[claydoh]

The USB part seems relevant. Maybe it's an old entry that's being saved, in or sort of stuck, and not cleared out?

[Qqmike]

Your intuition about things is amazing, claydoh.
The only thing it could be that's bootable is the original USB thumb drive I used to originally install Kubuntu 22.04 to my system.
I checked it. Snippet:

ls -l /dev/disk/by-*uuid/
lrwxrwxrwx 1 root root 10 Oct 6 16:45 e7e777e5-ba64-4290-a758-837b96feb4ed -> ../../sdb3

There it is, sdb3, on that installer thumb drive!
That artifact has survived many re-boots of this PC.
Sounds like an UEFI firmware issue with my ASUS Prime Z590-P mobo.
I have heard of such things happening.

Many thanks, claydoh. This was threatening my sanity! I couldn't put it down all day today.
I'm still amazed you thought of it.

I was doing all this to prepare to install an M.2 soon, so I would have a "before" picture of my booting,
prior to a 2nd drive and a dual boot (experiment).

(I am unable to bold that GUID in the code text.)

[jglen490]

The GIUD e7e777e5-ba64-4290-a759-837b96feb4ed is likely the unique identifier of your SSD, as a whole, since that string is in reference to the GPT structure of the SSD.

[Qqmike]

That GPT is confusing. It must be somehow built into the Kubuntu iso image dd'd to the installer thumb drive.
So, no, it is not my SSD. That GUID appears here:

ls -l /dev/disk/by-partuuid/

lrwxrwxrwx 1 root root 10 Oct 6 12:11 81566d30-f0e8-40b0-a0a4-4c37c025af3f -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 6 12:11 8be5b232-4878-4a1d-b4f1-3405f54d6a76 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 6 18:10 afba11e6-8872-b248-943d-8b5572d9a4b5 -> ../../sdb4
lrwxrwxrwx 1 root root 10 Oct 6 12:11 b0cb2dbb-9956-439c-b0be-f79553903c2a -> ../../sda4
lrwxrwxrwx 1 root root 10 Oct 6 12:11 cfc63277-3e31-4939-bde9-db4429f4fa77 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 6 18:10 e7e777e5-ba64-4290-a758-837b96feb4ed -> ../../sdb3
lrwxrwxrwx 1 root root 10 Oct 6 18:10 e7e777e5-ba64-4290-a759-837b96feb4ed -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 6 18:10 e7e777e5-ba64-4290-a75a-837b96feb4ed -> ../../sdb1

The sda refers to my installed SATA SSD (my one and only drive).
The sdb refers to the Kubuntu installer USB thumb drive I just plugged in to my PC to run this test.
It's sdb3.
It's an artifact because, of course, the installer thumb drive has been removed ever since I installed 22.04, long time ago.
Thanks, jglen, for looking at this.

[Qqmike]

Been thinking about the artifact left over and retained as an NVRAM variable by my UEFI/BIOS.
It's not a firmware problem. Maybe it is a firmware feature! ha-ha
I might need that USB Kubuntu bootable thumb drive to conduct rescue operations on my 22.04 OS.
If so, it's all set up in my EFI boot list, which is at least somewhat reassuring.

It would be easy enough to delete it from firmware, of course, right?
sudo efibootmgr -b 0001 -B
And, fact is, although I can recognize it now when I see it,
I could use my how-to to create a better label for it in the UEFI/BIOS boot listing from efibootmgr -v.
--> not necessarily true in this specific case ... looking at the details ...
because of how it seems to appear (that path) in that PCIe Root tree.
But, anyway, no big deal. Best to leave everything alone for now.

[jlittle]

The firmware on my desktop's Gigabyte motherboard has been prone to generating a lot of trashy NVRAM boot entries. There's a 1500 byte one for an old drive that the desktop has never booted from. I sometimes clean them up.