Re: Best practice for fresh install on UEFI with multiple disks?

[Florent Rougon]

Hi,

Le 30/09/2024, Boyan Penkov  a écrit:

> -- If I have multiple drives, do I modify the script to have multiple
> efi2, efi3, ..., efiX ?

I think yes.

> -- it seems that the script above privileges /boot/efi over /boot/efi2
> -- in this case, if /boot/efi becomes corrupted, won't this just copy
> the errors to /boot/efi2 and thus destroy it as well, on the next run?

My understanding of how the script was designed is the following:
  - if the disk containing /boot/efi is fine, no problem using it as the
“master copy”;
  - if it has a silent corruption problem, we're screwed and the
corruption may be copied to other disks, but that's already the case
with other partitions in a raid (nowadays there are consistency
checks...);
  - if it has a problem that is visible enough for the md layer to
remove the disk from the array, then /boot/efi won't be a mount
point anymore, so the script will do nothing from this point on.
Thus, you can boot from another disk until you have a replacement
drive; during this time (and unless you changed /etc/fstab), the
script won't sync anything.

HTH, regards

-- 
Florent

Re: Best practice for fresh install on UEFI with multiple disks?

[Boyan Penkov]

Hello folks,

Thanks kindly -- and my apologies for picking this up after a while;
fell sick here...

A few questions:

-- If I have multiple drives, do I modify the script to have multiple
efi2, efi3, ..., efiX ?

-- it seems that the script above privileges /boot/efi over /boot/efi2
-- in this case, if /boot/efi becomes corrupted, won't this just copy
the errors to /boot/efi2 and thus destroy it as well, on the next run?

Cheers!

On Fri, Sep 20, 2024 at 2:12 PM Tim Woodall  wrote:
>
> On Fri, 20 Sep 2024, Florent Rougon wrote:
>
> > Le 20/09/2024, Tim Woodall  a écrit:
> >
> >> Because the script will abort after the mount fails.
> >>
> >> root@dirac:~# cat test.sh
> >> #!/bin/bash
> >>
> >> set -e
> >>
> >> mount /boot/efi2
> >>
> >> echo "do important stuff"
> >>
> >> root@dirac:~# ./test.sh
> >> mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
> >>dmesg(1) may have more information after failed mount system call.
> >>
> >>
> >> Note that do important stuff is never reached.
> >
> > That's interesting because my system doesn't behave the same. I had of
> > course checked, before writing my first message, that 'mount /boot/efi2'
> > returns exit status 0 even when /boot/efi2 is already mounted. With your
> > script (called foo.sh here), here is what I get:
> >
> > # mount | grep efi2
> > /dev/sda1 on /boot/efi2 type vfat 
> > (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > # /tmp/foo.sh
> > do important stuff
> > # mount | grep efi2
> > /dev/sda1 on /boot/efi2 type vfat 
> > (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > /dev/sda1 on /boot/efi2 type vfat 
> > (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > #
> >
> > Every invocation adds a new, duplicate entry in the output of 'mount'.
> >
> > This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
> > 2.40.2-8.
> >
>
> That's very interesting and looks like it's probably a kernel change.
>
> Tim.



-- 
Boyan Penkov

Re: Best practice for fresh install on UEFI with multiple disks?

[Tim Woodall]

On Fri, 20 Sep 2024, Florent Rougon wrote:


Le 20/09/2024, Tim Woodall  a écrit:


Because the script will abort after the mount fails.

root@dirac:~# cat test.sh
#!/bin/bash

set -e

mount /boot/efi2

echo "do important stuff"

root@dirac:~# ./test.sh
mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
   dmesg(1) may have more information after failed mount system call.


Note that do important stuff is never reached.


That's interesting because my system doesn't behave the same. I had of
course checked, before writing my first message, that 'mount /boot/efi2'
returns exit status 0 even when /boot/efi2 is already mounted. With your
script (called foo.sh here), here is what I get:

# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
# /tmp/foo.sh
do important stuff
# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda1 on /boot/efi2 type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
#

Every invocation adds a new, duplicate entry in the output of 'mount'.

This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
2.40.2-8.



That's very interesting and looks like it's probably a kernel change.

Tim.

Re: Best practice for fresh install on UEFI with multiple disks?

[Florent Rougon]

Le 20/09/2024, Tim Woodall  a écrit:

> Because the script will abort after the mount fails.
>
> root@dirac:~# cat test.sh
> #!/bin/bash
>
> set -e
>
> mount /boot/efi2
>
> echo "do important stuff"
>
> root@dirac:~# ./test.sh
> mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
>dmesg(1) may have more information after failed mount system call.
>
>
> Note that do important stuff is never reached.

That's interesting because my system doesn't behave the same. I had of
course checked, before writing my first message, that 'mount /boot/efi2'
returns exit status 0 even when /boot/efi2 is already mounted. With your
script (called foo.sh here), here is what I get:

# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
# /tmp/foo.sh
do important stuff
# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda1 on /boot/efi2 type vfat 
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
#

Every invocation adds a new, duplicate entry in the output of 'mount'.

This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
2.40.2-8.

Regards

-- 
Florent

Re: Best practice for fresh install on UEFI with multiple disks?

[Tim Woodall]

On Fri, 20 Sep 2024, Florent Rougon wrote:


Le 20/09/2024, Tim Woodall  a ?crit:


Haven't looked at the script but assuming it's run set -e, then your
suggestion will fail if it's already mounted.


Why?



Because the script will abort after the mount fails.

root@dirac:~# cat test.sh
#!/bin/bash

set -e

mount /boot/efi2

echo "do important stuff"

root@dirac:~# ./test.sh
mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
   dmesg(1) may have more information after failed mount system call.


Note that do important stuff is never reached.

Re: Best practice for fresh install on UEFI with multiple disks?

[Florent Rougon]

Le 20/09/2024, Tim Woodall  a écrit:

> Haven't looked at the script but assuming it's run set -e, then your
> suggestion will fail if it's already mounted.

Why?

-- 
Florent

Re: Best practice for fresh install on UEFI with multiple disks?

[Tim Woodall]

On Thu, 19 Sep 2024, Florent Rougon wrote:


Hi,

Le 19/09/2024, Andy Smith  a ?crit:


I don't think the answer, on Debian, has changed since I asked the
same question in 2020:

https://lists.debian.org/debian-user/2020/11/msg00455.html


There is a script at [1] to install as, e.g.,
/etc/grub.d/90_copy_to_boot_efi2, so that it is automatically run every
time grub updates its configuration file. I believe the script is fine,
except I would do

 mount /boot/efi2

rather than

 mount /boot/efi2 || :

Maybe the intent is for the script not to return a non-zero exit status
when /boot/efi2 can't be mounted, however in this case I certainly don't
want the rsync command to be run.



Haven't looked at the script but assuming it's run set -e, then your
suggestion will fail if it's already mounted.

Best would be to check that, and unmount again only if the script
mounted.

Tim.

Re: Best practice for fresh install on UEFI with multiple disks?

[Florent Rougon]

Hi,

Le 19/09/2024, Andy Smith  a écrit:

> I don't think the answer, on Debian, has changed since I asked the
> same question in 2020:
>
> https://lists.debian.org/debian-user/2020/11/msg00455.html

There is a script at [1] to install as, e.g.,
/etc/grub.d/90_copy_to_boot_efi2, so that it is automatically run every
time grub updates its configuration file. I believe the script is fine,
except I would do

  mount /boot/efi2

rather than

  mount /boot/efi2 || :

Maybe the intent is for the script not to return a non-zero exit status
when /boot/efi2 can't be mounted, however in this case I certainly don't
want the rsync command to be run.

Regards

[1] https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition

-- 
Florent

Re: Best practice for fresh install on UEFI with multiple disks?

[Andy Smith]

Hi,

On Wed, Sep 18, 2024 at 08:21:10PM -0400, Boyan Penkov wrote:
> So, what are folks doing these days to mirror /efi and /boot?

[ TL;DR: You already found it - have two separate EFI System
  Partitions, sync one to the other manually using e.g. rsync
  whenever one changes, add paths to both in your UEFI firmware. ]

I don't think the answer, on Debian, has changed since I asked the
same question in 2020:

https://lists.debian.org/debian-user/2020/11/msg00455.html

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Best practice for fresh install on UEFI with multiple disks?

[Boyan Penkov]

Hello folks,

New machine, new opportunity to get up to speed with the contemporary
best practices for multiple disks on UEFI.

The behavior I'd like -- and, I suspect, the behavior we'd all like --
is the machine stays bootable and data is preserved if any disk fails.
Specifically, what I'd like to do if a disk fails (or starts warning
me of possible failure) is shut the machine down at my convenience,
replace the disk, have it re-boot, and re-populate the new disk with
data in the background.

For data, BTRFS works well for my use case, has for some time, and has
been tested on disks dying in the last few years.  However, this is
the first time I have a chance to deal with this for /boot on EFI
partitions, which can't be put on BTRFS.

So, what are folks doing these days to mirror /efi and /boot?
Googling shows that Ubuntu can boot off RAID directly here, but Debian
cant quite yet without manually rsync'ing directories.

Anybody have a firm solution here?

Cheers!

-- 
Boyan Penkov

Re: [SUMMARY] UEFI multiboot

[songbird]

Anssi Saari wrote:
> songbird  writes:
>
>>   hmm, well i actually use Refind for my normal booting up
>> and install GRUB as a backup.  so far i've never needed the
>> backup but i do test it out from time to time.
>
> Um, so how do you choose which boot manager you want to run? UEFI boot
> menu?
>

  efibootmgr lets you pick.


songbird

Re: [SUMMARY] UEFI multiboot

[Anssi Saari]

songbird  writes:

>   hmm, well i actually use Refind for my normal booting up
> and install GRUB as a backup.  so far i've never needed the
> backup but i do test it out from time to time.

Um, so how do you choose which boot manager you want to run? UEFI boot
menu?

Re: [SUMMARY] UEFI multiboot

[Thomas Schmitt]

Hi,

Felix Miata wrote:
> Which distros ship rEFInd? It's not among packages monitored by distrowatch.

It seems that Debian does since a while:
  https://tracker.debian.org/pkg/refind

The tracker page points by its "homepage" link to
  https://www.rodsbooks.com/refind/
which shows the name "rEFInd".


Have a nice day :)

Thomas

Re: [SUMMARY] UEFI multiboot

[Felix Miata]

songbird composed on 2024-09-14 13:07 (UTC-0400):

> Felix Miata wrote:

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

>   hmm, well i actually use Refind for my normal booting up
> and install GRUB as a backup.  so far i've never needed the
> backup but i do test it out from time to time.

Which distros ship rEFInd? It's not among packages monitored by distrowatch.
-- 
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

Re: [SUMMARY] UEFI multiboot

[songbird]

Felix Miata wrote:
> 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.

  hmm, well i actually use Refind for my normal booting up
and install GRUB as a backup.  so far i've never needed the
backup but i do test it out from time to time.


  songbird

Re: [SUMMARY] UEFI multiboot

[Felix Miata]

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

[SUMMARY] Re: UEFI multiboot

[Max Nikulin]

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   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 <93...@debian.org>  Sun, 04 Dec 2022 20:42:23 +

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

Re: UEFI multiboot

[Max Nikulin]

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.

Re: UEFI multiboot

[Felix Miata]

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

Re: UEFI multiboot

[Max Nikulin]

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.

Re: [SUMMARY] UEFI multiboot

[Felix Miata]

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:
> 
> 
 
> 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: ,0004,0005,0003,0001,0002
Boot* opensusetw
HD(1,GPT,64c8...8745,0x800,0xa)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0004* opensuse  
HD(1,GPT,64c8...8745,0x800,0xa)/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,,0004,0005,0003,0001,0002
Boot* opensusetw
HD(1,GPT,64c8...8745,0x800,0xa)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0004* opensuse  
HD(1,GPT,64c8...8745,0x800,0xa)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0006* debian13  
HD(1,GPT,64c8...8745,0x800,0xa)/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

[SUMMARY] Re: UEFI multiboot

[Max Nikulin]

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:




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.

Re: UEFI multiboot

[Felix Miata]

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

Re: UEFI multiboot

[Max Nikulin]

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.

Re: UEFI multiboot

[Felix Miata]

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...701a1.1G81% /
├─sda9  ext4   1.0   tg1p09deb12   87b9...8adc1.5G76% /disks/deb12
├─sda13 ext4   1.0   tg1p13deb13   a5d4...ceb03.6G49% /disks/deb13
├─sda17 ext4   1.0   tg1p17deb11   5be1...5084  765.9M86% /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

Re: UEFI multiboot

[Max Nikulin]

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>

Re: UEFI multiboot

[Felix Miata]

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: 
Timeout: 1 seconds
BootOrder: ,0004,0003,0002
Boot* opensusetw   
HD(1,GPT,<...>,0x800,0xa)/File(\EFI\opensusetw\grubx64.efi)
Boot0002* UEFI OS  HD(1,GPT,<...>,0x800,0xa)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* CD/DVD Drive 
BBS(CDROM,,0x0)474f4e4f7f0001004f00440052...
Boot0004* Hard Drive   
BBS(HD,,0x0)474f4e4f810001004f00540045004...
# 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  1G82% /disks/stw
├─sda9  ext4   1.0   tg1p09deb12   87b9...8adc  606.5M88% /disks/deb12
├─sda13 ext4   1.0   tg1p13deb13   a5d4...ceb02.9G58% /disks/deb13
├─sda17 ext4   1.0   tg1p17deb11   5be1...5084  675.4M87% /disks/deb11
# ls -gG /boot/grub2/custom.cfg
-rwxr-xr-x 1 6796 Aug  5 00:03 /boot/grub2/custom.cfg
#

# 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: 
Timeout: 1 seconds
BootOrder: ,0004,0003,0002
Boot* opensusetw
HD(1,GPT,<...>,0x800,0xa)/File(\EFI\opensusetw\grubx64.efi)
Boot0002* UEFI OS   
HD(1,GPT,<...>,0x800,0xa)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* CD/DVD Drive  
BBS(CDROM,,0x0)474f4e4f7f0001004f00440052...
Boot0004* Hard Drive
BBS(HD,,0x0)474f4e4f810001004f00540045004...
# 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  1G82% /disks/stw
├─sda9  ext4   1.0   tg1p09deb12   87b9...8adc  606.5M88% /disks/deb12
├─sda13 ext4   1.0   tg1p13deb13   a5d4...ceb03.6G49% /
├─sda17 ext4   1.0   tg1p17deb11   5be1...5084  675.4M87% /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 exis

Re: UEFI multiboot

[Nicolas George]

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

Re: UEFI multiboot

[Max Nikulin]

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.

Re: UEFI multiboot

[Joe]

On Wed, 21 Aug 2024 08:45:05 +0200
Nicolas George  wrote:

> Max Nikulin (12024-08-21):
> > Do you mean 3rd party bootloader (e.g. grub)?  
> 
> There is nothing “3rd party” about GRUB.
> 
> > I was responding to
> > "AIUI
> > UEFI/GPT were designed to support multi-boot".  
> 
> Yes, and so was I. If you want half a dozen different GRUBs configured
> for half a dozen installed distros, it is possible. Completely useless
> because:
> 
> >  Custom
> > configuration of grub
> > (earlier lilo) was possible before UEFI and GPT.  
> 
> … and more convenient. But it is possible.
> 
> > 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).  
> 
> As I said, perfectly possible.
> 
> > I was experimenting trying to get 2
> > entries
> > from the same vendor in the UEFI (firmware) boot menu and found it
> > tricky and inconvenient.  
> 
> “Tricky and inconvenient” ≠ “impossible”
> 

