You are not logged in.

  1. Index
  2. » Help & Support (Other)
  3. » From BIOS to UEFI(am I too old?)

Pages: 1

#1 2025-02-11 15:21:57

unklar
Back to the roots 1.9
From: #! BL
Registered: 2015-10-31
Posts: 2,640

From BIOS to UEFI(am I too old?)

@HoaS  smile

I had the honor of using your 40_custom for booting my BIOS multiboot systems for many, many years.
It was super easy, e.g.

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'nox-dk (auf /dev/sdb7)' {
	set root='hd1,msdos7'
	configfile /boot/grub/grub.cfg
}
menuentry 'riogrande (auf /dev/sdb9)' {
	set root='hd1,msdos9'
	configfile /boot/grub/grub.cfg
}
menuentry 'nox-labwc (auf /dev/sdc5)' {
	set root='hd2,msdos5'
	configfile /boot/grub/grub.cfg
}
...

The main system was always BunsenLabs with Grub in the MBR. The other grubs were installed in the PBR.

Now I had to buy a new desktop computer with UEFI sad
It was already set up with Debian12 - Cinamon. Since the /home was almost 400GB in size, I reduced this partition to 100GB. I installed / and /home from Boron/Carbon in the free space.
The questions in the 'Expert-Installer' of Debian during the installation of Grub, to force in /boot/efi and an entry in the NVRAM, I have denied.

The subsequent (warm) start worked exactly once.  tongue
I had to use the 'chroot helper' from siduction to make the debian12-cinamon usable again with 'grub-install'.

The 40_custom now has this look and only the last, 3rd entry works.

exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'carbon (auf /dev/nvme0n1p5)' {
	insmod ext2
	search --fs-uuid --no-floppy --set=root 89fe80f1-6d71-452d-97de-1dbdc9b9c6ed
	configfile /boot/grub/grub.cfg
}
menuentry 'carbon' {
	insmod part_gpt
	insmod ext2
	search --fs-uuid --no-floppy --set=root 89fe80f1-6d71-452d-97de-1dbdc9b9c6ed
	configfile /boot/grub/grub.cfg
}
menuentry 'carbon' {
	insmod part_gpt
	insmod ext2
	search --fs-uuid --no-floppy --set=root 89fe80f1-6d71-452d-97de-1dbdc9b9c6ed
	linux /vmlinuz root=UUID=89fe80f1-6d71-452d-97de-1dbdc9b9c6ed
	initrd /initrd.img
}

(of course I still have an entry created by os-prober in the grub.cfg  wink  )

Is it now the case with the EFI that the grub of another OS first wipes out the main system grub and
and then I have to restore the previous, desired state with chroot?
Or do I simply omit the grub installation ('continue without boot loader')?
How do I keep the multi-boot system with EFI as small and effective as it was with BIOS?

Maybe you still need my current disk status with parted -l:

Model: ATA Samsung SSD 870 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type      File system  Flags
 1      1049kB  500GB  500GB  extended               lba
 5      2097kB  108GB  108GB  logical   fat32


Model: MTFDKBA512QFM-1BD1AABGB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name                  Flags
 1      1049kB  105MB   104MB   fat16           EFI boot partition    boot, esp
 2      106MB   75,6GB  75,5GB  ext4            Linux root partition
 3      75,6GB  77,8GB  2147MB  linux-swap(v1)  Linux SWAP partition  swap
 4      77,8GB  186GB   108GB   ext4            Linux home partition
 5      186GB   291GB   105GB   ext4
 6      291GB   396GB   105GB   ext4

Take your time  wink
Thank you very much!

Offline

#2 2025-02-11 16:55:08

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 9,063
Website

Re: From BIOS to UEFI(am I too old?)

unklar wrote:

The main system was always BunsenLabs with Grub in the MBR. The other grubs were installed in the PBR.

There was no need to install any other GRUB loaders to any of the PBRs, all that is needed is the /boot/grub/grub.cfg, no chainloading is involved.

Installing GRUB to a PBR is not recommended, even a simple fsck can delete the loader and result in an unbootable system.

unklar wrote:

The 40_custom now has this look and only the last, 3rd entry works.

You've used the same filesystem UUID for each menuentry so they're all trying to boot from the same partition. That being the case the first two menuentries will just loop back to the main GRUB menu.

So if you change the UUIDs to match the desired partitions it should still work, use this command (as root) to view the UUIDs:

lsblk -o name,mountpoint,uuid
unklar wrote:

