Announcement

Collapse
No announcement yet.

Does anyone here understand this

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Does anyone here understand this

    Code:
    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)
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    #2
    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!

    Click image for larger version

Name:	image.png
Views:	102
Size:	51.2 KB
ID:	682862
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    Comment


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

      Comment


        #4
        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:

        Code:
        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.)
        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

        Comment


          #5
          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.
          The next brick house on the left
          Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.27.11​| Kubuntu 24.04 | 6.8.0-31-generic



          Comment


            #6
            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:

            Code:
            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.

            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

            Comment


              #7
              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.
              An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

              Comment


                #8
                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.
                Regards, John Little

                Comment

                Working...
                X