Groups > linux.debian.user > #272303 > unrolled thread

Default partition mounts [ "Installation Guide" lacks index ]

Started by	Richard Owlett <rowlett@access.net>
First post	2024-08-19 13:20 +0200
Last post	2024-08-21 09:20 +0200
Articles	20 on this page of 48 — 20 participants

Back to article view | Back to linux.debian.user

  Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-19 13:20 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] David <bouncingcats@gmail.com> - 2024-08-19 14:10 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-19 15:50 +0200
        Re: Default partition mounts [ "Installation Guide" lacks index ] Joe <joe@jretrading.com> - 2024-08-19 18:00 +0200
          Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-19 20:20 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] Andy Smith <andy@strugglers.net> - 2024-08-19 22:00 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 10:50 +0200
        Re: Default partition mounts [ "Installation Guide" lacks index ] "Andrew M.A. Cater" <amacater@einval.com> - 2024-08-20 11:40 +0200
          Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 12:50 +0200
            Trixie and i386 - was [Re: Default partition mounts [ "Installation  Guide" lacks index ]] Richard Owlett <rowlett@access.net> - 2024-08-20 14:40 +0200
              Re: Trixie and i386 - was [Re: Default partition mounts [  "Installation Guide" lacks index ]] Charles Curley <charlescurley@charlescurley.com> - 2024-08-20 15:50 +0200
              Future of i386 as installer "Andrew M.A. Cater" <amacater@einval.com> - 2024-08-20 15:50 +0200
        The lack of a future for 32-bit x86 installs (Was Re: Default  partition mounts [ "Installation Guide" lacks index ]) Andy Smith <andy@strugglers.net> - 2024-08-20 17:20 +0200
          Re: The lack of a future for 32-bit x86 installs (Was Re: Default  partition mounts [ "Installation Guide" lacks index ]) Roberto C. Sánchez <roberto@debian.org> - 2024-08-20 18:10 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] Tom Dial <tddial@comcast.net> - 2024-08-20 00:50 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] David Wright <deblis@lionunicorn.co.uk> - 2024-08-20 05:20 +0200
        Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 10:10 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] David Christensen <dpchrist@holgerdanske.com> - 2024-08-20 06:30 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 10:20 +0200
      UEFI multiboot (was: Re: Default partition mounts [ "Installation  Guide" lacks index ]) Max Nikulin <manikulin@gmail.com> - 2024-08-20 17:20 +0200
        Re: UEFI multiboot (was: Re: Default partition mounts [  "Installation Guide" lacks index ]) Erwan David <erwan@rail.eu.org> - 2024-08-20 17:30 +0200
        Re: UEFI multiboot (was: Re: Default partition mounts [  "Installation Guide" lacks index ]) Nicolas George <george@nsup.org> - 2024-08-20 18:00 +0200
          Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation  Guide" lacks index ]) Jeffrey Walton <noloader@gmail.com> - 2024-08-20 18:30 +0200
            Re: UEFI multiboot gene heskett <gheskett@shentel.net> - 2024-08-20 22:20 +0200
          Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-21 06:00 +0200
            Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-21 06:30 +0200
              Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-21 18:20 +0200
                Re: UEFI multiboot Nicolas George <george@nsup.org> - 2024-08-21 19:40 +0200
                Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-22 00:30 +0200
                  Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-22 05:20 +0200
                    Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-22 11:50 +0200
                      Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-22 18:00 +0200
                        Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-22 22:50 +0200
                      [SUMMARY] Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-23 05:10 +0200
                        Re: [SUMMARY] UEFI multiboot Felix Miata <mrmazda@earthlink.net> - 2024-08-23 06:50 +0200
                          Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-30 18:10 +0200
                            Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-30 18:50 +0200
                              Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-31 04:20 +0200
                            [SUMMARY] Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-09-14 06:10 +0200
                              Re: [SUMMARY] UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-09-14 06:40 +0200
                                Re: [SUMMARY] UEFI multiboot songbird <songbird@anthive.com> - 2024-09-14 19:40 +0200
                                  Re: [SUMMARY] UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-09-14 21:20 +0200
                                    Re: [SUMMARY] UEFI multiboot "Thomas Schmitt" <scdbackup@gmx.net> - 2024-09-14 21:40 +0200
                                  Re: [SUMMARY] UEFI multiboot Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-16 12:20 +0200
                                    Re: [SUMMARY] UEFI multiboot songbird <songbird@anthive.com> - 2024-09-17 01:50 +0200
                    Re: UEFI multiboot Joe <joe@jretrading.com> - 2024-08-22 12:00 +0200
            Re: UEFI multiboot Nicolas George <george@nsup.org> - 2024-08-21 08:50 +0200
              Re: UEFI multiboot Joe <joe@jretrading.com> - 2024-08-21 09:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#272351 — Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