Is it now the case with the EFI that the grub of another OS first wipes out the main system grub and
and then I have to restore the previous, desired state with chroot?

For UEFI systems the motherboard has it's own boot menu and installing another OS will add a new bootentry and place it first in the boot order.

The boot order can be reset with efibootmgr(8), which does not need a chroot to work, just a rw mounted /sys/firmware/efi/efivars/ directory.

unklar wrote:

Or do I simply omit the grub installation ('continue without boot loader')?

That will only be possible with Debian's "expert" installer, it will just plow ahead automatically otherwise. Not sure how other distributions deal with this though. I distrust automated installers and almost never use them.

unklar wrote:

How do I keep the multi-boot system with EFI as small and effective as it was with BIOS?

With UEFI it is possible to have each OS install it's own bootloader and then use the UEFI boot menu to select between them. Then you wouldn't have to bother with 40_custom at all.

Last edited by Head_on_a_Stick (2025-02-11 16:55:45)

Para todos todo, para nosotros nada

Offline

#3 2025-02-12 09:52:54

unklar
Back to the roots 1.9
From: #! BL
Registered: 2015-10-31
Posts: 2,640

Re: From BIOS to UEFI(am I too old?)

Head_on_a_Stick wrote:

There was no need to install any other GRUB loaders to any of the PBRs, all that is needed is the /boot/grub/grub.cfg, no chainloading is involved.

Ha, I never paid attention to that.
I'll have to try that out when I get a chance (on my wife's old laptop). big_smile

You've used the same filesystem UUID for each menuentry so they're all trying to boot from the same partition. That being the case the first two menuentries will just loop back to the main GRUB menu.

So if you change the UUIDs to match the desired partitions it should still work, use this command (as root) to view the UUIDs:

lsblk -o name,mountpoint,uuid
NAME        MOUNTPOINT   UUID
sda                      
├─sda1                   
└─sda5      /media/DATEN 1EE9-004D
nvme0n1                  
├─nvme0n1p1 /boot/efi    FD33-ABF3
├─nvme0n1p2              07b006d5-eace-4db3-bcff-93a9994c7b1a
├─nvme0n1p3 [SWAP]       a9091f63-0f5e-494b-a429-e8b30d81eb98
├─nvme0n1p4              64deb4a6-f5fe-4cbf-81b5-58d1f014144c
├─nvme0n1p5 /            89fe80f1-6d71-452d-97de-1dbdc9b9c6ed
└─nvme0n1p6 /home        110a92f2-e928-4191-bb3c-d12e5fd96c09

1p1 to 1p4 is the original delivery status of the computer.

nvme0n1p5 is / and nvme0n1p6 is /home from carbon. therefore it is the same.

That will only be possible with Debian's "expert" installer, it will just plow ahead automatically otherwise. Not sure how other distributions deal with this though. I distrust automated installers and almost never use them.

I am also suspicious of this 'automatic system'.
In recent years I have mainly installed from a Siduction-noX, which only has a very spartan cli-installer.

Otherwise I also prefer the debian-expert installer, which in my experience has become better and better and really does what it is told.

With UEFI it is possible to have each OS install it's own bootloader and then use the UEFI boot menu to select between them. Then you wouldn't have to bother with 40_custom at all.

Didn't it used to be decisive how the ISO was booted?
So where do I 'turn off' here? With the question of the Installer,
whether an entry should be made in the NVRAM?
GRUB could then also be omitted (although I get on well with it)?
-------------------
PS: ...just a little startled

efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001
Boot0001* debian	HD(1,GPT,e89bca5a-072e-44be-b61a-a527c0df95db,0x800,0x31801)/File(\EFI\debian\shimx64.efi)

Last edited by unklar (2025-02-12 15:58:37)

Offline

#4 2025-02-12 18:45:57

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 9,063
Website

Re: From BIOS to UEFI(am I too old?)

UEFI allows you to drop the bootloader completely — the kernel can boot itself in a UEFI system:

https://wiki.debian.org/EFIStub

I'm using a unified kernel image signed with my own Secure Boot keys, which ensures the entire boot chain (including the initramfs) is verified and approved. I just drop it at /EFI/Boot/bootx64.efi on the EFI system partition so the system boots just like a USB stick without any specific boot entries at all, which is rather useful when the boot entries get wiped after BIOS updates.

~$ doas bootctl --no-p
System:
      Firmware: UEFI 2.80 (American Megatrends 5.24)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