No all UEFI firmware is equal. I have an Acer netbook which does not
honour DefaultBoot. When cold booted, it always boots to the Windows
drive and resets that as the default boot. Fortunately, it can be
overridden by a USB stick. It does honour NextBoot, so I have a script
which sets NextBoot to grub on each Linux boot, and I carry a Debian
rescue USB for the odd occasion when I have to use Windows.

-- 
Joe

Re: UEFI multiboot

[Nicolas George]

Max Nikulin (12024-08-21):
> Do you mean 3rd party bootloader (e.g. grub)?

There is nothing “3rd party” about GRUB.

>   I was responding to "AIUI
> UEFI/GPT were designed to support multi-boot".

Yes, and so was I. If you want half a dozen different GRUBs configured
for half a dozen installed distros, it is possible. Completely useless
because:

>Custom configuration of grub
> (earlier lilo) was possible before UEFI and GPT.

… and more convenient. But it is possible.

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

As I said, perfectly possible.

>   I was experimenting trying to get 2 entries
> from the same vendor in the UEFI (firmware) boot menu and found it tricky
> and inconvenient.

“Tricky and inconvenient” ≠ “impossible”

-- 
  Nicolas George

Re: UEFI multiboot

[Felix Miata]

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

Re: UEFI multiboot

[Max Nikulin]

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.

Re: UEFI multiboot

[gene heskett]

On 8/20/24 12:29, Jeffrey Walton wrote:

On Tue, Aug 20, 2024 at 11:51 AM Nicolas George  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:
.

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

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

[Jeffrey Walton]

On Tue, Aug 20, 2024 at 11:51 AM Nicolas George  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:
.

Jeff

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

[Nicolas George]

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

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

[Erwan David]

On Tue, Aug 20, 2024 at 05:17:43PM CEST, Max Nikulin  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

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

[Max Nikulin]

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.

Re: UEFI secure boot issue

[Bhasker C V]

On Thu, Jun 20, 2024 at 3:57 PM Jeffrey Walton  wrote:
>
> On Thu, Jun 20, 2024 at 9:23 AM Bhasker C V  wrote:
> >
> > I generated a pr/pk pair and the kernel is signed. Placed them in the
> > kernel tree and compiled the kernel.
>
> I don't think you are supposed to check-in/compile-in the private key.
> It is usually supposed to stay private.
>
> > Could someone tell me what am I doing wrong please ?
> >
> > Below is the status (I am using loader.efi from linuxfoundation)
> > When i boot debian stock kernel signed, i see that the secure boot
> > gets enabled (hence bios and everything else seems to be fine with the
> > same UEFI loader).
> > However, when I boot the compiled kernel I get
> >
> > $ dmesg | grep -i secure
> > [0.007085] Secure boot could not be determined
> >
> >
> > $ sbverify --list bootx64.efi
> > warning: data remaining[91472 vs 101160]: gaps between PE/COFF sections?
> > signature 1
> > image signature issuers:
> >  - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
> > Corporation UEFI CA 2011
> > image signature certificates:
> >  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
> >issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/CN=Microsoft Corporation UEFI CA 2011
> >  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/CN=Microsoft Corporation UEFI CA 2011
> >issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/CN=Microsoft Corporation Third Party Marketplace Root
> > $ sbverify  --list ./loader.efi
> > signature 1
> > image signature issuers:
> >  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> > image signature certificates:
> >  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> >issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> > $ sbverify  --list ../../linux/k.bcv
> > signature 1
> > image signature issuers:
> >  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> > image signature certificates:
> >  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> >issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
>
>
> Have a look at <https://wiki.debian.org/SecureBoot>, and the use of
> the Machine Owner Key (MOK).

Thanks Jeff. I did follow this.
Like I had mentioned before, the stock kernel still works in
locked-down mode with secure boot whereas the kernel I have compiled
and signed does not.
Is there a way to debug this on why exactly does this not work ?

>
> Jeff

Re: UEFI secure boot issue

[Jeffrey Walton]

On Thu, Jun 20, 2024 at 9:23 AM Bhasker C V  wrote:
>
> I generated a pr/pk pair and the kernel is signed. Placed them in the
> kernel tree and compiled the kernel.

I don't think you are supposed to check-in/compile-in the private key.
It is usually supposed to stay private.

> Could someone tell me what am I doing wrong please ?
>
> Below is the status (I am using loader.efi from linuxfoundation)
> When i boot debian stock kernel signed, i see that the secure boot
> gets enabled (hence bios and everything else seems to be fine with the
> same UEFI loader).
> However, when I boot the compiled kernel I get
>
> $ dmesg | grep -i secure
> [0.007085] Secure boot could not be determined
>
>
> $ sbverify --list bootx64.efi
> warning: data remaining[91472 vs 101160]: gaps between PE/COFF sections?
> signature 1
> image signature issuers:
>  - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
> Corporation UEFI CA 2011
> image signature certificates:
>  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
>issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=Microsoft Corporation UEFI CA 2011
>  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=Microsoft Corporation UEFI CA 2011
>issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=Microsoft Corporation Third Party Marketplace Root
> $ sbverify  --list ./loader.efi
> signature 1
> image signature issuers:
>  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> image signature certificates:
>  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
>issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> $ sbverify  --list ../../linux/k.bcv
> signature 1
> image signature issuers:
>  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> image signature certificates:
>  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
>issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv


Have a look at <https://wiki.debian.org/SecureBoot>, and the use of
the Machine Owner Key (MOK).

Jeff

UEFI secure boot issue

[Bhasker C V]

Hi,

I generated a pr/pk pair and the kernel is signed. Placed them in the
kernel tree and compiled the kernel.


Could someone tell me what am I doing wrong please ?

Below is the status (I am using loader.efi from linuxfoundation)
When i boot debian stock kernel signed, i see that the secure boot
gets enabled (hence bios and everything else seems to be fine with the
same UEFI loader).
However, when I boot the compiled kernel I get

$ dmesg | grep -i secure
[0.007085] Secure boot could not be determined


$ sbverify --list bootx64.efi
warning: data remaining[91472 vs 101160]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation Third Party Marketplace Root
$ sbverify  --list ./loader.efi
signature 1
image signature issuers:
 - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
image signature certificates:
 - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
   issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
$ sbverify  --list ../../linux/k.bcv
signature 1
image signature issuers:
 - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
image signature certificates:
 - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
   issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv

Re: migrating grub from BIOS to UEFI loses /etc/default/grub

[Florent Rougon]

Le 28/05/2024, Harald Dunkel  a écrit:

> Full thread is on debian-boot mailing list.

I've read it now, thanks for the info, Harald!

Regards

-- 
Florent

Re: migrating grub from BIOS to UEFI loses /etc/default/grub

[Harald Dunkel]

Full thread is on debian-boot mailing list.

Re: migrating grub from BIOS to UEFI loses /etc/default/grub

[Florent Rougon]

Hi,

Le 24/05/2024, Harald Dunkel  a écrit:

> if I migrate from grub-pc to grub-uefi, then grub-pc.postrm
> removes /etc/default/grub on the final purge.

