3 ms·

This is excellent! Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously

This is excellent! Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition) The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. It's been somewhat frustrating for distributions to install GRUB, hijacking the previous prioritized boot PE, and have entries for other installed Linux distributions missing.

amarshall 4y ago
> through systemd, and ensure all boot images are autodiscoverable and automatically bootable. See systemd-boot and BootLoaderSpec, both mentioned in OP. https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ https://www.freedesktop.org/wiki/Software/systemd/systemd-bo... https://systemd.io/BOOT_LOADER_SPECIFICATION/ https://systemd.io/BOOT_LOADER_SPECIFICATION/
- hyperupcall 4y ago
  yes - not all Linux distros do this
csdvrx 4y ago
> Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition) Same. The boot partition is a relic of the past, and you can easily do without it when you remove other relics like grub2: simply make EFI payloads the Arch way: https://wiki.archlinux.org/title/Unified_kernel_image#Manually https://wiki.archlinux.org/title/Unified_kernel_image#Manual... > The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. As much as I like systemd, I think it's not necessary here: I have a EFISP that's about 16G: it also contains a few .ISO that can be loaded in case system maintenance or a full reinstall is needed. GrubFM and others like Ventoy let you boot directly on say Windows11-22H2.ISO, Ubuntu22-10.iso etc. When I buy a new drive or computer, I just copy this partition: it's much faster than playing with thumbdrives or PXE Boot.
iam-TJ 4y ago
One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails AND it can take quite some time and effort to recover even if you're technically familiar with the boot process since there are no standardised procedures for duplicating the ESP or its content. A second issue is that since FAT doesn't have permissions any user ID on the system can potentially mount, read, and possibly write to the ESP. A separate (possibly encrypted) /boot/ file-system can be hosted on a RAID device or even loaded over the network. With a 'regular' boot process (UEFI > ESP boot-loader core > LUKS unlock > /boot/ boot-loader 2nd stage > /boot/ kernel+initrd > root-fs) the only thing lost is the boot-loader core, which can quickly be switched for a USB boot, set options appropriately to find and use /boot/, and for the boot process to use alternate RAID device(s) and continue with a degraded boot. On UEFI most distros now do not use os-prober to populate GRUB's own menu with other bootable OSes (GRUB_DISABLE_OS_PROBER=yes) since it expects those OSes to have added themselves to the UEFI boot menu. As for replacing the default boot entry, this is caused by efibootmgr not GRUB. GRUB calls efibootmgr with "--create|-c" which adds a new BOOTNUM and puts it at the head of the list. GRUB could be taught a new option that then does several efibootmgr operations: parsing text output of "efibootmgr" to get current boot order, --delete-bootorder then --bootorder A,B,C,OS to ensure OS is added last. That is obviously fragile so best approach would be to teach efibootmgr a new option --create-append|-C that adds the new entry to the end of BootOrder and then simply teach GRUB a new variable GRUB_UEFI_BOOTORDER_FIRST=yes|no to use efibootmgr --create-append.
- sneak 4y ago
  As someone who has run /boot on raid1 for years, I think his idea in the article of keeping them synchronised in userspace at update time (ie rsync) is better. There is no reason to need realtime raid1 kernelspace sync when /boot changes only monthly.
  - effie 4y ago
    One good reason is that mdraid takes care of syncing automatically, no need to set up rsync on every update of /boot.

amarshall 4y ago

> through systemd, and ensure all boot images are autodiscoverable and automatically bootable. See systemd-boot and BootLoaderSpec, both mentioned in OP. https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ https://www.freedesktop.org/wiki/Software/systemd/systemd-bo... https://systemd.io/BOOT_LOADER_SPECIFICATION/ https://systemd.io/BOOT_LOADER_SPECIFICATION/

hyperupcall 4y ago
yes - not all Linux distros do this

csdvrx 4y ago

> Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition) Same. The boot partition is a relic of the past, and you can easily do without it when you remove other relics like grub2: simply make EFI payloads the Arch way: https://wiki.archlinux.org/title/Unified_kernel_image#Manually https://wiki.archlinux.org/title/Unified_kernel_image#Manual... > The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. As much as I like systemd, I think it's not necessary here: I have a EFISP that's about 16G: it also contains a few .ISO that can be loaded in case system maintenance or a full reinstall is needed. GrubFM and others like Ventoy let you boot directly on say Windows11-22H2.ISO, Ubuntu22-10.iso etc. When I buy a new drive or computer, I just copy this partition: it's much faster than playing with thumbdrives or PXE Boot.

iam-TJ 4y ago

One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails AND it can take quite some time and effort to recover even if you're technically familiar with the boot process since there are no standardised procedures for duplicating the ESP or its content. A second issue is that since FAT doesn't have permissions any user ID on the system can potentially mount, read, and possibly write to the ESP. A separate (possibly encrypted) /boot/ file-system can be hosted on a RAID device or even loaded over the network. With a 'regular' boot process (UEFI > ESP boot-loader core > LUKS unlock > /boot/ boot-loader 2nd stage > /boot/ kernel+initrd > root-fs) the only thing lost is the boot-loader core, which can quickly be switched for a USB boot, set options appropriately to find and use /boot/, and for the boot process to use alternate RAID device(s) and continue with a degraded boot. On UEFI most distros now do not use os-prober to populate GRUB's own menu with other bootable OSes (GRUB_DISABLE_OS_PROBER=yes) since it expects those OSes to have added themselves to the UEFI boot menu. As for replacing the default boot entry, this is caused by efibootmgr not GRUB. GRUB calls efibootmgr with "--create|-c" which adds a new BOOTNUM and puts it at the head of the list. GRUB could be taught a new option that then does several efibootmgr operations: parsing text output of "efibootmgr" to get current boot order, --delete-bootorder then --bootorder A,B,C,OS to ensure OS is added last. That is obviously fragile so best approach would be to teach efibootmgr a new option --create-append|-C that adds the new entry to the end of BootOrder and then simply teach GRUB a new variable GRUB_UEFI_BOOTORDER_FIRST=yes|no to use efibootmgr --create-append.

sneak 4y ago
As someone who has run /boot on raid1 for years, I think his idea in the article of keeping them synchronised in userspace at update time (ie rsync) is better. There is no reason to need realtime raid1 kernelspace sync when /boot changes only monthly.
- effie 4y ago
  One good reason is that mdraid takes care of syncing automatically, no need to set up rsync on every update of /boot.