From	Erwan David <erwan@rail.eu.org>
Date	2024-08-20 17:30 +0200
Subject	Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])
Message-ID	<JdyY1-6m9I-3@gated-at.bofh.it>
In reply to	#272349

On Tue, Aug 20, 2024 at 05:17:43PM CEST, Max Nikulin <manikulin@gmail.com> said:
> On 20/08/2024 11:27, David Christensen wrote:
> > AIUI UEFI/GPT were designed to support multi-boot
> 
> Single EFI System Partition may contain loaders from different vendors, but
> not 2 Debian systems installed on different partitions. EFI files are signed
> for Secure Boot, so vendor paths can not be easily adjusted. I have no idea
> how much trouble may cause multiple ESP on the same drive. I tried ESP on
> different drives and it works (HP firmware on a decade-old laptop is quite
> buggy in respect to boot configuration). Actually GRUB menu to load system
> from alternative partition is more convenient than firmware boot menu in my
> case.

Here is the tree on my laptop, I think the "ubuntu part" comes from a
former Mint installation (Debian is tthe only OS on the computer)

.
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── mmx64.efi
    ├── debian
    │   ├── BOOTX64.CSV
    │   ├── fbx64.efi
    │   ├── fw
    │   │   └── fwupd-cdcae5ae-413a-4198-b866-8028e994dd53.cap
    │   ├── fwupdx64.efi
    │   ├── grub.cfg
    │   ├── grubx64.efi
    │   ├── mmx64.efi
    │   └── shimx64.efi
    ├── Dell
    │   └── Bios
    │       └── Recovery
    │           ├── BIOS_CUR.RCV
    │           └── BIOS_PRE.rcv
    └── ubuntu
        ├── BOOTX64.CSV
        ├── fw
        ├── fwupdx64.efi
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi


-- 
Erwan David

[toc] | [prev] | [next] | [standalone]

#272355 — Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

From	Nicolas George <george@nsup.org>
Date	2024-08-20 18:00 +0200
Subject	Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])
Message-ID	<Jdzr3-6mjH-13@gated-at.bofh.it>
In reply to	#272349

Max Nikulin (12024-08-20):
> Single EFI System Partition may contain loaders from different vendors, but
> not 2 Debian systems installed on different partitions.

This is not true. The only problem you will have with this setup is that
you will need to install and/or configure the bootloader manually.

>							  EFI files are signed
> for Secure Boot, so vendor paths can not be easily adjusted.

Secure boot is a joke when it comes to security, its only “merit” is to
prevent lusers from installing software with disabled DRM.

>								I have no idea
> how much trouble may cause multiple ESP on the same drive.

Once the bootloader is installed, the partition is referred by UUID, it
does not matter if it is the ESP or not.

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#272358 — Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

From	Jeffrey Walton <noloader@gmail.com>
Date	2024-08-20 18:30 +0200
Subject	Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])
Message-ID	<JdzU5-6mIN-15@gated-at.bofh.it>
In reply to	#272355

On Tue, Aug 20, 2024 at 11:51 AM Nicolas George <george@nsup.org> wrote:
>
> [...]
> >                                                         EFI files are signed
> > for Secure Boot, so vendor paths can not be easily adjusted.
>
> Secure boot is a joke when it comes to security, its only “merit” is to
> prevent lusers from installing software with disabled DRM.

Speaking of Secure Boot, this just made my radar:
<https://www.schneier.com/blog/archives/2024/07/compromising-the-secure-boot-process.html>.

Jeff

[toc] | [prev] | [next] | [standalone]

#272368 — Re: UEFI multiboot

From	gene heskett <gheskett@shentel.net>
Date	2024-08-20 22:20 +0200
Subject	Re: UEFI multiboot
Message-ID	<JdDuF-6oWq-1@gated-at.bofh.it>
In reply to	#272358