I confirm the behavior, have been bitten by this. IMHO, it is a nasty
bug: suppose your rely on your kernel command line to disable, say, the
IPv6 stack—because you don't need it and your firewall rules don't
handle IPv6. When grub-pc is purged, the IPv6 stack gets silently
activated on your box, even though you are still naked regarding the
firewall. :(

Regards

-- 
Florent

migrating grub from BIOS to UEFI loses /etc/default/grub

[Harald Dunkel]

Hi folks,

if I migrate from grub-pc to grub-uefi, then grub-pc.postrm
removes /etc/default/grub on the final purge.

grub2 doesn't provide much information in its man pages, but
AFAICT /etc/default/grub is still processed for UEFI, so why
is it deleted?

Regards
Harri

Re: memtest86+ on UEFI

[Max Nikulin]

On 03/12/2023 02:15, Stefan Monnier wrote:

Interesting.  I have memtest86+ 6.10-4, for amd64, on the machine.


Then AFAIK it is not a known problem (IOW, it should work).


The package contains /boot/memtest86+x64.efi, so it is intended to work 
with UEFI. I am less sure that it can work when secure boot is enabled. 
Perhaps /usr/share/doc/memtest86+/README.Debian will shed some light on 
the issue.

memtest86+ on UEFI (was: Hardware Advice Wanted: Router)

[Stefan Monnier]

> Interesting.  I have memtest86+ 6.10-4, for amd64, on the machine.

Then AFAIK it is not a known problem (IOW, it should work).

> Maybe I'll try a USB stick version.

IIRC the memtest86+ Debian package comes with .iso files which you can
(manually) put into /boot/images/ and which boot in a slightly different
way than the image files installed there by default, so you could try
that as ell.
Also upstream has a slightly more recent release.


Stefan

Getting UEFI to boot Debian (was: Hardware Advice Wanted: Router)

[Stefan Monnier]

> For the curious, I occasionally need to run Microchip MPLAB, the old
> pre-Java version which doesn't do Linux. It only just about does
> Windows... I used to think Serif software was buggy until I tried
> Microchip stuff.

Setting it up might take some work (especially if you need it to have
direct access to some of your hardware) but running it inside a VM
might save you a fair bit of trouble in the long run.


Stefan

Re: Set UEFI boot target with Windows (was: Hardware Advice Wanted: Router)

[Joe]

On Thu, 30 Nov 2023 13:27:59 +0100
Arno Lehmann  wrote:


> 
> ... have you ever tried
> 
> bcdedit /bootsequence 
> 
> In general, the built-in help of bcdedit is not bad, needs a bit of 
> patience, though.
> 
> And of course we lack the flexibility of tools such as awk or sed on 
> Windows, to automate setting things and still remain flexible :-)
> 
> On a particular system, with rather static setup, hard-coding a
> single bcdedit call and automatically execute that should be
> feasible, though.
> 
> Give it a try if you haven't done yet!
> 

I have used it in the past, when Windows moved away from boot.ini. That
was probably XP, so about twenty years ago.

I believe using it to write currently requires booting to Safe Mode,
and if I've got to reboot, it might as well be to the Debian install
disc/USB. Having got to chroot, I just use the up-arrow and it remembers
the efibootmgr command I used last time.

I haven't looked for a while, if it's possible to set NextBoot from
normal Windows it would be worth doing.

-- 
Joe

Re: Set UEFI boot target with Windows

[Max Nikulin]

On 30/11/2023 19:27, Arno Lehmann wrote:

Am 30.11.2023 um 12:52 schrieb Joe:

I have a
netbook which, left to its own devices, will always boot to Windows,
and cannot be made to boot to anything else from the UEFI part of
whatever we're supposed to call the BIOS these days.


... have you ever tried

bcdedit /bootsequence 


I have read that early UEFI versions of some vendors had hardcoded path 
to windows loader. Another variant is loader installed to "removable" 
path EFI/Boot (in additional or instead of EFI/microsoft) and firmware 
tries EFI/Boot with higher priority.


From linux:

efibootmgr -v
ls -l /boot/efi/EFI/{boot,debian,microsoft}

I have a decade-old HP laptop that boots from EFI/Boot. (Or using a 
custom boot entry with path to shimx64.efi created from the firmware 
setup menu that is less convenient.) It has never had windows installed 
though.

Set UEFI boot target with Windows (was: Hardware Advice Wanted: Router)

[Arno Lehmann]

Bit of a digression here, probably better not to pursue *this* on the 
mailing list, but...


Am 30.11.2023 um 12:52 schrieb Joe:

On Wed, 29 Nov 2023 18:34:30 -0500
Jeffrey Walton  wrote:

  


As I understand things, a well functioning UEFI system does not need
to use GRUB. The entries for Linux and Windows will be in the UEFI
boot menu, and you can boot directly using EFI variables.



It's the 'well functioning' that is sometimes a problem. I have a
netbook which, left to its own devices, will always boot to Windows,
and cannot be made to boot to anything else from the UEFI part of
whatever we're supposed to call the BIOS these days. It does not honour
DefaultBoot, always resetting it to Windows, but for some reason does
honour NextBoot. So once Linux is running, a script sets NextBoot to
grub. Unfortunately, there's no simple way to set NextBoot from
Windows,


... have you ever tried

bcdedit /bootsequence 

In general, the built-in help of bcdedit is not bad, needs a bit of 
patience, though.


And of course we lack the flexibility of tools such as awk or sed on 
Windows, to automate setting things and still remain flexible :-)


On a particular system, with rather static setup, hard-coding a single 
bcdedit call and automatically execute that should be feasible, though.


Give it a try if you haven't done yet!


There seems to be a lot of problems with the EFI commands operating
BIOSes properly, so I wonder if good old MS requires compliant
manufacturers to get it wrong deliberately.


Well...

... probably yes. But that's MS and their hardware partners for you. 
It's getting better the more MS loses interest in actually selling Windows.



Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Re: Whole-disk RAID and GPT/UEFI

[David Christensen]

On 2/23/23 11:05, Tim Woodall wrote:

On Wed, 22 Feb 2023, Nicolas George wrote:

Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?



I've wanted this ...



I think only hardware raid where the bios thinks it's a single disk ...



My wants and thinking are the same.  I can and do FOSS RAID for data 
disks, but I am baffled for boot disks.



I did desktop motherboard simple hardware RAID years ago (0, 1, 10, 
JBOD; Intel Matrix Storage Technology?).  It was configured via BIOS 
Setup.  I seem to recall that both Windows and Linux saw the RAID as a 
single SATA HDD.  Under Windows, you could download an Intel driver and 
controller app to configure and/or monitor the RAID.  I do not recall a 
driver and app for Linux.



I believe my newer motherboards/ computers also include simple hardware 
RAID.  The current Intel solution is Rapid Storage Technology.  I 
believe this is enabled on my Dells via UEFI Setup -> Settings -> System 
Configuration -> SATA Operation -> "RAID On", but I have not attempted 
to build a RAID.  (Do I need the Windows driver and app?)  I have 
discovered that Linux cannot see the disks unless the setting is changed 
to "AHCI" (?), and am curious why.



I have some 2-port SATA HBA's and believe they also support simple 
hardware RAID.  I assume they have a BIOS extension/ POST hotkey 
configuration utility, with drivers and apps for Windows.  I have used 
them in BIOS computers back in the day and in UEFI computers with 
backwards compatibility, but I do not know if they would work in the 
newest UEFI-only computers; especially with Secure Boot.



Hardware is again becoming a walled garden more so every day; especially 
with Windows 11, TPM 2, and whatever Apple does.  I look forward to open 
source hardware, such as RISC-V.



David

Re: Whole-disk RAID and GPT/UEFI

[Tim Woodall]

On Wed, 22 Feb 2023, Nicolas George wrote:


Hi.

Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?



I've wanted this but settled for using dd to copy the start of the disk,
fdisk to rewrite the GPT properly then mdadm to rebuild the raid on the
remainder.

My understanding is that UEFI can potentially write, bypassing the raid
and causing the two drives to be out of sync anyway. I think only
hardware raid where the bios thinks it's a single disk can avoid this
(or software raid aware bios I guess)

Re: Whole-disk RAID and GPT/UEFI

[Juri Grabowski]

Hello,

I have seen some installations with following setup:
GPT
sda1 sdb1 bios_grub md1 0.9 
sda2 sdb2 efi md2 0.9 
sda3 sdb3 /boot md3 0.9
sda4 sdb4 / md? 1.1

on such installations it's important, that  grub installation is made
with "grub-install --removable"
I mean it was some grub bugs about update grub on such installations,
but if you don't blindly update the machine and reboot it shouldn't be the
problem.

Best Regards,
Juri Grabowski

Re: Whole-disk RAID and GPT/UEFI

[DdB]

Am 22.02.2023 um 17:07 schrieb Nicolas George:
> Unfortunately, that puts the partition table
> and EFI partition outside the RAID: if you have to add/replace a disk,
> you need to partition and reinstall GRUB, that makes a few more
> manipulations on top of syncing the RAID.

Yes, i get it. AFAIK, you cannot really avoid that, because a disk
replacement comes with new disk UUID's anyway and slightly different
sizes mostly. Maybe the best thing to do is to document, and maybe
script that case with your knowledge from today. that way, you can go to
sleeo until the case happens, and then read the doc (in your script) and
execute it. That is what i do (because i keep forgetting things faster
and faster ;-))

And usually, the script gets better over time after several runs ...

Sorry, that i have no better suggestion.
Good luck
DdB

Re: Whole-disk RAID and GPT/UEFI

[Dan Ritter]

Nicolas George wrote: 
> Hi.
> 
> Is there a solution to have a whole-disk RAID (software, mdadm) that is
> also partitioned in GPT and bootable in UEFI?

Not that I know of. An EFI partition needs to be FAT32 or VFAT.

What I think you could do:

Partition the disks with GPT: 2 partitions each, EFI and mdadm
raid. We'll call these sda1 and sda2, and sdb1 and sdb2.

Install Debian. Use sda1 for EFI (/boot/efi), sda2/sdb2 for mdadm to create
md0.

Create a degraded mdadm mirror on sdb1, with metadata 1.0. Call
this md1.

mkfs vfat on md1. Mount it as /mnt/tmp. Get the UUID and put it in
/etc/fstab as the new value for /boot/efi.

copy everything from /boot/efi to /mnt/tmp. sync, and umount
/mnt/tmp.

wipefs /dev/sda1, then use mdadm to add it to md1.

After the resynch is finished (watch /proc/mdstat), try a
reboot.

Note that UEFI should detect this as two different boot disks,
and will not automatically switch between them. But booting
after sda fails should be as simple as switching to sdb1.

I have not tested this. I could be wrong.

-dsr-

Re: Whole-disk RAID and GPT/UEFI

[Nicolas George]

DdB (12023-02-22):
> I cannot say yes or no. But, of the top of my head, i know, that gdisk
> does support a strange thing called hybrid between MBR and GPT, where a
> clean GPT formatted drive contains (instead of a protective MBR)

I have toyed with hybrid GPT in the past, in the hope to make an USB
stick that was bootable in legacy mode, bootable in UEFI mode and usable
as a regular USB stick (spoiler: it worked, until I tried it with
Windows.)

But it will not help for this issue.

> The only issue, i have had a look at, was the problem to have a raid,
> that is bootable no matter which one of the drives initially fails, a
> problem, that can be solved by having at least 2 grub installs (on the
> two mirrors).
> 
> Certainly, there is a solution to your problem, even if might not
> exactly fulfill your premises.

I know of this solution. Unfortunately, that puts the partition table
and EFI partition outside the RAID: if you have to add/replace a disk,
you need to partition and reinstall GRUB, that makes a few more
manipulations on top of syncing the RAID.

Regards,

-- 
  Nicolas George

Re: Whole-disk RAID and GPT/UEFI

[DdB]

Am 22.02.2023 um 16:30 schrieb Nicolas George:
> Is there something I have missed?

I cannot say yes or no. But, of the top of my head, i know, that gdisk
does support a strange thing called hybrid between MBR and GPT, where a
clean GPT formatted drive contains (instead of a protective MBR) an MBR
with pointers to up to four partitons, in order to make a system
bootable without UEFI. I understand, that your use case is somewhat
different. But maybe you can use the idea anyway. The hybrid formatting
has some restrictions, like you should not have standard MBR tools mess
this configuration up (not use them at all) and unfortunately that
applies to standard GPT tools as well, but the dual bootability can
solve some problems.

The only issue, i have had a look at, was the problem to have a raid,
that is bootable no matter which one of the drives initially fails, a
problem, that can be solved by having at least 2 grub installs (on the
two mirrors).

Certainly, there is a solution to your problem, even if might not
exactly fulfill your premises.

Whole-disk RAID and GPT/UEFI

[Nicolas George]

Hi.

Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?

What I imagine:

- RAID1, mirroring: if you ignore the RAID, the data is there.

- The GPT metadata is somewhere not too close to the beginning of the
  drive nor too close to the end, to not conflict with the GPT, but the
  space before / after the metadata is part of the RAID and synced.

