renaming an entriy causes wrong entries with multible HDs and EFIpartitions

[a4z]

if you have more than one HD and each has a efi sector, guefi needs to care about which hd and partition the entries are defined

for example this setup, where the Ubuntu entry is on sda1 and the Slackware entry on sdb1

.....# skip tons of entries

Boot0018* Ubuntu        HD(1,800,100000,d05fb60d-411c-4efe-9b02-236308280025)File(\EFI\ubuntu\shimx64.efi)/
Boot001B* Slackware     HD(1,800,100000,2b6665be-f5e2-48f5-a374-fef13c6341b4)File(\EFI\Slackware\elilo.efi)

on that hard disks

blkid
/dev/sda1: UUID="DD4E-A4C8" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="d05fb60d-411c-4efe-9b02-236308280025"
/dev/sda2: UUID="9d1758a7-4b51-4d37-a8fd-5c26b12e2b39" TYPE="ext4" PARTUUID="e2043d11-89e1-47c9-9041-b1513c802602"
/dev/sda3: UUID="2baf1f3d-d55d-4276-9361-2f0fc923e5c0" TYPE="swap" PARTUUID="d6abd353-2872-4c35-a750-d2177d7dc2de"
/dev/sdb1: UUID="AC03-AD0D" TYPE="vfat" PARTUUID="2b6665be-f5e2-48f5-a374-fef13c6341b4"
/dev/sdb2: UUID="0a19e78f-1274-4159-adec-ffba1f455643" TYPE="ext4" PARTUUID="f158ceca-7d9f-4a0c-b0db-c96153ea73c7"

using guefi from Slackware to rename the Ubuntu entry to Ubuntu1604 will place the changed entry and let it point to the Slackware HD

this means that the Ubuntu1604 boot entry will exist but not working since it points to a wrong disk/partition, what is a somehow negative user experience.

creating the boot entry must be called with the right HD and the correct partition, in the given example /dev/sda and partition 1.

efibootmgr -c -w -l \\EFI\\ubuntu\\shimx64.efi -L "Ubuntu1604" -p 1 -d /dev/sda

I think what you need to do is

• using blkid to get the disk partition ids ans spare them
• using efibootmgr -v to pars the output, match the diskid and remember on which disk/partition the entry lives
• update the entry with the new name and pass disk/partition you figured out

or simply disable the edit/rename function for entries if there are more than one hd or find some other solution

[laprjns]

I confirmed that there is a problem with creating and editing boot menu entries that that point to a disk other than the disk which guefi in running from. All the other guefi functions seem to work without problems. There is nothing in the UEFI specification that limits the number of ESP partition that can be on a system, so guefi should be able to detect multiple partitions across all the internal storage devices and be able to create and edit entries that point to the various ESP partitions. I'm no expert on writing code, but you can cull out the ESP partitions on a system using fdisk. Here's an example using an overly exaggerate number of esp partitions :

sudo fdisk -l -o DEVICE,TYPE | grep "EFI System"
/dev/sdb1  EFI System
/dev/sdb4  EFI System
/dev/sda5  EFI System
/dev/sda6  EFI System
/dev/sda8  EFI System

[a4z]

I guess after soon 3 years, it is safe to close that issue

[gapan]

I'm reopening, as I actually want this fixed. I completely forgot about it. I'll get to it, soon I hope.

[gapan]

I tried testing this. I created EFI partitions on two drives. But efibootmgr only shows one

PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,1,0)

entry for the other drive, not the actual boot entries that are in the EFI partition of the second drive. This is with efibootmgr version 17. Specifying -d sdb doesn't change anything at all. Do you still get all boot entries, irrespective on which partition they are listed with efibootmgr?

[laprjns]

Just installed 15 beta on my tower computer that has three hard drives and one nvme drive.  Two of the three hard drives and the NVMe drive have EFI partitions.   Here's the output of efibootmgr from the Salix 15 install;