On 8/20/24 12:29, Jeffrey Walton wrote:
> On Tue, Aug 20, 2024 at 11:51 AM Nicolas George <george@nsup.org> wrote:
>>
>> [...]
>>>                                                          EFI files are signed
>>> for Secure Boot, so vendor paths can not be easily adjusted.
>>
>> Secure boot is a joke when it comes to security, its only “merit” is to
>> prevent lusers from installing software with disabled DRM.
> 
> Speaking of Secure Boot, this just made my radar:
> <https://www.schneier.com/blog/archives/2024/07/compromising-the-secure-boot-process.html>.
> 
> Jeff
> 
And proves the point, that all this bs is for naught if enough salary is 
paid to the right people.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#272381 — Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-21 06:00 +0200
Subject	Re: UEFI multiboot
Message-ID	<JdKFP-6tBl-1@gated-at.bofh.it>
In reply to	#272355

On 20/08/2024 22:50, Nicolas George wrote:
> Max Nikulin (12024-08-20):
>> Single EFI System Partition may contain loaders from different vendors, but
>> not 2 Debian systems installed on different partitions.
> 
> This is not true. The only problem you will have with this setup is that
> you will need to install and/or configure the bootloader manually.

Do you mean 3rd party bootloader (e.g. grub)? I was responding to "AIUI 
UEFI/GPT were designed to support multi-boot". Custom configuration of 
grub (earlier lilo) was possible before UEFI and GPT.

Erwan posted directory tree for debian+ubuntu ESP, but it is a case of 
different vendors. Richard wants 2 variants of Debian (however UEFI may 
be irrelevant to that machine). I was experimenting trying to get 2 
entries from the same vendor in the UEFI (firmware) boot menu and found 
it tricky and inconvenient.

On 20/08/2024 23:28, Jeffrey Walton wrote:
> Speaking of Secure Boot, this just made my radar:
> <https://www.schneier.com/blog/archives/2024/07/compromising-the-secure-boot-process.html>.

When I noticed that news, I was curious if there is an alternative 
command to "efi-readvar -v PK" since I do not have the tool installed. It is

     efi-readvar -v PK

I found it in
<https://github.com/fwupd/fwupd/issues/2695>
"Add test for detecting the "AMI Test PK" in the HSI"
opened 2020-12-18T19:23:10Z

The issue that is rather similar at first glance was filed 3.5 years 
before the latest discovery.

[toc] | [prev] | [next] | [standalone]

#272382 — Re: UEFI multiboot

From	Felix Miata <mrmazda@stanis.net>
Date	2024-08-21 06:30 +0200
Subject	Re: UEFI multiboot
Message-ID	<JdL8R-6u5a-1@gated-at.bofh.it>
In reply to	#272381

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?
-- 
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

[toc] | [prev] | [next] | [standalone]

#272427 — Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-21 18:20 +0200
Subject	Re: UEFI multiboot
Message-ID	<JdWdX-6ASA-7@gated-at.bofh.it>
In reply to	#272382

On 21/08/2024 11:25, 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?

printf "GRUB_DISTRIBUTOR=%s\n" mydeb \
    >/etc/default/grub.d/distributor.cfg
update-grub
grep --count mydeb /boot/grub/grub.cfg
8

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.

[toc] | [prev] | [next] | [standalone]

#272434 — Re: UEFI multiboot

From	Nicolas George <george@nsup.org>
Date	2024-08-21 19:40 +0200
Subject	Re: UEFI multiboot
Message-ID	<JdXto-6Bym-9@gated-at.bofh.it>
In reply to	#272427

Max Nikulin (12024-08-21):
> Have I missed something or GRUB_DISTRIBUTOR affects *grub* menu, but not
> *UEFI* boot menu?

Indeed, it is not just as simple as that.

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

       --bootloader-id=ID
              the  ID  of  bootloader. This option is only available on EFI and
              Macs.

I it as simple as this.

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#272443 — Re: UEFI multiboot

From	Felix Miata <mrmazda@stanis.net>
Date	2024-08-22 00:30 +0200
Subject	Re: UEFI multiboot
Message-ID	<Je201-6Eon-3@gated-at.bofh.it>
In reply to	#272427

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

[toc] | [prev] | [next] | [standalone]

#272446 — Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-22 05:20 +0200
Subject	Re: UEFI multiboot
Message-ID	<Je6wF-6HsV-1@gated-at.bofh.it>
In reply to	#272443

On 22/08/2024 05:21, Felix Miata wrote:
> My BBS menu contains 4 entries corresponding to output from efibootmgr,
> with the highlight on the one beginning "opensusetw", as configured via
> GRUB_DISTRIBUTOR=.

Or it just coincides with the configured value. My expectation is that 
EFI/opensusetw/grub.cfg is still hardcoded in your grubx64.efi. I tried 
earlier "install-grub --bootloader-id", but there was a pitfall in the 
case of enabled SecureBoot: grubx64.efi and grub.cfg were taken from 
different ESP directories that is not apparent in some cases.