- The firmware, not aware of RAID, sees a perfectly normal GPT partition
  scheme, just with some unallocated space before the first partition or
  after the last where the RAID metadata happen to reside.

- The kernel or a userspace tool like kpartx translates the offsets of
  the GPT partitions into offsets inside the RAID, skipping the
  metadata, and creates partitions inside the RAID device.

The benefit would be that the RAID would cover also the EFI partition
and the partition table itself. Since these are things that only change
at known times and are very small, the benefit is limited, but that
still would be nice.

At this time, as far as I can see: RAID metadata versions 1.0, 1.1 and
1.2 conflict with GPT because:

- 1.2 puts the superblock at sector 8;
- 1.1 puts the superblock at sector 0;
- 1.0 puts the superblock at sector end-16;
- GPT uses the sectors [0;34[ and [end-33;end[.

Metadata 0.9 uses the sectors [end-128;end-120[, not conflicting with
GPT and causing no offset for the partitions, but the data after that is
not part of the RAID, so the secondary GPT would not be synchronized.

Also, metadata 0.9 has limitations.

(I have not tested metadata ddf or imsm because they do not support
RAID1 on only one device, which is what I intend to do and what I was
testing on.)

Is there something I have missed?

Regards,

-- 
  Nicolas George

Re: Re: howto install Debian on software RAID1 when UEFI?

[Andrew M.A. Cater]

Hi hw,

Having followed through the steps I outlined:

> I'm about to try this on a VM with two disks. I'm going to initially partition
> as if I were using LVM and all in one partition on one disk, then on the other

> That should give me identically sized partitions.

> At that point, I'll change the type on the LVM partitions to RAID, and use
> use the RAID partitioner to make a RAID1 device.

> At that point, I'll change the type on the LVM partitions to RAID, and use
> use the RAID partitioner to make a RAID1 device.

> After that, I'll use one of the ESP partitons and tell the partitioner
> to install all in one partition on the RAID device.

> I'll then change the type of the partition installed to btrfs.

> That should give me EFI - RAID - swap on each of two disks.
> The RAID should be RAID1 and will be mounted as /

This all worked.

I then rebooted into rescue mode, typed in the root password and typed 

update-grub /dev/sdb

which appeared to work fine.

Hope this helps, with every good wish as ever,

Andy Cater

Re: howto install Debian on software RAID1 when UEFI?

[Andrew M.A. Cater]

On Sun, Nov 13, 2022 at 05:29:17PM +0100, hw wrote:
> On Sun, 2022-11-13 at 14:32 +, Andrew M.A. Cater wrote:
> > On Sun, Nov 13, 2022 at 02:49:28PM +0100, hw wrote:
> > > 
> > > Hi,
> > > 
> > > the Debian installer is horrible.  It won't let me install on software 
> > > RAID1
> > > on
> > > a server with an UEFI BIOS.  I can't find any good guide about that, 
> > > either.
> > > 
> > 
> > Hi hw
> > 
> > You might want to *start* with using the expert install - found under the 
> > advanced menu option. That will give you more control, including advanced
> > partitioning.
> 
> That's where I kept ending up.  I didn't want that, it needs to be easy to
> install on software RAID.  Not everyone has hardware RAID to boot from.
> 

And that's why I suggested the advanced partitioning. I only have software
RAID - as do most people now.

I'm about to try this on a VM with two disks. I'm going to initially partition
as if I were using LVM and all in one partition on one disk, then on the other.
That should give me identically sized partitions.

At that point, I'll change the type on the LVM partitions to RAID, and use
use the RAID partitioner to make a RAID1 device.

After that, I'll use one of the ESP partitons and tell the partitioner
to install all in one partition on the RAID device.

[I'm fairly sure Fedora also installs LVM by default as it makes it a lot
easier to resize partitions if necessary when adding more storage.]
I'll then change the type of the partition installed to btrfs.

That should give me EFI - RAID - swap on each of two disks.
The RAID should be RAID1 and will be mounted as /

> > > I want root on brtfs with RAID1.  How do I get Debian installed?
> > 
> > I'd suggest that you partition one disk with "all files in one partition"
> > as a test run to see the sizes you'll need and then rerun the partitioner.
> 
> Yeah that failed.  The installer was unable to install grub, then it was 
> unable
> to mount /boot/efi ...  It's not working right at all.
> 

Let me run through the process: I'm reformatting a spare machine so that its
running Stable then I'll run through in a KVM/QEMU machine with virt-manager.

> > > From memory, I think you end up with something like an EFI partition of
> > > 512M,
> > a root partition of (the rest - 1G) and then a 1G swap.
> > 
> > If you partition both disks to have an EFI partition at the beginning, then
> > a RAID partition, then 2 x 1G swap at the end.
> 
> Yeah that's what I tried.
> 
> > Then use the RAID manager to set up RAID1 and LVM over the top.
> 
> There's no way that I would use LVM.  That's yet another layer of complexitiy
> with no advantages whatsoever and a nightmare to deal with.  I used it once 
> and
> I'll never do that again.
> 
> >  I'm unsure how
> > you would install GRUB to the second disk of the RAID - it might be that 
> > you'd
> > need to restart once the install is complete, use the rescue option and
> > specifically install GRUB on the second disk of the RAID.
> 
> It used to be possible to just install it on the other disk.  But I didn't get
> that far.
> 
> After over half a day and some reboots, I finally got it to install on a 
> single
> disk without any redundancy.  I'll have to partition the 2nd disk later after 
> I
> figured out how to add another IPv6 address to one of the interfaces --- easy
> with network manager on Fedora (which also installs on software RAID),
> impossible with Debian.
> 
> I won't be able to boot when the disk I installed on failed.  In this case, it
> doesn't matter too much, but if that was a remote server there would be no way
> to get it installed without hardware RAID.
> 
> Debian really needs to work a lot on the installer.  It used to be easy to
> install Debian, but now it's a nightmare.
> 
> > > 
> > > The graphical version crashes with a kernel panic when booting from an USB
> > > stick, so I need to use the normal installer.
> > 
> > Then you have wider problems than just installation, perhaps?
> > 
> 
> No, why would you say that.
> 

If you can't boot the graphical installer but you can boot the text
installer, there's something wrong somewhere. How did you write the USB
stick and did you test the integrity of the media?

> > > There's even not a way to select RAID1 for btrfs.  What an anachronism ...
> > > 
> > 
> > You do know that this is a general purpose installer that covers 12 or so
> > files

Re: howto install Debian on software RAID1 when UEFI?

[hw]

On Sun, 2022-11-13 at 14:32 +, Andrew M.A. Cater wrote:
> On Sun, Nov 13, 2022 at 02:49:28PM +0100, hw wrote:
> > 
> > Hi,
> > 
> > the Debian installer is horrible.  It won't let me install on software RAID1
> > on
> > a server with an UEFI BIOS.  I can't find any good guide about that, either.
> > 
> 
> Hi hw
> 
> You might want to *start* with using the expert install - found under the 
> advanced menu option. That will give you more control, including advanced
> partitioning.

That's where I kept ending up.  I didn't want that, it needs to be easy to
install on software RAID.  Not everyone has hardware RAID to boot from.

> > I want root on brtfs with RAID1.  How do I get Debian installed?
> 
> I'd suggest that you partition one disk with "all files in one partition"
> as a test run to see the sizes you'll need and then rerun the partitioner.

Yeah that failed.  The installer was unable to install grub, then it was unable
to mount /boot/efi ...  It's not working right at all.

> > From memory, I think you end up with something like an EFI partition of
> > 512M,
> a root partition of (the rest - 1G) and then a 1G swap.
> 
> If you partition both disks to have an EFI partition at the beginning, then
> a RAID partition, then 2 x 1G swap at the end.

Yeah that's what I tried.

> Then use the RAID manager to set up RAID1 and LVM over the top.

There's no way that I would use LVM.  That's yet another layer of complexitiy
with no advantages whatsoever and a nightmare to deal with.  I used it once and
I'll never do that again.

>  I'm unsure how
> you would install GRUB to the second disk of the RAID - it might be that you'd
> need to restart once the install is complete, use the rescue option and
> specifically install GRUB on the second disk of the RAID.

It used to be possible to just install it on the other disk.  But I didn't get
that far.

After over half a day and some reboots, I finally got it to install on a single
disk without any redundancy.  I'll have to partition the 2nd disk later after I
figured out how to add another IPv6 address to one of the interfaces --- easy
with network manager on Fedora (which also installs on software RAID),
impossible with Debian.

I won't be able to boot when the disk I installed on failed.  In this case, it
doesn't matter too much, but if that was a remote server there would be no way
to get it installed without hardware RAID.

Debian really needs to work a lot on the installer.  It used to be easy to
install Debian, but now it's a nightmare.

> > 
> > The graphical version crashes with a kernel panic when booting from an USB
> > stick, so I need to use the normal installer.
> 
> Then you have wider problems than just installation, perhaps?
> 

No, why would you say that.

> > There's even not a way to select RAID1 for btrfs.  What an anachronism ...
> > 
> 
> You do know that this is a general purpose installer that covers 12 or so
> filesystem types and allows for flexibility?

Fedoras installer does a better much job.  I didn't want endless flexibility but
a simple standard installation on software RAID.  That used to be easy with
Debian.

> With every good wish, as ever,
> 
> Andy Cater 
> 

Re: howto install Debian on software RAID1 when UEFI?

[Andy Smith]

Hello,

On Sun, Nov 13, 2022 at 02:32:06PM +, Andrew M.A. Cater wrote:
> If you partition both disks to have an EFI partition at the beginning, then
> a RAID partition, then 2 x 1G swap at the end.
> 
> Then use the RAID manager to set up RAID1 and LVM over the top. I'm unsure how
> you would install GRUB to the second disk of the RAID - it might be that you'd
> need to restart once the install is complete, use the rescue option and
> specifically install GRUB on the second disk of the RAID.

Do note that OP has not made clear whether they want btrfs on top of MD
RAID-1, or btrfs with its own "raid1" data profile (which is not at all
the same as MD RAID-1 and isn't installed the same way).

I'm not sure whether you can set up multi-device btrfs in the installer,
though if you can't it would be easy to just install to one device, add
the second device afterwards and then do a balance to split the data
equally.

Also OP should note that whichever way you go, the EFI System Partition
technically can't go in any form of software RAID, so at the moment you
have to have two of them and manage them individually somehow:

"Redundancy for EFI System Partition: what do people do in 2020?"
https://lists.debian.org/debian-user/2020/11/msg00455.html

(same answers now in 2022)

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: howto install Debian on software RAID1 when UEFI?

[Andrew M.A. Cater]

On Sun, Nov 13, 2022 at 02:49:28PM +0100, hw wrote:
> 
> Hi,
> 
> the Debian installer is horrible.  It won't let me install on software RAID1 
> on
> a server with an UEFI BIOS.  I can't find any good guide about that, either.
> 

Hi hw

You might want to *start* with using the expert install - found under the 
advanced menu option. That will give you more control, including advanced
partitioning.

> I want root on brtfs with RAID1.  How do I get Debian installed?

I'd suggest that you partition one disk with "all files in one partition"
as a test run to see the sizes you'll need and then rerun the partitioner.

>From memory, I think you end up with something like an EFI partition of 512M,
a root partition of (the rest - 1G) and then a 1G swap.

If you partition both disks to have an EFI partition at the beginning, then
a RAID partition, then 2 x 1G swap at the end.

Then use the RAID manager to set up RAID1 and LVM over the top. I'm unsure how
you would install GRUB to the second disk of the RAID - it might be that you'd
need to restart once the install is complete, use the rescue option and
specifically install GRUB on the second disk of the RAID.

> 
> The graphical version crashes with a kernel panic when booting from an USB
> stick, so I need to use the normal installer.

Then you have wider problems than just installation, perhaps?

> 
> There's even not a way to select RAID1 for btrfs.  What an anachronism ...
>

You do know that this is a general purpose installer that covers 12 or so
filesystem types and allows for flexibility?

With every good wish, as ever,

Andy Cater 

howto install Debian on software RAID1 when UEFI?

[hw]

Hi,

the Debian installer is horrible.  It won't let me install on software RAID1 on
a server with an UEFI BIOS.  I can't find any good guide about that, either.

I want root on brtfs with RAID1.  How do I get Debian installed?

The graphical version crashes with a kernel panic when booting from an USB
stick, so I need to use the normal installer.

There's even not a way to select RAID1 for btrfs.  What an anachronism ...

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[vinceh121]

Thanks a lot, this is very useful!

 - vinceh121

On 9/18/22 13:42, Steve McIntyre wrote:

On Sat, Sep 17, 2022 at 03:07:29AM +0200, vinceh121 wrote:

Thanks, this works!

Is there a way to set this option during installation on a netinst image?


Yes! You can switch to expert mode for installation and then
grub-efi-$ARCH will ask you these questions. Or you can add these
options using a preseed, tweaking the following settings to change
from the default answers.

### Description: Force extra installation to the EFI removable media path?
#   Some EFI-based systems are buggy and do not handle new bootloaders 
correctly.
#   If you force an extra installation of GRUB to the EFI removable media path,
#   this should ensure that this system will boot Debian correctly despite such 
a
#   problem. However, it may remove the ability to boot any other operating
#   systems that also depend on this path. If so, you will need to make sure 
that
#   GRUB is configured successfully to be able to boot any other OS 
installations
#   correctly.
# d-i grub2/force_efi_extra_removable boolean false

### Description: Update NVRAM variables to automatically boot into Debian?
#   GRUB can configure your platform's NVRAM variables so that it boots into
#   Debian automatically when powered on. However, you may prefer to disable
#   this behavior and avoid changes to your boot configuration. For example,
#   if your NVRAM variables have been set up such that your system contacts a
#   PXE server on every boot, this would preserve that behavior.
# d-i grub2/update_nvram boolean true



OpenPGP_signature
Description: OpenPGP digital signature

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[Steve McIntyre]

On Sat, Sep 17, 2022 at 03:07:29AM +0200, vinceh121 wrote:
>Thanks, this works!
>
>Is there a way to set this option during installation on a netinst image?

Yes! You can switch to expert mode for installation and then
grub-efi-$ARCH will ask you these questions. Or you can add these
options using a preseed, tweaking the following settings to change
from the default answers.

### Description: Force extra installation to the EFI removable media path?
#   Some EFI-based systems are buggy and do not handle new bootloaders 
correctly.
#   If you force an extra installation of GRUB to the EFI removable media path,
#   this should ensure that this system will boot Debian correctly despite such 
a
#   problem. However, it may remove the ability to boot any other operating
#   systems that also depend on this path. If so, you will need to make sure 
that
#   GRUB is configured successfully to be able to boot any other OS 
installations
#   correctly.
# d-i grub2/force_efi_extra_removable boolean false

### Description: Update NVRAM variables to automatically boot into Debian?
#   GRUB can configure your platform's NVRAM variables so that it boots into
#   Debian automatically when powered on. However, you may prefer to disable
#   this behavior and avoid changes to your boot configuration. For example,
#   if your NVRAM variables have been set up such that your system contacts a
#   PXE server on every boot, this would preserve that behavior.
# d-i grub2/update_nvram boolean true

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[vinceh121]

Thanks, this works!

Is there a way to set this option during installation on a netinst image?
 - vinceh121


On 9/17/22 00:03, Steve McIntyre wrote:

vinceh121 wrote:


Southern French government is handing out laptops (HP ProBook x360 G1
EE) to students, whom a lot of want to install a Linux distro on.

However, many distros installs are broken by grub-install either safely
failing, or making the kernel hang while trying to write NVRAM boot
options. I've confirmed this on Debian Buster and Bullseye.

This causes the netinst images to give us a mostly working installation,
except for a config-less GRUB. For now, we've gone around this by
manually booting with the GRUB CLI, and then running grub-install with
the --no-nvram option.

However, the problem reappears when running apt upgrade.

Is there a way to mitigate this problem? Maybe a way to tell
grub-install to always use --no-nvram?


Yup. See 
https://wiki.debian.org/UEFI#Firmware_does_not_support_setting_boot_variables



OpenPGP_signature
Description: OpenPGP digital signature

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[Steve McIntyre]

vinceh121 wrote:
>
>Southern French government is handing out laptops (HP ProBook x360 G1 
>EE) to students, whom a lot of want to install a Linux distro on.
>
>However, many distros installs are broken by grub-install either safely 
>failing, or making the kernel hang while trying to write NVRAM boot 
>options. I've confirmed this on Debian Buster and Bullseye.
>
>This causes the netinst images to give us a mostly working installation, 
>except for a config-less GRUB. For now, we've gone around this by 
>manually booting with the GRUB CLI, and then running grub-install with 
>the --no-nvram option.
>
>However, the problem reappears when running apt upgrade.
>
>Is there a way to mitigate this problem? Maybe a way to tell 
>grub-install to always use --no-nvram?

Yup. See 
https://wiki.debian.org/UEFI#Firmware_does_not_support_setting_boot_variables

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[DdB]

Am 16.09.2022 um 20:19 schrieb vinceh121:
> Is there a way to mitigate this problem?

Apart from the plan, you seem to be favoring, i would like to introduce
another option to you:
(BTW: I used it myself, and still do, while i was learning to
reconfigure to UEFI-Booting)

There is a sort of boot manager, that is perfectly independant from
grub, but can use grub, if desired. i am thinking of refind (is in
debian repos and also available from website by the author of gdisk).

I suggest you take a look as it *might* be able to start independantly
without the necessity to use NVRAM.

just my 2 cents
DdB

Re: How to start Preseed installation on UEFI computer?

[Hans]

> Steve wrote:
>
> 3. Move the cursor to near the end of the line, before the "---"
> separator and add any extra command line options you need there.
>

After too many trials and errors I found that the following two variables / 
kernel parameters do the trick:

auto=true

url=http://example.com/my-preseed.cfg

* https://pasteboard.co/HB4yjvB9mFfV.png

In future I might try to modify Debian ISO and change the default GRUB config 
so the only thing needed is to boot it and it'll install OS.

Thank very much.

Hans

Re: How to start Preseed installation on UEFI computer?

[Steve McIntyre]

Hans wrote:
>Steve wrote:
>>
>> If you hit E, that will let you edit the currently-loaded grub
>> config so you can append preseed and other options.
>
>I thought about that since hit all keys trying to get to cmd prompt
>like when booting from BIOS. But I didn't find any documentation /
>example what needs to be edited / added. Could you please point me to
>some example? I literally just need "auto https://"; and maybe an
>option for serial output instead of VGA but that's just an optional
>bonus ;-).

Ah, sorry. It looks like we maybe don't have clear enough docs here.

1. On the grub menu, use the cursor keys to select the menu entry you
   want to edit, and press the E key.

2. Move the cursor down 3 lines to find the command line for the kernel.
   This is the line starting with "linux".

3. Move the cursor to near the end of the line, *before* the "---"
   separator and add any extra command line options you need there.

4. Hit Ctrl-x or F10 to boot

As mentioned separately, you'll probably want to do this starting with
the "Advanced Options ..." / "... Automated install" boot option.

OK? Hope that helps...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: How to start Preseed installation on UEFI computer?

[Hans]

> Hans wrote:
>
> > Dear Debian Users and Maintainers,
> >
> > I want to automate Debian installation using Preseed. I started with baby 
> > steps creating a preseed file installing
> > Debian on VM. All good.
> >
> > Then I continued with my actual goal to install Debian on a server / laptop 
> > and I hit a problem... I don't know how
> > to start the Pressed installation on UEFI hardware.
> >
> > When I boot ISO on a BIOS virtual machine I get this screen:
> >
> > https://pasteboard.co/nnvxHDvOZP6C.png
> >
> > I hit Esc and type "auto path-to-the-file":
> >
> > https://pasteboard.co/gXpsslGWHx9L.png
> >
> > And it Debian gets installed.
> >
> > But when I boot UEFI I get this screen:
> >
> > https://pasteboard.co/a0E0HDUlMq6G.png
> >
> > And Esc doesn't do anything...
> >
> > Could you please tell how to start Preseed installation when booting UEFI?
>
>
> If you hit E, that will let you edit the currently-loaded grub
> config so you can append preseed and other options.

I thought about that since hit all keys trying to get to cmd prompt like when 
booting from BIOS. But I didn't find any documentation / example what needs to 
be edited / added. Could you please point me to some example? I literally just 
need "auto https://"; and maybe an option for serial output instead of VGA 
but that's just an optional bonus ;-).

Thank you Steve.

Re: How to start Preseed installation on UEFI computer?

[Hans]

> On 2022-06-06, Hans hans.str...@protonmail.com wrote:
>
> > Dear Debian Users and Maintainers,
> >
> > I want to automate Debian installation using Preseed. I started with baby 
> > steps creating a preseed file installing Debian on VM. All good.
> >
> > Then I continued with my actual goal to install Debian on a server / laptop 
> > and I hit a problem... I don't know how to start the Pressed installation 
> > on UEFI hardware.
> >
> > When I boot ISO on a BIOS virtual machine I get this screen:
> >
> > https://pasteboard.co/nnvxHDvOZP6C.png
> >
> > I hit Esc and type "auto path-to-the-file":
> >
> > https://pasteboard.co/gXpsslGWHx9L.png
> >
> > And it Debian gets installed.
> >
> > But when I boot UEFI I get this screen:
> >
> > https://pasteboard.co/a0E0HDUlMq6G.png
> >
> > And Esc doesn't do anything...
> >
> > Could you please tell how to start Preseed installation when booting UEFI?
> >
> > Thank you.
> >
> > Kind regards,
> >
> > Hans
>
>
> I'm reading the following:
>
> The “Advanced options” entry gives access to a second menu that allows
> to boot the installer in expert mode, in rescue mode and for automated
> installs.
>
>
> https://www.debian.org/releases/bullseye/amd64/ch05s01.en.html
>
> Maybe your cat can be skinned in another manner.

The Automated option in Advanced actually asks for preseed so that's good 
enough for now for testing. Thank you ;-).

Re: How to start Preseed installation on UEFI computer?

[Steve McIntyre]

Hans wrote:
>
>Dear Debian Users and Maintainers,
>
>I want to automate Debian installation using Preseed. I started with baby 
>steps creating a preseed file installing
>Debian on VM. All good.
>
>Then I continued with my actual goal to install Debian on a server / laptop 
>and I hit a problem... I don't know how
>to start the Pressed installation on UEFI hardware.
>
>When I boot ISO on a BIOS virtual machine I get this screen:
>
>https://pasteboard.co/nnvxHDvOZP6C.png
>
>I hit Esc and type "auto path-to-the-file":
>
>https://pasteboard.co/gXpsslGWHx9L.png
>
>And it Debian gets installed.
>
>But when I boot UEFI I get this screen:
>
>https://pasteboard.co/a0E0HDUlMq6G.png
>
>And Esc doesn't do anything...
>
>Could you please tell how to start Preseed installation when booting UEFI?

If you hit E, that will let you edit the currently-loaded grub
config so you can append preseed and other options.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: How to start Preseed installation on UEFI computer?

[Curt]

On 2022-06-06, Hans  wrote:
> Dear Debian Users and Maintainers,
>
> I want to automate Debian installation using Preseed. I started with baby 
> steps creating a preseed file installing Debian on VM. All good.
>
> Then I continued with my actual goal to install Debian on a server / laptop 
> and I hit a problem... I don't know how to start the Pressed installation on 
> UEFI hardware.
>
> When I boot ISO on a BIOS virtual machine I get this screen:
>
> https://pasteboard.co/nnvxHDvOZP6C.png
>
> I hit Esc and type "auto path-to-the-file":
>
> https://pasteboard.co/gXpsslGWHx9L.png
>
> And it Debian gets installed.
>
> But when I boot UEFI I get this screen:
>
> https://pasteboard.co/a0E0HDUlMq6G.png
>
> And Esc doesn't do anything...
>
> Could you please tell how to start Preseed installation when booting UEFI?
>
> Thank you.
>
> Kind regards,
>
> Hans
>
>

I'm reading the following:

 The “Advanced options” entry gives access to a second menu that allows
 to boot the installer in expert mode, in rescue mode and for automated
 installs.


https://www.debian.org/releases/bullseye/amd64/ch05s01.en.html

Maybe your cat can be skinned in another manner.

- 

How to start Preseed installation on UEFI computer?

[Hans]

Dear Debian Users and Maintainers,

I want to automate Debian installation using Preseed. I started with baby steps 
creating a preseed file installing Debian on VM. All good.

Then I continued with my actual goal to install Debian on a server / laptop and 
I hit a problem... I don't know how to start the Pressed installation on UEFI 
hardware.

When I boot ISO on a BIOS virtual machine I get this screen:

https://pasteboard.co/nnvxHDvOZP6C.png

I hit Esc and type "auto path-to-the-file":

https://pasteboard.co/gXpsslGWHx9L.png

And it Debian gets installed.

But when I boot UEFI I get this screen:

https://pasteboard.co/a0E0HDUlMq6G.png

And Esc doesn't do anything...

Could you please tell how to start Preseed installation when booting UEFI?

Thank you.

Kind regards,

Hans

Re: Strange permissions issue with virt-install + UEFI

[Matt Ventura]

On 5/13/2022 6:53 PM, David wrote:

On Sat, 14 May 2022 at 10:57, Matt Ventura  wrote:


On one box (Debian 11.3), my virt-install script works fine:
virt-install [...]
However, on another box, the same command (minus the final --network option) 
gives me this:

[...]

Could not open '/var/lib/libvirt/qemu/nvram/openwisp_VARS.fd': Permission denied

[...]

Any ideas?

You don't mention which user is running the 'virt-install' commands.
I suggest to think about that.

https://wiki.debian.org/KVM says:
   In order to manage virtual machines as a regular user, that user
needs to be added to the libvirt group:
   # adduser  libvirt

On both machines, check that the user (who is running the virt-install
command) is a member of group=libvirt.

Run: groups | grep libvirt

I'm not sure if this is the answer, but it is the first thing I would check.
Also, test if that user can read the file openwisp_VARS.fd via its
full path.

On the broken machine, it fails even if I run it as root. Root isn't a 
member of libvirt on either machine, but root is root, so it shouldn't 
be getting permission denied either way. Perhaps the file is being 
created as libvirt-qemu, but the plain old libvirt user needs to access 
it too? That's the only thing I can think of, since root ignores 
permissions anyway.


I did try to `su` into the libvirt-qemu user, and the path was reachable 
via the full absolute path. I could create, modify, read, and delete 
files in that dir.


Some searching pointed to it being an AppArmor problem, but AA is 
enabled on both.


Matt Ventura

Re: Strange permissions issue with virt-install + UEFI

[David]

On Sat, 14 May 2022 at 10:57, Matt Ventura  wrote:

> On one box (Debian 11.3), my virt-install script works fine:
> virt-install [...]

> However, on another box, the same command (minus the final --network option) 
> gives me this:
[...]
> Could not open '/var/lib/libvirt/qemu/nvram/openwisp_VARS.fd': Permission 
> denied
[...]
> Any ideas?

You don't mention which user is running the 'virt-install' commands.
I suggest to think about that.

https://wiki.debian.org/KVM says:
  In order to manage virtual machines as a regular user, that user
needs to be added to the libvirt group:
  # adduser  libvirt

On both machines, check that the user (who is running the virt-install
command) is a member of group=libvirt.

Run: groups | grep libvirt

I'm not sure if this is the answer, but it is the first thing I would check.
Also, test if that user can read the file openwisp_VARS.fd via its
full path.

Strange permissions issue with virt-install + UEFI

[Matt Ventura]

Hi,

On one box (Debian 11.3), my virt-install script works fine:

virt-install --virt-type kvm --name $NEWVM 
--locationhttp://ftp.us.debian.org/debian/dists/bullseye/main/installer-amd64  
--extra-args "netcfg/hostname=$NEWVM" -v  \
--os-variant debian11 --disk 
size=30,pool=vmvol,bus=scsi,discard=unmap,cache=writeback,io=threads --disk 
size=4,pool=vmvol-nobackup,bus=scsi,discard=unmap,cache=unsafe,io=threads \
--memory 8196 --initrd-inject=preseed.cfg --noautoconsole  --boot uefi 
--graphics spice --video virtio --controller=scsi,model=virtio-scsi 
--network=bridge=virbr1,model=virtio


However, on another box, the same command (minus the final --network 
option) gives me this:



ERROR    internal error: process exited while connecting to monitor: 
2022-05-14T00:11:48.169264Z qemu-system-x86_64: -blockdev \

{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/openwisp_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}:
 \
Could not open '/var/lib/libvirt/qemu/nvram/openwisp_VARS.fd': Permission denied
Domain installation does not appear to have been successful.

First idea was to check the perms of the /var/lib/libvirt-qemu/nvram 
directory. On both boxes, it is owned by user+group libvirt-qemu, mode 
0755. The files themselves seem to be owned by libvirt-qemu:libvirt-qemu 
as well.


On the failing box, the new file /is/ created:

-rw---  1 libvirt-qemu libvirt-qemu 540672 May 13 16:39 openwisp_VARS.fd

So, I'm really not sure why it thinks it's failing, but it aborts the 
installation regardless.


Any ideas?

Matt Ventura

Re: Dual boot - first time using UEFI

[Felix Miata]

Hans composed on 2022-05-02 12:44 (UTC+0200):
...
> When I got it running, I tried to install grub again onto the MBR, which was 
> successfull. But now appeared a blue screen, with choices: "Wait 10 seconds - 
> go on - Restart - Do not ask any more" (similar, is from my remembers).
...
> Can ssomebody explain, what technically the grub installer did do? At one 
> point it said "I have dicovered another EFI partition, shall I use it?" (or 
> similar, it is from my remembers)

Grub's job starts differently with GPT and UEFI. The UEFI firmware holds the key
to booting, not the MBR. The firmware loads the designated Grub loader, whether
that designated and stored in NVRAM, or selected from using the BBS menu, from 
the
ESP, instead of loading MBR code. Installing Grub to MBR should equate to a 
no-op
on a disk used for UEFI booting.

The Debian installer may have created a separate ESP rather than using the one
that Windows created. It's hard to explain what happened exactly without output
from parted -l or fdisk -l or equivalent, both before and after the Debian
installation process.

Managing which OS controls boot is simpler with UEFI. From Debian boot, it is 
done
with efibootmgr command, but it can be done directly in UEFI setup as well.
-- 
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

Re: Dual boot - first time using UEFI

[Andrew M.A. Cater]

On Mon, May 02, 2022 at 12:44:32PM +0200, Hans wrote:
> Hi folks, 
> 
> yesterday I installed debian bullseye besides a windows system. As UEFI could 
> not switched off, I used gparted to make the windows partition smaller. 
> 
> Then used an usb-stick and installed bullseye as usual.
> 
> However, the installer discovered UEFI and respected this, but atthe first 
> boot, only windows could still be booted. 
> 
> But the bios allowed me, to boot into windows again (using the F12 key) , and 
> I could start the installed debian.
> 
> When I got it running, I tried to install grub again onto the MBR, which was 
> successfull. But now appeared a blue screen, with choices: "Wait 10 seconds - 
> go on - Restart - Do not ask any more" (similar, is from my remembers).
> 
> After choosing "Do not ask any more", the next reboot showed me the well 
> known 
> grub starting screen.
> 
> Well, everything is working, but the problem is: I have nothing learnt of 
> this! 
> 
> Can ssomebody explain, what technically the grub installer did do? At one 
> point it said "I have dicovered another EFI partition, shall I use it?" (or 
> similar, it is from my remembers).
> 
> Thanky for making things clear.
> 
> Best 
> 
> Hans
> 

Hello Hans,

I think this has also been covered in another thread here. 

If Windows is the _only_ system on a disk, it hijacks the UEFI booting
process slightly :)

Most people never notice this because they don't dual boot ever.

If you install Debian first, it will install entries into the EFI 
partition. If you then install Windows, it will set its own EFI entries as
first and does not recognise any other operating system. 

If you have Windows installed first and then install Debian, it _should_
run os-prober and discover that Windows is already there and set it as
an entry within grub-efi and Grub's menus.

If not, you still end up with Windows first and have to boot using a
recovery disk somehow. Rerunning the grub install process at this point
does install os-prober and then the system "just works", I think.

See also the notes to Richard Owlett about how to dual boot a Debian/
Windows system in the other thread.

With every good wish, as ever,

Andy Cater




>  
> 
> 

Dual boot - first time using UEFI

[Hans]

Hi folks, 

yesterday I installed debian bullseye besides a windows system. As UEFI could 
not switched off, I used gparted to make the windows partition smaller. 

Then used an usb-stick and installed bullseye as usual.

However, the installer discovered UEFI and respected this, but atthe first 
boot, only windows could still be booted. 

But the bios allowed me, to boot into windows again (using the F12 key) , and 
I could start the installed debian.

When I got it running, I tried to install grub again onto the MBR, which was 
successfull. But now appeared a blue screen, with choices: "Wait 10 seconds - 
go on - Restart - Do not ask any more" (similar, is from my remembers).

After choosing "Do not ask any more", the next reboot showed me the well known 
grub starting screen.

Well, everything is working, but the problem is: I have nothing learnt of 
this! 

Can ssomebody explain, what technically the grub installer did do? At one 
point it said "I have dicovered another EFI partition, shall I use it?" (or 
similar, it is from my remembers).

Thanky for making things clear.

Best 

Hans

 

Review of Refind boot manager (was Re: USB UEFI recovery stick)

[Joel Roth]

On Sun, Jan 23, 2022 at 09:47:10PM -0500, Polyna-Maude Racicot-Summerside wrote:

> rEFInd is a fork of the rEFIt boot manager. Like rEFIt, rEFInd can
> auto-detect your installed EFI boot loaders and it presents a pretty GUI
> menu of boot options. rEFInd goes beyond rEFIt in that rEFInd better
> handles systems with many boot loaders, gives better control over the
> boot loader search process, and provides the ability for users to define
> their own boot loader entries.
> 
> https://www.rodsbooks.com/refind/installing.html

I just migrated my system to new hardware with a GPT
formatted disk. (Well, almost migrated; I still have to
figure out the driver for the wifi chip.)

There was no reason not to reformat the disk as MBR (it is
only 500GB) but anyway decided to try to use the GPT/EFI
format. 

I repartitioned, leaving only the EFI system partition.
For the bootloader I've been avoiding Grub due to its
complicated config files. (Maybe I'm just contrarian ;-)

lilo seemed to barf. I didn't get beyond the warnings that
there was some partition table error and that I was attempting
something dangerous. 

My next try was Refind, a friendly OS-agnostic bootloader
that handles EFI. (I'd used it once previously when
installing devuan on a Intel Mac.)

The main limitation compared to Grub is that Refind doesn't
let you edit the command line prior to booting. 

Despite lots of detail on the website, the actual
configuration is simple, even compared to lilo.conf.  There
are just three lines in /boot/refind_linux.conf containing
options for normal, single-user mode and minimal boot. The
boot partition(s) are identified by UUID. Refind generates
menu choices for all kernels found.  

Refind comes with several utility scripts. I used
refind-install to generate refind_linux.conf, but needed to
tweak the result for it to correctly find the initrd images
matching the kernel versions.  

So in conclusion, Refind is easy to install and configure,
and suits my purposes just fine. 

> -- 
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource development

-- 
Joel Roth

Re: Converting a BIOS (CSM) Debian installation into UEFI

[David Wright]

On Tue 15 Feb 2022 at 14:20:55 (-0500), Felix Miata wrote:
> David Wright composed on 2022-02-15 10:11 (UTC-0600):
> 
> > Is anything else required for B to become a "native EFI" installation?
> 
> > This conversion process will, I think, make the system boot into
> > the EFI-ed B by default. If I want to make E boot by default again,
> > should I boot E and run update-grub and grub-install?³
> > Or should I do this by running efibootmgr?
> 
> Without changing GRUB_DISTRIBUTOR= in /etc/default/grub, you'll wind up with 
> only
> /boot/efi/EFI/debian. It will be just like MBR booting, where the last updated
> Grub overwrites what the previous one put in the MBR. I avoid this by 
> changing the
> default
> 
>   GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> 
> to e.g.
> 
>   GRUB_DISTRIBUTOR="bookworm"

That was useful — I hadn't realised the connection between that
variable and the directory name in EFI/. It's quite tricky pulling all
the threads together: the directory layout in EFI/, all the stuff
that's in /sys/firmware/efi/efivars, the efibootmgr's listing, and
the contents (and actions) of the EFI menus when you boot into the
firmware interface (reached with Esc F9 here, IIRC).

> Once you have a unique /boot/efi/EFI/ entry for each installation, you 
> /should/ be
> able to switch which has control either in the BIOS directly, or with 
> efibootmgr.
> Likely update-grub and grub-install would do the same thing, but I've never 
> given
> them the opportunity here. I say /should/ because some UEFI BIOS are finicky
> beasts that can't always be trusted to do as expected.
> 
> I avoid the issue of priority usurpation in two ways:
> 1-only mount the ESP filesystem to /boot/efi/ on one installation
> 2-don't install any bootloader

I think I've decided to keep mine simple by:
. booting into one primary system from the ESP,
. only that primary system has /boot/efi/EFI/ mounted (your 1),
. no Grub on the non-primary systems (your 2),
. the primary's Grub will choose which system to boot.

I'm used to using grubenv for one-time boot selection, even when
I'm not at the machine, but am happy to use the EFI menus whenever
I need to boot from a stick, etc.

> I actually boot from /boot/grub/custom.cfg, by copying /etc/grub.d/40_custom 
> to
> 06_custom. This causes grub-mkconfig to generate a grub.cfg that displays my
> custom.cfg entries before its auto-generated entries, minimizing need to 
> scroll
> the menu to find a desired selection. My custom.cfg boots via kernel and 
> initrd
> symlinks (and volume LABEL rather than UUID, same as fstab), so infrequently 
> has
> any need to be updated. Note that my use of singular filenames is inaccurate, 
> as I
> have 5 UEFI systems configured this way, and all have 10 or more Linux 
> installations.

I'll probably go through another iteration of my edgrub
script, to reduce even more of the "garbage" in grub.cfg.
Thanks for the suggestions.

Cheers,
David.

Re: Converting a BIOS (CSM) Debian installation into UEFI

[Felix Miata]

David Wright composed on 2022-02-15 10:11 (UTC-0600):

> Is anything else required for B to become a "native EFI" installation?

> This conversion process will, I think, make the system boot into
> the EFI-ed B by default. If I want to make E boot by default again,
> should I boot E and run update-grub and grub-install?³
> Or should I do this by running efibootmgr?

Without changing GRUB_DISTRIBUTOR= in /etc/default/grub, you'll wind up with 
only
/boot/efi/EFI/debian. It will be just like MBR booting, where the last updated
Grub overwrites what the previous one put in the MBR. I avoid this by changing 
the
default

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

to e.g.

GRUB_DISTRIBUTOR="bookworm"

Once you have a unique /boot/efi/EFI/ entry for each installation, you /should/ 
be
able to switch which has control either in the BIOS directly, or with 
efibootmgr.
Likely update-grub and grub-install would do the same thing, but I've never 
given
them the opportunity here. I say /should/ because some UEFI BIOS are finicky
beasts that can't always be trusted to do as expected.

I avoid the issue of priority usurpation in two ways:
1-only mount the ESP filesystem to /boot/efi/ on one installation
2-don't install any bootloader

I actually boot from /boot/grub/custom.cfg, by copying /etc/grub.d/40_custom to
06_custom. This causes grub-mkconfig to generate a grub.cfg that displays my
custom.cfg entries before its auto-generated entries, minimizing need to scroll
the menu to find a desired selection. My custom.cfg boots via kernel and initrd
symlinks (and volume LABEL rather than UUID, same as fstab), so infrequently has
any need to be updated. Note that my use of singular filenames is inaccurate, 
as I
have 5 UEFI systems configured this way, and all have 10 or more Linux 
installations.
-- 
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

Converting a BIOS (CSM) Debian installation into UEFI

[David Wright]

With the threads on "Stupid question" and "Throw an hard drive"
in d-u at the moment, this seems timely:

I have a drive which contains two Debian installations, one of which
(B) was installed for BIOS booting, and the other (E) was installed
with EFI booting. I would like to convert B into a EFI system too. ¹

Each system has its own Grub installation, and os-prober has inserted
entries for both systems into both systems. Consequently this means
that I can boot in EFI-mode and run B, and I can boot in BIOS-mode
and run E.

As far as I can tell, the process for B to EFI should just involve:
. boot B in EFI mode
. mkdir /boot/efi/
. add it to /etc/fstab
. mount the ESP onto it
. remove grub-pc, grub-pc-bin
. install (with Recommends) grub-efi-amd64, grub-efi-amd64-bin, 
grub-efi-amd64-signed,
  shim-signed, shim-signed-common, shim-helpers-amd64-signed, shim-unsigned
. run update-grub
. run grub-install (which should now modify /boot/efi, not the MBR).

Is anything else required for B to become a "native EFI" installation?

This conversion process will, I think, make the system boot into
the EFI-ed B by default. If I want to make E boot by default again,
should I boot E and run update-grub and grub-install?³
Or should I do this by running efibootmgr?

--

¹
More details: B was installed for dual-booting with EFI Windows,
by switching into the BIOS (CMS) for booting B. Since then,
Windows and almost all its entrails (various recovery, data and
reserved partitions) ² have been overwritten with Debian
installation E.

The disk has all the necessary components: GPT partitioning, with
a protective MBR and BIOS boot partition for B's use, and the
original ESP for E's (and B's future) use, plus shared /home
(encrypted), and a random encrypted swap.

²
The ESP still has a "fossil" EFI/Microsoft/Boot/bootmgfw.efi file
which merely causes grub-efi (through os-prober) to write a
useless (but benign) entry in grub.cfg.

³
With totally BIOS systems, if I wanted a system "A" to be the
default system when booted, I could boot A and run update-grub
and grub-install. This would preen A's grub.cfg, and make the
protective MBR boot to it.

Cheers,
David.

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Flacusbigotis]

Thank you! I was using the 32-bit image! Duh!!!  I retried with the 64-bit
image and it is all good!


On Fri, Feb 11, 2022 at 11:16 AM Andrew M.A. Cater 
wrote:

> On Thu, Feb 10, 2022 at 07:43:56PM -0600, Flacusbigotis wrote:
> > Thomas and Andrew, thanks for your reply.
> >
> >
> > The laptop is no more than two years old and it has an Intel Core
> i3-1005G1
> > processor.
> > Also, I checked the USB stick and it only has the 32-bit EFI program in
> the
> > EFI boot folder.
> >
> > I assume based on what Andrew said that maybe the UEFI needs to be
> 64-bit.
> > I guess I will take the thread to the debian-live mailing list and ask
> why
> > there is no 64-bit UEFI program and their plans to add one.
> >
> > On Tue, Feb 8, 2022 at 5:18 AM Thomas Schmitt  wrote:
> >
> > > Hi,
> > >
> > > Andrew M.A. Cater wrote:
> > > > I had a similar issue the other day with an old Intel Baytrail
> > > > notebook where the UEFI is 32 bit and the processor is 64 bit -
> using a
> > > > Debian multi-arch installer worked. I used the one with firmware.
> > >
> > > This would match the observation that Knoppix 9.1 works.
> > > I have Knoppix 9.0 and  9.2 ISOs. On both the EFI partition has start
> > > programs for 64 bit and for 32 bit:
> > >   /mnt/fat/efi/boot/BOOTIA32.efi
> > >   /mnt/fat/efi/boot/BOOTX64.efi
> > >
> > >
> > > Have a nice day :)
> > >
> > > Thomas
> > >
> > >
>
> Check which Debian live image you downloaded - I think there are two
> versions
> -- one 32 bit, one 64 bit.
>
> To be honest, I'd be tempted to just use a standard Debian installer.
>
> If you have a machine which only has UEFI and refuses to boot a 64 bit
> Debian live at any point - at that point, you can look to say whether it's
> one of the outliers with a 32 bit BIOS and 64 bit CPU.
>
> There was a rash of netbooks a few years ago with 2GB RAM for just this
> reason
> they were sold with cut down 32 bit Windows versions.
>
> Hope this helps, all the very best, as ever,
>
> Andy C.
>
>

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Andrew M.A. Cater]

On Thu, Feb 10, 2022 at 07:43:56PM -0600, Flacusbigotis wrote:
> Thomas and Andrew, thanks for your reply.
> 
> 
> The laptop is no more than two years old and it has an Intel Core i3-1005G1
> processor.
> Also, I checked the USB stick and it only has the 32-bit EFI program in the
> EFI boot folder.
> 
> I assume based on what Andrew said that maybe the UEFI needs to be 64-bit.
> I guess I will take the thread to the debian-live mailing list and ask why
> there is no 64-bit UEFI program and their plans to add one.
> 
> On Tue, Feb 8, 2022 at 5:18 AM Thomas Schmitt  wrote:
> 
> > Hi,
> >
> > Andrew M.A. Cater wrote:
> > > I had a similar issue the other day with an old Intel Baytrail
> > > notebook where the UEFI is 32 bit and the processor is 64 bit - using a
> > > Debian multi-arch installer worked. I used the one with firmware.
> >
> > This would match the observation that Knoppix 9.1 works.
> > I have Knoppix 9.0 and  9.2 ISOs. On both the EFI partition has start
> > programs for 64 bit and for 32 bit:
> >   /mnt/fat/efi/boot/BOOTIA32.efi
> >   /mnt/fat/efi/boot/BOOTX64.efi
> >
> >
> > Have a nice day :)
> >
> > Thomas
> >
> >