Current Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✓ Boot loader sets ESP information
         Stub: systemd-stub 256.11
     Features: ✓ Stub sets ESP information
               ✓ Picks up credentials from boot partition
               ✓ Picks up system extension images from boot partition
               ✓ Picks up configuration extension images from boot partition
               ✓ Measures kernel+command line+sysexts
               ✓ Support for passing random seed to OS
               ✓ Pick up .cmdline from addons
               ✓ Pick up .cmdline from SMBIOS Type 11
               ✓ Pick up .dtb from addons
          ESP: /dev/disk/by-partuuid/69b0de98-a08c-470c-ae1f-64b49c754229
         File: └─/EFI/BOOT/BOOTX64.EFI

Random Seed:
 System Token: set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/69b0de98-a08c-470c-ae1f-64b49c754229)
         File: └─/EFI/BOOT/bootx64.efi (systemd-stub 256.11)
systemd-boot not installed in ESP.

Boot Loaders Listed in EFI Variables:
        Title: UEFI OS
           ID: 0x0002
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/69b0de98-a08c-470c-ae1f-64b49c754229
         File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loader Entries:
        $BOOT: /efi (/dev/disk/by-partuuid/69b0de98-a08c-470c-ae1f-64b49c754229)
        token: chimera

0 entries, no entry could be determined as default.
~$ ukify inspect /etc/kernel/uki.efi                                  
.sbat:
  size: 315 bytes
  sha256: b8d9597ef95954df7131c512dba0bbf9a7978ca8fdb5fcd5b95486f1edfb99da
  text:
    sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
    systemd-stub,1,The systemd Developers,systemd,256,https://systemd.io/
    systemd-stub.chimera,1,Chimera Linux,systemd-boot,256.11-r1,https://chimera-linux.org
    uki,1,UKI,uki,1,https://uapi-group.org/specifications/specs/unified_kernel_image/
    
.osrel:
  size: 194 bytes
  sha256: c1e39a7cd0afed82edcd9b492a7aa93b12453986203c4585dfe9723659ac7dc5
  text:
    NAME="Chimera"
    ID="chimera"
    PRETTY_NAME="Chimera Linux"
    HOME_URL="https://chimera-linux.org"
    DOCUMENTATION_URL="https://chimera-linux.org/docs"
    LOGO="chimera-logo"
    ANSI_COLOR="0;38;2;214;79;93"
.cmdline:
  size: 80 bytes
  sha256: 17030f2b0b9ba100648af43618a80f62e9a713150c302f82acbc54f82ce84eb2
  text:
    root=/dev/nvme0n1p3 ro quiet loglevel=3 udev.log_level=3 bgrt_disable=1 --quiet
.uname:
  size: 16 bytes
  sha256: 0fbbf9b827aeb53c51b9014dafcb76dbc76c3ec34c82b90df7514d27cbb42e3e
  text:
    6.13.2-0-generic
.splash:
  size: 802954 bytes
  sha256: 33b02ff48edae966ecdae3357324ae6cd2f51e1a976346b95c81a82fd5fe56df
.initrd:
  size: 38783185 bytes
  sha256: f5b60faaa3ac523b081f73387468d97cf7b29f07cd204c2c79e2c44410940ce0
.ucode:
  size: 147968 bytes
  sha256: 93fe14b24bd8173bec06ffec88760e1d2d4a981020f0948bc8f0f4c15e6e12bc
.linux:
  size: 12178432 bytes
  sha256: 165aafd2e2ba4d1e479cdd82dbe0380e6b8802f43a361a1bfd39a36c0041f59b
~$

EDIT: inline code tags rule! cool

Last edited by Head_on_a_Stick (2025-02-12 19:41:20)

Para todos todo, para nosotros nada

Offline

#5 2025-02-13 09:27:57

unklar
Back to the roots 1.9
From: #! BL
Registered: 2015-10-31
Posts: 2,640

Re: From BIOS to UEFI(am I too old?)

WOW, I take my hat off to these Debian people who are researching this and documenting possible solutions on the wiki.
My hat is off to you who can creatively implement this for your own needs.

This is clearly a pay grade too big for me (I read the whole article and tried to understand it).
Even if I won't have 9 OS on the disk(s) at the same time anymore, EFI is and remains way too complicated and unreliable for me. Ergo, I'm trying to make the best of it.

Thank you for your work and your patience with me! wink

Offline

Pages: 1

  1. Index
  2. » Help & Support (Other)
  3. » From BIOS to UEFI(am I too old?)

Board footer

Powered by FluxBB