> My custom.cfg is 100% managed by me.
[...]
> This is KISS applied to multibooting with UEFI.

Sorry, but this time I would prefer to leave aside grub configuration 
unrelated to UEFI. I have never had intention to dispute that it is 
possible to configure multiboot using grub. Multiboot using UEFI 
facilities directly is a bit different beast.

>> 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?)?

Actually I tried dpkg-reconfigure for grub and shim packages and your 
message made me thinking that you may correct me and may provide proper 
commands to configure *UEFI* boot menu.

 From my old notes:
<https://bugs.launchpad.net/bugs/1450783>

[toc] | [prev] | [next] | [standalone]

#272449 — Re: UEFI multiboot

From	Felix Miata <mrmazda@stanis.net>
Date	2024-08-22 11:50 +0200
Subject	Re: UEFI multiboot
Message-ID	<JecC5-6Lc2-1@gated-at.bofh.it>
In reply to	#272446

Max Nikulin composed on 2024-08-22 10:17 (UTC+0700):

> Felix Miata wrote:

>> My BBS menu contains 4 entries corresponding to output from efibootmgr,
>> with the highlight on the one beginning "opensusetw", as configured via
>> GRUB_DISTRIBUTOR=.

> Or it just coincides with the configured value.

/etc/default/grub's GRUB_DISTRIBUTOR=, if not null, /is/ where the configuration
is established. In openSUSE, that default is null, and thus falls back to
something somewhere I suppose in /usr/ establishing opensuse as its default. In
Debian it is by default whatever `lsb_release -i -s 2> /dev/null || echo Debian`
works out to be, usually "debian" AFAICT, unless it's been changed since last I
had such file from a Debian installation. With only one bootloader per PC, lots of
/etc/default/ directories have no grub file in them.

> My expectation is that 
> EFI/opensusetw/grub.cfg is still hardcoded in your grubx64.efi.

Given /boot/grub2/grub.cfg was last written 13 minutes after
EFI/opensusetw/grubx64.efi, I do not believe it is in there in this or on any
other of my installations:

# ls -gG /boot/efi/EFI/opensusetw/grub.cfg
ls: cannot access '/boot/efi/EFI/opensusetw/grub.cfg': No such file or directory
# ls -gG /boot/efi/EFI/opensusetw/
total 148
-rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi
# ls -gG /boot/efi/EFI/*
/boot/efi/EFI/BOOT:
total 1172
-rwxr-xr-x 1  143360 Aug 23  2022 BOOTX64.EFI
-r-xr-xr-x 1 1053552 Jul 26  2017 mt74x64.efi

/boot/efi/EFI/opensusetw:
total 148
-rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi
# lsblk -f | egrep -i 'tw|deb|esp'
├─sda1  vfat   FAT32 TG1P01ESP     ...9-E...      315M     1% /boot/efi
├─sda7  ext4   1.0   tg1p07stw     c9b0...701a    1.1G    81% /
├─sda9  ext4   1.0   tg1p09deb12   87b9...8adc    1.5G    76% /disks/deb12
├─sda13 ext4   1.0   tg1p13deb13   a5d4...ceb0    3.6G    49% /disks/deb13
├─sda17 ext4   1.0   tg1p17deb11   5be1...5084  765.9M    86% /disks/deb11
# ls -gG /boot/grub2/grub.cfg
-rw------- 1 28238 Aug 21 16:21 /boot/grub2/grub.cfg
#

>> Do we know that the update-grub command normally writes to /boot/efi/EFI/,
>> and NVRAM (optional?)?

> Actually I tried dpkg-reconfigure for grub and shim packages and your 
> message made me thinking that you may correct me and may provide proper 
> commands to configure *UEFI* boot menu.

>  From my old notes:
> <https://bugs.launchpad.net/bugs/1450783> 

efibootmgr -c -L "opensusetw" -d /dev/sda1 -l '\EFI\opensusetw\grubx64.efi'
here has created a new entry in NVRAM when old was obsolete or deleted. It doesn't
create the opensusetw directory on the ESP. That is written by any process that
reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.
-- 
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

[toc] | [prev] | [next] | [standalone]

#272463 — Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-22 18:00 +0200
Subject	Re: UEFI multiboot
Message-ID	<Jeioa-6OKN-43@gated-at.bofh.it>
In reply to	#272449