BootCurrent: 0000 Timeout: 1 secon BootOrder: 0000,0002,0004,0009,000A,0003,0001,000B,000C,0005,0006 Boot0000 Salix-Xfce-15.0 HD(1,GPT,402fab1c-6e7c-3346-bcad-5c7cb4678848,0x800,0xfa000)/File(\EFI\Salix-Xfce-15.0\elilo.efi) Boot0001 slint HD(1,GPT,dbdbae44-645e-47b0-b543-dc3d4cfb038c,0x800,0xfa000)/File(\EFI\slint\grubx64.efi) Boot0002 rEFInd HD(1,GPT,dbdbae44-645e-47b0-b543-dc3d4cfb038c,0x800,0xfa000)/File(\EFI\REFIND\REFIND_X64.EFI) Boot0003 MX19.1 HD(1,GPT,dbdbae44-645e-47b0-b543-dc3d4cfb038c,0x800,0xfa000)/File(\EFI\MX19.1\GRUBX64.EFI) Boot0004 Salix_14,2 HD(1,GPT,27c309bc-8f55-4f9c-b691-71f28b6d911f,0x800,0xfa000)/File(\EFI\SALIX-XFCE-14.2\ELILO.EFI) Boot0005 Hard Drive VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)..GO Boot0006 CD/DVD Drive VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)..GO Boot0009 Hard Drive BBS(HD,,0x0)..GO..NO..........S.A.M.S.U.N.G. .M.Z.V.L.B.2.5.6.H.A.H.Q.-.0.0.0.L.7....................A...........................%8...v......J..Gd-.;.A..MQ..L.S.A.M.S.U.N.G. .M.Z.V.L.B.2.5.6.H.A.H.Q.-.0.0.0.L.7........BO..NO........o.W.D.C. .W.D.1.0.E.Z.E.X.-.0.0.W.N.4.A.0....................A...........................>..Gd-.;.A..MQ..L. . . . .W. .-.D.M.W.6.C.0.Y.9.L.S.4.7.M........BO..NO........o.S.T.3.5.0.0.4.1.3.A.S....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .2.Z.6.A.C.M.D.9........BO..NO........o.S.T.3.1.0.0.0.5.2.8.A.S....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .V.9.6.P.J.D.D.T........BO Boot000A CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........o.T.S.S.T.c.o.r.p. .D.V.D.-.R.O.M. .S.H.-.1.1.8.B.B....................A...........................>..Gd-.;.A..MQ..L.9.R.9.5.8.6.D.A.0.4.0.0.K.4. . . . . . ........BO Boot000B Windows Boot Manager HD(1,GPT,27c309bc-8f55-4f9c-b691-71f28b6d911f,0x800,0xfa000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO Boot000C* UEFI: TOSHIBA TransMemory PMAP PciRoot(0x0)/Pci(0x14,0x0)/USB(7,0)/USB(2,0)/CDROM(1,0x5b0,0x2d00)..BO

Boot item 0000 is on sda1 efi partition.  Boot items, 0001, 0002, 0003 are on the nvme0n1p1 efi partition  and Boot items 0004 and 000B are on the sdc1 efi partition.

One thing I did note was that efibootmfgr (version 17) included in Salix 15 defaults to the verbose output.  Mint 19 also uses version 17 and its default output is the simple boot listing like what was in salix 14.2.

Rich Lapointe

On 5/22/22 21:31, George Vlahavas wrote:

I tried testing this. I created EFI partitions on two drives. But efibootmgr only shows one

|PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,1,0) |

entry for the other drive, not the actual boot entries that are in the EFI partition of the second drive. This is with efibootmgr version 17. Specifying |-d sdb| doesn't change anything at all. Do you still get all boot entries, irrespective on which partition they are listed with efibootmgr?

— Reply to this email directly, view it on GitHub https://github.com/gapan/guefi/issues/1#issuecomment-1133987049, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMQG7KMUI4XCWGQLWO3XTLVLKRSHANCNFSM4C26QUEQ. You are receiving this because you commented.Message ID: @.***>