Check which Debian live image you downloaded - I think there are two versions
-- one 32 bit, one 64 bit.

To be honest, I'd be tempted to just use a standard Debian installer. 

If you have a machine which only has UEFI and refuses to boot a 64 bit
Debian live at any point - at that point, you can look to say whether it's 
one of the outliers with a 32 bit BIOS and 64 bit CPU.

There was a rash of netbooks a few years ago with 2GB RAM for just this reason 
they were sold with cut down 32 bit Windows versions.

Hope this helps, all the very best, as ever,

Andy C.

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Thomas Schmitt]

Hi,

Flacusbigotis wrote:
> The laptop is no more than two years old and it has an Intel Core i3-1005G1
> processor.
> Also, I checked the USB stick and it only has the 32-bit EFI program in the
> EFI boot folder.

In this case you probably got an "i386" ISO image for 32-bit systems.

Try one of the "amd64" ISOs at
  https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

Their EFI partition is supposed to contain
  /efi/boot/bootx64.efi
(I have debian-live-11.1.0-amd64-xfce.iso here and expect no change in
the newer 11.2.0 ISO.)


Have a nice day :)

Thomas

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Flacusbigotis]

Thomas and Andrew, thanks for your reply.


The laptop is no more than two years old and it has an Intel Core i3-1005G1
processor.
Also, I checked the USB stick and it only has the 32-bit EFI program in the
EFI boot folder.