On 22/08/2024 16:44, Felix Miata wrote:
> # ls -gG/boot/efi/EFI/opensusetw/
> total 148
> -rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi

Am I right that you either do not use Secure Boot or generated a local 
key instead of/in addition to Microsoft and SUSE ones?

In the case of default or almost default install with a Debian key 
(mokutil --list-enrolled)

ls -gG /boot/efi/EFI/debian/
total 5960
-rwx------ 1     108 Oct  9  2023 BOOTX64.CSV
-rwx------ 1   87328 Oct  9  2023 fbx64.efi
-rwx------ 1     112 Oct  9  2023 grub.cfg
-rwx------ 1 4199872 Oct  9  2023 grubx64.efi
-rwx------ 1  849616 Oct  9  2023 mmx64.efi
-rwx------ 1  948768 Oct  9  2023 shimx64.efi

Shim and grub are shipped signed, so install-grub can not embed location 
of /boot/grub2/grub.cfg (search.fs_uuid) into grubx64.efi. So grub.cfg 
specifying a partition with /boot is written to EFI/debian/grub.cfg:

search.fs_uuid 12345678-90ab-4cde-f012-34567890abcd root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

I have found an upstream bug:

<https://savannah.gnu.org/bugs/index.php?57381>
bug #57381: EFI image with wrong prefix when bootload-id is specified

that confirms that "debian" is fixed in the EFI/debian/grub.cfg path 
when grubx64.efi is taken from grub-efi-amd64-signed. I have no idea if 
EFI binaries can determine their own location to implement relative path 
for the configuration file. Depending on that hardcoded .cfg path is 
either grub or UEFI limitation.

[toc] | [prev] | [next] | [standalone]

#272468 — Re: UEFI multiboot

From	Felix Miata <mrmazda@stanis.net>
Date	2024-08-22 22:50 +0200
Subject	Re: UEFI multiboot
Message-ID	<JemUN-6Rvd-5@gated-at.bofh.it>
In reply to	#272463

Max Nikulin composed on 2024-08-22 22:56 (UTC+0700):

> Felix Miata wrote:

>> # ls -gG/boot/efi/EFI/opensusetw/
>> total 148
>> -rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi

> Am I right that you either do not use Secure Boot or generated a local 
> key instead of/in addition to Microsoft and SUSE ones?

I'm just finishing up with a distribution upgrade on one of my PCs. I cloned
/dev/sda16 to /dev/sda64, updated configuration on /dev/sda64, verified it works
normally, then did the upgrade on the original. My many computers each have lots
of GNU/Linux installations. This particular one includes OS/2. KISS with so many
installations demands I not tangle everything up with secure boot. It's
complicated enough without.
-- 
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

[toc] | [prev] | [next] | [standalone]

#272470 — [SUMMARY] Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-23 05:10 +0200
Subject	[SUMMARY] Re: UEFI multiboot
Message-ID	<JesQx-6Wav-7@gated-at.bofh.it>
In reply to	#272449

On 22/08/2024 16:44, Felix Miata wrote:
> That is written by any process that
> reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.

To avoid confusion of those who may notice this thread in search engine 
results:

In Debian GRUB_DISTRIBUTOR value is *not* passed to "grub-install 
--bootloader-id" by postinst package scripts:
<https://sources.debian.org/src/grub2/2.12-5/debian/postinst.in/?hl=723#L723>
<https://sources.debian.org/src/shim-signed/1.44/debian/shim-signed.postinst/?hl=64#L64>

Notice
> 	case $bootloader_id in
> 	    kubuntu) bootloader_id=ubuntu ;;
> 	esac

that was added to prevent a secure boot issue.

Behavior of SUSE may be different.

I believe, a robust way would be to add grub-install option that reports 
path withing EFI partition configured at compile time, so heuristics 
based on GRUB_DISTRIBUTOR from /etc/default/grub would not confuse users.

*Signed* grub*.efi reads its config from EFI/debian/grub.cfg (that loads 
/boot/grub/grub.cfg) that is fixed when the binary is signed.

[toc] | [prev] | [next] | [standalone]

#272474 — Re: [SUMMARY] UEFI multiboot

From	Felix Miata <mrmazda@earthlink.net>
Date	2024-08-23 06:50 +0200
Subject	Re: [SUMMARY] UEFI multiboot
Message-ID	<Jeupj-6X1t-1@gated-at.bofh.it>
In reply to	#272470

Max Nikulin composed on 2024-08-23 10:09 (UTC+0700):

> Felix Miata wrote:

>> That is written by any process that
>> reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.
 
