Max Nikulin composed on 2024-08-21 23:17 (UTC+0700):
> Felix Miata wrote:
>> Max Nikulin composed on 2024-08-21 10:54 (UTC+0700):
>>> I was experimenting trying to get 2
>>> entries from the same vendor in the UEFI (firmware) boot menu and found
>>> it tricky and inconvenient.
>> How so? I found it quite simple to edit /etc/default/grub and replace the
>> default
>> value of GRUB_DISTRIBUTOR= to some unique string, e.g. "trixie" or
>> "debian12",
>> then update Grub before doing second installation. What else did you find
>> necessary?
> Have I missed something or GRUB_DISTRIBUTOR affects *grub* menu, but not
> *UEFI* boot menu?
Your language as I quoted above I interpreted to mean:
1-you wish 2 entries from same vendor in BBS menu
2-you are not directly or ATM concerned with any Grub menu
Here's how multiboot configuration goes on just one of mine:
# inxi -S
System:
Host: ab85m Kernel: 6.9.7-1-default arch: x86_64 bits: 64
Console: pty pts/0 Distro: openSUSE Tumbleweed 20240820
# mount | grep -i vfat
/dev/sda1 on /boot/efi type vfat (rw,relatime...
# dmidecode | grep -i efi
UEFI is supported
# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0003,0002
Boot0000* opensusetw
HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\opensusetw\grubx64.efi)
Boot0002* UEFI OS HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* CD/DVD Drive
BBS(CDROM,,0x0)0000474f00004e4f7f000000010000004f00440052...
Boot0004* Hard Drive
BBS(HD,,0x0)0000474f00004e4f81000000010000004f00540045004...
# grep UTOR /etc/default/grub
GRUB_DISTRIBUTOR="opensusetw"
# tree /boot/efi/
/boot/efi/
├── EFI
│ ├── BOOT
│ │ ├── BOOTX64.EFI
│ │ └── mt74x64.efi
│ └── opensusetw
│ └── grubx64.efi
├── MemTest86.log
├── MemTest86-Report-20200216-223015.html
├── mt74x64.efi
└── mt83x64.efi
4 directories, 7 files
# lsblk -f | grep deb
├─sda7 ext4 1.0 tg1p07stw c9b0...701a 1G 82% /disks/stw
├─sda9 ext4 1.0 tg1p09deb12 87b9...8adc 606.5M 88% /disks/deb12
├─sda13 ext4 1.0 tg1p13deb13 a5d4...ceb0 2.9G 58% /disks/deb13
├─sda17 ext4 1.0 tg1p17deb11 5be1...5084 675.4M 87% /disks/deb11
# ls -gG /boot/grub2/custom.cfg
-rwxr-xr-x 1 6796 Aug 5 00:03 /boot/grub2/custom.cfg
#
<system restart>
# inxi -S
System:
Host: ab85m Kernel: 6.9.12-amd64 arch: x86_64 bits: 64
Desktop: TDE (Trinity) v: R14.1.3~[DEVELOPMENT] Distro: Debian GNU/Linux
trixie/sid
# mount | grep -i vfat
# dmidecode | grep -i efi
UEFI is supported
# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0003,0002
Boot0000* opensusetw
HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\opensusetw\grubx64.efi)
Boot0002* UEFI OS
HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* CD/DVD Drive
BBS(CDROM,,0x0)0000474f00004e4f7f000000010000004f00440052...
Boot0004* Hard Drive
BBS(HD,,0x0)0000474f00004e4f81000000010000004f00540045004...
# grep UTOR /etc/default/grub
grep: /etc/default/grub: No such file or directory
# tree /boot/efi
-bash: tree: command not found
# tree /boot/efi
/boot/efi
0 directories, 0 files
# lsblk -f | egrep 'stw|deb'
├─sda7 ext4 1.0 tg1p07stw c9b0...701a 1G 82% /disks/stw
├─sda9 ext4 1.0 tg1p09deb12 87b9...8adc 606.5M 88% /disks/deb12
├─sda13 ext4 1.0 tg1p13deb13 a5d4...ceb0 3.6G 49% /
├─sda17 ext4 1.0 tg1p17deb11 5be1...5084 675.4M 87% /disks/deb11
# ls -gG /boot/grub/custom.cfg
ls: cannot access '/boot/grub/custom.cfg': No such file or directory
# ls -gG /disks/stw/boot/grub2/custom.cfg
-rwxr-xr-x 1 6796 Aug 5 00:03 /disks/stw/boot/grub2/custom.cfg
# which update-grub
# dpkg-query -l | grep grub
# parted -l | grep -i ESP
1 1049kB 337MB 336MB fat32 TG1P01 EFI System (ESP) T253X 2295 boot, esp
#
My BBS menu contains 4 entries corresponding to output from efibootmgr,
with the highlight on the one beginning "opensusetw", as configured via
GRUB_DISTRIBUTOR=.
My custom.cfg is 100% managed by me. Its included stanzas are automatically
included along with the entries contained in grub.cfg. By reason of my
having copied /etc/grub.d/41_custom to /etc/grub.d/07_custom, and emptying
/etc/grub.d/41_custom, stanzas from custom.cfg precede those from grub.cfg
when Grub's boot menu is onscreen. Management of custom.cfg is trivial, as
editing is required only when adding another installation, or some other
non-trival changes among installed systems are employed. Stanzas in
custom.cfg all employ symlinks to kernel and initrds.
This is KISS applied to multibooting with UEFI. As with legacy/MBR booting,
only one installed bootloader is required to support as many installed
GNU/Linux installations as desired. I trust it adequately explains why
above only one directory in /EFI/ on ESP exists. It is orthogonal to use
of GRUB_DISTRIBUTOR= to assign a unique directory name within /EFI/ on ESP.
> printf "GRUB_DISTRIBUTOR=%s\n" mydeb \
> >/etc/default/grub.d/distributor.cfg
> update-grub
> grep --count mydeb /boot/grub/grub.cfg
> 8
Do we know that the update-grub command normally writes to /boot/efi/EFI/,
and NVRAM (optional?)?
> So the added option has been applied. However I have not noticed any
> effect related to UEFI configuration
> efibootmgr -v | grep --count mydeb
> 0
> iconv -f UCS-2 /boot/efi/EFI/debian/BOOTX64.CSV
> shimx64.efi,debian,,This is the boot entry for debian
> /boot/efi/EFI/debian remained as it was earlier.
> My expectations for "UEFI/GPT were designed to support multi-boot" in
> the context of discussion of 2 Debian installations are the following:
> - It is possible to create either EFI/mydeb or EFI/debian/mydeb on the
> ESP partition so that grubx64.efi from this directory may load grub.cfg
> from the *same* directory (path relative to the .efi binary). Currently
> .cfg path is a compile-time setting (EFI/debian/grubx64.cfg) for the
> sake of secure boot.
> - boot menu entry with customized name is created (efibootmgr)
> - name in BOOTX64.CSV is changed accordingly. This file is used by
> fallback fbx64.efi to create EFI boot variable when it is missed during
> boot. Currently it is not a configuration file and copied from
> /usr/lib/shim/BOOTX64.CSV (shim-unsigned).
> I have not tried to dispute that it is possible to configure grub for 2
> Debian systems. I do not mind that UEFI allows to put boot files for
> different architectures and (besides removable media EFI/BOOT path) from
> different vendors. I still suspect it is a UEFI+SecureBoot design
> shortcoming that it is not possible to install the same loader (the same
> vendor) on the same ESP twice with different configurations.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