I assume based on what Andrew said that maybe the UEFI needs to be 64-bit.
I guess I will take the thread to the debian-live mailing list and ask why
there is no 64-bit UEFI program and their plans to add one.

On Tue, Feb 8, 2022 at 5:18 AM Thomas Schmitt  wrote:

> Hi,
>
> Andrew M.A. Cater wrote:
> > I had a similar issue the other day with an old Intel Baytrail
> > notebook where the UEFI is 32 bit and the processor is 64 bit - using a
> > Debian multi-arch installer worked. I used the one with firmware.
>
> This would match the observation that Knoppix 9.1 works.
> I have Knoppix 9.0 and  9.2 ISOs. On both the EFI partition has start
> programs for 64 bit and for 32 bit:
>   /mnt/fat/efi/boot/BOOTIA32.efi
>   /mnt/fat/efi/boot/BOOTX64.efi
>
>
> Have a nice day :)
>
> Thomas
>
>

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Thomas Schmitt]

Hi,

Andrew M.A. Cater wrote:
> I had a similar issue the other day with an old Intel Baytrail
> notebook where the UEFI is 32 bit and the processor is 64 bit - using a
> Debian multi-arch installer worked. I used the one with firmware.

This would match the observation that Knoppix 9.1 works.
I have Knoppix 9.0 and  9.2 ISOs. On both the EFI partition has start
programs for 64 bit and for 32 bit:
  /mnt/fat/efi/boot/BOOTIA32.efi
  /mnt/fat/efi/boot/BOOTX64.efi