> To avoid confusion of those who may notice this thread in search engine 
> results:
 
> In Debian GRUB_DISTRIBUTOR value is *not* passed to "grub-install 
> --bootloader-id" by postinst package scripts:
> <https://sources.debian.org/src/grub2/2.12-5/debian/postinst.in/?hl=723#L723>
> <https://sources.debian.org/src/shim-signed/1.44/debian/shim-signed.postinst/?hl=64#L64>
 
> Notice
>> 	case $bootloader_id in
>> 	    kubuntu) bootloader_id=ubuntu ;;
>> 	esac
 
> that was added to prevent a secure boot issue.
 
> Behavior of SUSE may be different.
 
> I believe, a robust way would be to add grub-install option that reports 
> path withing EFI partition configured at compile time, so heuristics 
> based on GRUB_DISTRIBUTOR from /etc/default/grub would not confuse users. 
I don't know what vexing secure boot might introduce, but without it,
GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce
results I expected:

# inxi -S
System:
  Host: msi85 Kernel: 6.9.12-amd64 arch: x86_64 bits: 64
  Console: pty pts/0 Distro: Debian GNU/Linux trixie/sid
# grep TOR /etc/default/grub
GRUB_DISTRIBUTOR="debian13"
# efibootmgr | egrep 'suse|debian|rder'
BootOrder: 0000,0004,0005,0003,0001,0002
Boot0000* opensusetw    HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0004* opensuse      HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
# tree /boot/efi/EFI
/boot/efi/EFI
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fbx64.efi
│   ├── MemTest86.log
│   └── mt74x64.efi
├── opensuse
│   └── grubx64.efi
└── opensusetw
    └── grubx64.efi

4 directories, 6 files
# grub-install --target=x86_64-efi --efi-directory=/boot/efi
Installing for x86_64-efi platform.
Installation finished. No error reported.
# efibootmgr | egrep 'suse|debian|rder'
BootOrder: 0006,0000,0004,0005,0003,0001,0002
Boot0000* opensusetw    HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0004* opensuse      HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0006* debian13      HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\debian13\grubx64.efi)
# tree /boot/efi/EFI
/boot/efi/EFI
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fbx64.efi
│   ├── MemTest86.log
│   └── mt74x64.efi
├── debian13
│   └── grubx64.efi
├── opensuse
│   └── grubx64.efi
└── opensusetw
    └── grubx64.efi

5 directories, 7 files
#
Note I didn't use option --bootloader-id, so grub-install had no place on my
Trixie's / filesystem to find string "debian13" other than GRUB_DISTRIBUTOR=
in /etc/default/grub.
-- 
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

[toc] | [prev] | [next] | [standalone]

#272712 — Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-30 18:10 +0200
Subject	Re: UEFI multiboot
Message-ID	<Jhcmd-8Klv-11@gated-at.bofh.it>
In reply to	#272474

On 23/08/2024 11:39, Felix Miata wrote:
> I don't know what vexing secure boot might introduce, but without it,
> GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce
> results I expected:
[...]
> # grep TOR /etc/default/grub
> GRUB_DISTRIBUTOR="debian13"
[...]
> ├── debian13
> │   └── grubx64.efi
> ├── opensuse

How does grubx64.efi find where grub.cfg is located? Is it compatible 
with Secure Boot? It is the reason why your experiment is not convincing.

I have tried some variants of full shim+grub signed configurations on 
the laptop with buggy firmware where I experienced troubles several 
years ago. The results have surprised me and they are the same as for 
qemu with OVMF instance.

grubx64.efi (v2.06) from Debian bookworm has no problem with reading 
grub.cfg placed in the same directory and directory name does not matter.

grubx64.efi (v2.06) from Ubuntu 20.04 focal reads config file strictly 
from EFI/ubuntu/grub.cfg.

I have not figured out what specific patch causes the difference. A lot 
of lines are changed. I do not think it is a security measure. Perhaps 
something is broken in attempts to improve booting from network.

There was a similar issue with Debian
https://bugs.debian.org/932966
and devuan still used EFI/debian when bootloader id "devuan" is used,
patches have not dropped (but perhaps just to avoid issues with existing 
installations).

A couple of problems that I have noticed in bookworm:

1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is 
not adjusted. As a result if additional removable path EFI/BOOT is used 
then there is a chance that fbx64.efi will create "debian" boot entry, 
not the name specified in GRUB_DISTRIBUTOR

2. It is not apparent that after modifying GRUB_DISTRIBUTOR it is 
necessary to create the directory with matched name in /boot/efi/EFI. 
Otherwise "dpkg-reconfigure grub-efi-amd64" does not run grub-install. I 
would prefer to have an explicit setting instead of relying on presence 
of a directory.

The main point is that I did not expect that Debian and Ubuntu may 
diverge in so subtle way. I believed fixed .cfg path is a UEFI 
limitation or at best an inherent grub limitation.

[toc] | [prev] | [next] | [standalone]

#272713 — Re: UEFI multiboot

From	Felix Miata <mrmazda@stanis.net>
Date	2024-08-30 18:50 +0200
Subject	Re: UEFI multiboot
Message-ID	<JhcYV-8KAk-1@gated-at.bofh.it>
In reply to	#272712

Max Nikulin composed on 2024-08-30 23:09 (UTC+0700):

> How does grubx64.efi find where grub.cfg is located?

I don't know what doc might report this, but in a file viewer I see a string like
(,gpt7)/boot/grub) embedded in a vast sea of nulls 98% of the way into the file.
-- 
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

[toc] | [prev] | [next] | [standalone]

#272726 — Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-08-31 04:20 +0200
Subject	Re: UEFI multiboot
Message-ID	<JhlSx-8R7J-1@gated-at.bofh.it>
In reply to	#272713

On 30/08/2024 23:42, Felix Miata wrote:
> Max Nikulin composed on 2024-08-30 23:09 (UTC+0700):
> 
>> How does grubx64.efi find where grub.cfg is located?
> 
> I don't know what doc might report this, but in a file viewer I see a string like
> (,gpt7)/boot/grub) embedded in a vast sea of nulls 98% of the way into the file.

Does UEFI secure boot allows modification of some part of a signed .efi 
binary without invalidating its signature?

/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed is copied verbatim to 
EFI/*/grubx64.efi. I still believe there is a reason why 
"(,gpt7)/boot/grub" is written to EFI/*/grub.cfg when secure boot is used.

[toc] | [prev] | [next] | [standalone]

#273072 — [SUMMARY] Re: UEFI multiboot

From	Max Nikulin <manikulin@gmail.com>
Date	2024-09-14 06:10 +0200
Subject	[SUMMARY] Re: UEFI multiboot
Message-ID	<JmsgF-c7To-1@gated-at.bofh.it>
In reply to	#272712

Avoid setting non-standard GRUB_DISTRIBUTOR in /etc/default/grub if you 
use Debian 12 bookworm with enabled Secure Boot and signed grub image 
from Debian. Alternatively install grub-2.12 from backports.

> On 23/08/2024 11:39, Felix Miata wrote:
>> I don't know what vexing secure boot might introduce, but without it,
>> GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce
>> results I expected:

There is significant difference in patches for grub-2.12 in trixie and 
for 2.06 in bookworm. In the case of Secure Boot, grub-install copies 
signed grubx64.efi instead of generation of an image specific to the 
machine.

On 30/08/2024 23:09, Max Nikulin wrote:
> I have tried some variants of full shim+grub signed configurations on 
[...]
> grubx64.efi (v2.06) from Debian bookworm has no problem with reading 
> grub.cfg placed in the same directory and directory name does not matter.
> 
> grubx64.efi (v2.06) from Ubuntu 20.04 focal reads config file strictly 
> from EFI/ubuntu/grub.cfg.

If there is EFI/debian/grub.cfg then it has higher priority than the 
file from the directory from where grubx64.efi is loaded. Loading config 
file from a custom directory looks like an unintentional behavior.

> I have not figured out what specific patch causes the difference. A lot 
> of lines are changed. I do not think it is a security measure.

The difference of grub-2.06 behavior between Ubuntu and Debian are 
caused by build script, not by patches. It is a result of an attempt to 
fix issues with Unicode characters. Relevant changes:

grub2 (2.06-14) experimental; urgency=medium

* Bundle unicode.pf2 in a squashfs memdisk attached to the signed EFI binary

  -- Julian Andres Klode <jak@debian.org>  Mon, 19 Jun 2023 17:26:49 +0200

grub2 (2.06-6) unstable; urgency=medium

* Include fonts in the memdisk build for EFI images.
   Closes: #1024395, #1025352, #1024447

  -- Steve McIntyre <93sam@debian.org>  Sun, 04 Dec 2022 20:42:23 +0000

Bookworm currently have 2.06-13 and in 2.06-14 config should be loaded 
strictly from EFI/debian/grub.cfg.