Have a nice day :)

Thomas

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Andrew M.A. Cater]

On Mon, Feb 07, 2022 at 08:47:16PM -0600, Flacusbigotis wrote:
> I have followed Debian's instructions (
> https://wiki.debian.org/DebianInstall#Creating_a_Bootable_Debian_USB_Flashdrive)
> for creating a bootable USB stick but it fails to boot on my UEFI laptop.
> In contrast, I am able to create the same for Knoppix 9.1 following their
> instructions. So not sure why the debian one doesn't work.
> 
> The debian instructions basically say to do a normal cp of the hybrid iso
> unto the raw USB device as follows (assume USB stick is on /dev/sdf):
> 
> cp  debian11_hybrid.iso  /dev/sdf
> 
> However, although the USB stick ends up with the 2 corresponding
> partitions, and I can mount/see the content of those, my laptop refuses to
> recognize the USB stick during boot and so it won't boot off it.
> 
> I have tried the Debian 10 and Debian 11 hybrid images on 2 different USB
> sticks and I get the same result.
> 
> According to [this](https://wiki.debian.org/UEFI#UEFI_support_in_live_images)
> page the debian live images should boot on UEFI-based systems when USB
> sticks are prepared as described above...
> 
> I have inspected the boot options of the laptop in is setup screen, with
> the USB stick plugged-in, but the USB stick is not listed as a possible
> target.
> 
> BTW, in that laptop setup screen I see a note that says that Legacy Boot
> mode is not supported on the laptop.

What model of laptop? What's the processor?

I ask because I had a similar issue the other day with an old Intel Baytrail
notebook where the UEFI is 32 bit and the processor is 64 bit - using a
Debian multi-arch installer worked. I used the one with firmware.

Happy to help on a reply

All the very best, as ever,

Andy Cater

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Thomas Schmitt]

Hi,

this problem is probably better served on debian-l...@lists.debian.org
(or on debian...@lists.debian.org if you tried also a Debian installation
ISO).

Whatever:

Flacusbigotis wrote:
> The debian instructions basically say to do a normal cp of the hybrid iso
> unto the raw USB device as follows (assume USB stick is on /dev/sdf):
> cp  debian11_hybrid.iso  /dev/sdf

This is the currently advised method, indeed.


> In contrast, I am able to create the same for
> Knoppix 9.1 following their instructions.

Did you do the same as with the Debian ISO or did you use "flash-knoppix"
to install the ISO onto the stick ?


> BTW, in that laptop setup screen I see a note that says that Legacy Boot
> mode is not supported on the laptop.

Does this note appear unconditionally or does it show up only if the Debian
USB stick is present ?


--

Far fetched idea:

What happens if you replace the partition table on the USB stick by a
GPT which marks only the small EFI partition ?

I.e. print the partition table of the USB stick, delete it, create a
new partition table as GPT and add a partition of the type for EFI
with start and size as printed from the original table.
(The way to express the EFI partition type differs from partition editor
to partition editor. See for example
  https://wiki.archlinux.org/title/EFI_system_partition#GPT_partitioned_disks
)

The big partition of Debian ISOs encloses the small one, which is not
allowed in GPT. But the big one exists only to protect the ISO 9660
filesystem from partition editors. It is not needed for booting.


Have a nice day :)

Thomas

Unable to boot UEFI laptop from Debian 11 Live USB stick

[Flacusbigotis]

I have followed Debian's instructions (
https://wiki.debian.org/DebianInstall#Creating_a_Bootable_Debian_USB_Flashdrive)
for creating a bootable USB stick but it fails to boot on my UEFI laptop.
In contrast, I am able to create the same for Knoppix 9.1 following their
instructions. So not sure why the debian one doesn't work.

The debian instructions basically say to do a normal cp of the hybrid iso
unto the raw USB device as follows (assume USB stick is on /dev/sdf):

cp  debian11_hybrid.iso  /dev/sdf

However, although the USB stick ends up with the 2 corresponding
partitions, and I can mount/see the content of those, my laptop refuses to
recognize the USB stick during boot and so it won't boot off it.

I have tried the Debian 10 and Debian 11 hybrid images on 2 different USB
sticks and I get the same result.

According to [this](https://wiki.debian.org/UEFI#UEFI_support_in_live_images)
page the debian live images should boot on UEFI-based systems when USB
sticks are prepared as described above...

I have inspected the boot options of the laptop in is setup screen, with
the USB stick plugged-in, but the USB stick is not listed as a possible
target.

BTW, in that laptop setup screen I see a note that says that Legacy Boot
mode is not supported on the laptop.

Re: USB UEFI recovery stick

[Andrei POPESCU]

On Lu, 24 ian 22, 03:39:47, deloptes wrote:
> 
> Hi all,
> is there a way to have a USB UEFI stick that works similar to the Debian
> installer - for example to boot into UEFI and recover the boot loader.
> One machine here seems a bit older and refuses to boot into UEFI from the
> USB - rendering USB obsolete as recovery option. In BIOS USB says AUTO
> (other option is Legacy) however if I disable Legacy keyboard does not
> work.

The USB AUTO / Legacy options would suggest to me[1] they are about the 
USB itself, i.e. support for older USB standards (1.1 and/or 2.0), which 
might explain why your keyboard stops working.

As David mentioned, some USB ports might not support booting at all, you 
should try all available USB ports.

[1] Hard to tell without looking at the menus, but the system's / 
motherboard's user manual should explain what each option actually does. 
Admittedly the explanation is often incomplete and/or badly worded.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: USB UEFI recovery stick

[David Wright]

On Mon 24 Jan 2022 at 17:26:13 (-0800), David Christensen wrote:
> On 1/24/22 2:55 AM, deloptes wrote:
> > I can boot from the CD/DVD into UEFI, but it seems I can not do the same
> > from the USB.
> > The USB which is UEFI can boot the newer notebook (has secure mode)
> 
> > The question is if it is not limited by the board. If I disable Legacy USB I
> > can not use the keyboard/mouse and I have to reset the bios.
> > 
> > But even in Legacy mode I see in boot options UEFI USB disk, however it does
> > not boot, but same stick boots on the more recent notebook.
> > 
> > Does someone knows more about it. What and where to check? I would not spend
> > time if it is the boards BIOS. I'll just keep a copy of the DVD/CD as
> > rescue
> 
> I have found that testing is the only way to determine if a given FOSS
> image/ device/ media boots, installs, or works in a given computer;
> and to what degree.

Not just the image and device, but which port it's plugged into can
also make a difference whether it will boot. Very frustrating.

Cheers,
David.

Re: USB UEFI recovery stick

[David Christensen]

On 1/24/22 2:55 AM, deloptes wrote:

Thank you for the response


YW.  :-)



Ah 2011 seems right to match the one that refer to here.
I can boot from the CD/DVD into UEFI, but it seems I can not do the same
from the USB.
The USB which is UEFI can boot the newer notebook (has secure mode)



The question is if it is not limited by the board. If I disable Legacy USB I
can not use the keyboard/mouse and I have to reset the bios.

But even in Legacy mode I see in boot options UEFI USB disk, however it does
not boot, but same stick boots on the more recent notebook.

Does someone knows more about it. What and where to check? I would not spend
time if it is the boards BIOS. I'll just keep a copy of the DVD/CD as
rescue

thanks



I have found that testing is the only way to determine if a given FOSS 
image/ device/ media boots, installs, or works in a given computer; and 
to what degree.



David

Re: USB UEFI recovery stick

[deloptes]

Andrew M.A. Cater wrote:

> Hi deloptes,
> 
> It depends very much on the machine. I've just saved a machine that has
> 32 bit UEFI implementation and a 64 bit Atom processor. It's an Intel
> Baytrail with a small amount of memory [2G] but required the Debian
> multi-arch .iso to boot.
> 
> A later model of the same series - Lenovo Ideapad - does support 64 bit
> UEFI and UEFI processor. Which machine do you have and what's the
> processor?
> 
> All the very best
> 
> Andy Cater
> 
> Which machine, which processor.

Thank you
I did not know that it could be different BIOS arch version - but of course
why not.
The PC is Fujitsu Esprimo C700
http://support.harlander.com/upload-artikelsupport/computer/fujitsu-siemens/esprimo-c700/c700-datenblatt.pdf

CPU is
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz

information is too little

thank you in advance

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

Re: USB UEFI recovery stick

[Andrew M.A. Cater]

On Mon, Jan 24, 2022 at 11:55:20AM +0100, deloptes wrote:
> Thank you for the response
> 
> David Christensen wrote:
> 
> > I have a computer with an Intel DQ67SW desktop motherboard (released Q1,
> > 2011).  The Setup utility allows me to select BIOS/MBR mode or UEFI/GPT
> > mode.  d-i seems to detect if the computer is running in BIOS/MBR mode
> > or in UEFI/GPT mode, and performs an install to match.  So, I installed
> > Debian twice (via textual "Install") onto a pair of USB sticks, once in
> > each mode.  (An "Expert" installation may offer more options.)
> 
> Ah 2011 seems right to match the one that refer to here.
> I can boot from the CD/DVD into UEFI, but it seems I can not do the same
> from the USB.
> The USB which is UEFI can boot the newer notebook (has secure mode)
> 
> > 
> > I mostly run my computers in BIOS/MBR mode, and use the BIOS/MBR USB
> > stick frequently.
> > 
> > 
> > I have limited experience with the UEFI/GPT USB stick.  I need to test
> > it on a newer computer with Secure Boot, and may need to create a third
> > USB stick.
> > 
> > 
> > AIUI d-i and Debian Live are open-source projects.  I believe they both
> > support all of the above in a single image.  If you have the skills,
> > perhaps you could fork one and create your own image with the tools you
> > want.
> 
> The question is if it is not limited by the board. If I disable Legacy USB I
> can not use the keyboard/mouse and I have to reset the bios.
> 
> But even in Legacy mode I see in boot options UEFI USB disk, however it does
> not boot, but same stick boots on the more recent notebook.
> 
> Does someone knows more about it. What and where to check? I would not spend
> time if it is the boards BIOS. I'll just keep a copy of the DVD/CD as
> rescue
> 
> thanks
> 
> -- 
> FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
>

Hi deloptes,

It depends very much on the machine. I've just saved a machine that has
32 bit UEFI implementation and a 64 bit Atom processor. It's an Intel Baytrail
with a small amount of memory [2G] but required the Debian multi-arch .iso
to boot.

A later model of the same series - Lenovo Ideapad - does support 64 bit UEFI
and UEFI processor. Which machine do you have and what's the processor?

All the very best 

Andy Cater

Which machine, which processor.