The script written for booting from CD or a similar media
<https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/build-efi-images/#L64>
accidentally got bundled into regular images
<https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/build-efi-images/#L240>
Since 2.06-14 a dedicated squashfs image has been provided for fonts, so 
the config search script is not a part of prebuilt images.

> Perhaps something is broken in attempts to improve booting from network.

I wrote "broken" describing Ubuntu-20.4 behavior where custom 
GRUB_DISTRIBUTOR may cause failure to boot. I consider 2.06 broken in 
Debian now. However patches making it possible in 2.12 are really 
related to network
<https://lists.nongnu.org/archive/html/grub-devel/2023-01/msg00012.html>
A one setting fw_path and
<https://sources.debian.org/patches/grub2/2.12-5/network/try-prefixes-for-tftp-config-file.patch/>

They have not been included into the upstream repository. Debian 
changelog entry is

     * Port UEFI based network stack to 2.12 (LP: #2039081)

> A couple of problems that I have noticed in bookworm:
> 
> 1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is 
> not adjusted. As a result if additional removable path EFI/BOOT is used 
> then there is a chance that fbx64.efi will create "debian" boot entry, 
> not the name specified in GRUB_DISTRIBUTOR
> 
> 2. It is not apparent that after modifying GRUB_DISTRIBUTOR it is 
> necessary to create the directory with matched name in /boot/efi/EFI. 
> Otherwise "dpkg-reconfigure grub-efi-amd64" does not run grub-install. I 
> would prefer to have an explicit setting instead of relying on presence 
> of a directory.

3. EFI/debian/grub.cfg has highest priority, so if bookworm is installed 
in parallel with another Debian then neither must have 
GRUB_DISTRIBUTOR=debian. Moreover grub.cfg likely may be found on some 
other disk (e.g. a USB pendrive) having .disk/info. The version from 
backports should help.

> I believed fixed .cfg path is a UEFI 
> limitation or at best an inherent grub limitation.

I have realized that shim can not work if it can not load grub from the 
same directory. Perhaps it really happens in some cases.

<https://www.gnu.org/software/grub/manual/grub/html_node/cmdpath.html>
in Special environment variables
> 15.1.4 cmdpath
> The location from which core.img was loaded as an absolute directory
> name (see File name syntax). This is set by GRUB at startup based on
> information returned by platform firmware. Not every platform provides
> this information and some may return only device without path name.

For EFI platform the required function is implemented (for many other 
platforms it is not), however there are enough code paths when it may 
return without providing a usable value.

At first glance shim really loads files using relative paths while grub 
tries to obtain absolute path. Perhaps some EFI-specific trick may be 
added to grub code to make it more reliable.

Curiously a patch intended to improve config loading breaks cmdpath. 
Instead it sets the fw_path variable.

So multiple loaders from the same vendor is tricky in the case of UEFI 
SecureBoot. Behavior of grub may vary across Linux distributions.

[toc] | [prev] | [next] | [standalone]

#273073 — Re: [SUMMARY] UEFI multiboot

From	Felix Miata <mrmazda@stanis.net>
Date	2024-09-14 06:40 +0200
Subject	Re: [SUMMARY] UEFI multiboot
Message-ID	<JmsJH-c87P-1@gated-at.bofh.it>
In reply to	#273072

Max Nikulin composed on 2024-09-14 10:59 (UTC+0700):

> So multiple loaders from the same vendor is tricky in the case of UEFI 
> SecureBoot. Behavior of grub may vary across Linux distributions.

Thus, consider to KISS. Pick one installation's bootloader to depend on. Install
no others.
-- 
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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

Default partition mounts [ "Installation Guide" lacks index ]

Contents

#272351 — Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

#272355 — Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

#272358 — Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

#272368 — Re: UEFI multiboot

#272381 — Re: UEFI multiboot

#272382 — Re: UEFI multiboot

#272427 — Re: UEFI multiboot

#272434 — Re: UEFI multiboot

#272443 — Re: UEFI multiboot

#272446 — Re: UEFI multiboot

#272449 — Re: UEFI multiboot

#272463 — Re: UEFI multiboot

#272468 — Re: UEFI multiboot

#272470 — [SUMMARY] Re: UEFI multiboot

#272474 — Re: [SUMMARY] UEFI multiboot

#272712 — Re: UEFI multiboot

#272713 — Re: UEFI multiboot

#272726 — Re: UEFI multiboot

#273072 — [SUMMARY] Re: UEFI multiboot

#273073 — Re: [SUMMARY] UEFI multiboot