3 ms·

I don’t really see the point in using the ESP for anything serious. Many of the arguments are also super weak, like the one about /boot/efi/ being nested (in ho

I don’t really see the point in using the ESP for anything serious. Many of the arguments are also super weak, like the one about /boot/efi/ being nested (in how many cases is this actually important to anyone and anything?). The ESP size issue successfully prevents the real world adoption of this, since Linux kernels are 50-100 MB each, which means you could maybe fit one on your average ESP, and good luck convincing real users to reinstall Windows just to make some Linux guys happy. Instead, I would prefer a different approach. An approach that can be seen in Windows and macOS, that is: no user serviceable parts inside. It would work like this: * Keep two partitions. * ESP contains a simple program (let’s call it stub), whose only job is to call the real boot loader on /boot. * The stub is simple (minimum user interaction) and doesn’t need updating very often. It has drivers/support software for storage media and some reasonable file systems (VFAT, Ext4). It may also support some simple form of disk encryption if desired. * The real bootloader (as well as any kernels) live on the separate /boot partition. The bootloader can do all the fancy things it wants, it can display a fancy wallpaper, support mouse input, and so on. * The ESP is not auto-mounted, might not even be listed in /etc/fstab. * Whenever the stub is updated (which would happen rarely, since it’s meant to be simple and minimum), some post-install scripts would mount ESP in any location they please (be it /run/{uuid.uuid4()}), copy over the new stub, and immediately unmount it. Simpler, safer, will make it harder for rogue software or `rm -rf /*` to mess up the booting of the system, and will not require any changes to existing partition tables.

xearl 4y ago
Your "different approach" sounds almost exactly like the approach proposed in the fine article for the "ESP too small" case (a case which you assume as a given).
still_grokking 4y ago
The "stub" would be in this case a (striped down) Linux kernel and an initrd… (Because that's needed for proper storage support) Than this "init Linux" would boot the bootloader, which in turn would load another kernel and initrd? This looks way to complicated. How does secure boot work in this setup? It's much simpler to just "glue together" a kernel and initrd, put it on the EFI partition, and boot that UKI directly by the built in EFI boot-manager. The EFI partition needs in this setup also be only mounted when updating / adding a UKI. Otherwise it never needs to show up in the running system as it's only used by the EFI boot-manager. Preparing a UKI can be done on the root FS (in its local /boot dir).
- krzyk 4y ago
  Why is initrd needed for "real storage support"? I usually have my storage drivers compiled into kernel, not as modules (because why have them as modules if you need them always).
  - mrktf 4y ago
    Answering question for ' Why is initrd needed for "real storage support"?' because there always be somebody: * need to have sshd at initrd stage to enter encryption keys (remote boot) * need to have recovery tool on hands (going even further: imagine having working graphical browser when storage fails) * have same crazy storage setup - root on ceph/nfs volume with non trial configuration and etc... * in case of electricity fault at home - it only system which have exposed connection to internet My suggestion for booting would be following: 1) having UEFI bootloader which boot some minimal kernel (lets same sort LTS for stability’s sake ) on /boot partition 2) have ability to unlock and read from root filesystem (same as above, rootfs in nfs/ceph/encrypted ir whatever) 3) then scan kernels from /lib/modules/{version}/bzImage (i know there are modules here, but having one additional file would not hurt too much) 4a) kexec kernel with necessary parameters to start system [in this step we do not enter passwords, encryption keys twice!] 4b) or boot without kexec in recovery mode with some GUI (I want ability to have browser in recovery mode)
  - still_grokking 4y ago
    You can compile cryptsetup into the kernel? I didn't know that. Interesting. Have you a reference for that? Or are you trying to say that you're booting without a initrd (which is said to be in general broken for decades). Also the secure boot question remains. I still don't get why complicate things in such way. Imho nothing is simpler than copying a (signed) boot-image onto the (firmware manged) boot partition, and be done.
    - krzyk 4y ago
      Is cruptsetup standard nowadays, or something that one would call a "real storage support"? Yes I'm booting without initrd, because in my case I don't need it - no cryptsetup and I don't need optional drivers because my setup doesn't change the hardware. (e.g. general distro kernel has to have it because they add modules for every hardware there is to support each user). How is boot without initrd broken? I use it since my first kernel compilation and find it simpler than dealing with initrd.

xearl 4y ago

Your "different approach" sounds almost exactly like the approach proposed in the fine article for the "ESP too small" case (a case which you assume as a given).

still_grokking 4y ago

The "stub" would be in this case a (striped down) Linux kernel and an initrd… (Because that's needed for proper storage support) Than this "init Linux" would boot the bootloader, which in turn would load another kernel and initrd? This looks way to complicated. How does secure boot work in this setup? It's much simpler to just "glue together" a kernel and initrd, put it on the EFI partition, and boot that UKI directly by the built in EFI boot-manager. The EFI partition needs in this setup also be only mounted when updating / adding a UKI. Otherwise it never needs to show up in the running system as it's only used by the EFI boot-manager. Preparing a UKI can be done on the root FS (in its local /boot dir).

krzyk 4y ago
Why is initrd needed for "real storage support"? I usually have my storage drivers compiled into kernel, not as modules (because why have them as modules if you need them always).
- mrktf 4y ago
  Answering question for ' Why is initrd needed for "real storage support"?' because there always be somebody: * need to have sshd at initrd stage to enter encryption keys (remote boot) * need to have recovery tool on hands (going even further: imagine having working graphical browser when storage fails) * have same crazy storage setup - root on ceph/nfs volume with non trial configuration and etc... * in case of electricity fault at home - it only system which have exposed connection to internet My suggestion for booting would be following: 1) having UEFI bootloader which boot some minimal kernel (lets same sort LTS for stability’s sake ) on /boot partition 2) have ability to unlock and read from root filesystem (same as above, rootfs in nfs/ceph/encrypted ir whatever) 3) then scan kernels from /lib/modules/{version}/bzImage (i know there are modules here, but having one additional file would not hurt too much) 4a) kexec kernel with necessary parameters to start system [in this step we do not enter passwords, encryption keys twice!] 4b) or boot without kexec in recovery mode with some GUI (I want ability to have browser in recovery mode)
- still_grokking 4y ago
  You can compile cryptsetup into the kernel? I didn't know that. Interesting. Have you a reference for that? Or are you trying to say that you're booting without a initrd (which is said to be in general broken for decades). Also the secure boot question remains. I still don't get why complicate things in such way. Imho nothing is simpler than copying a (signed) boot-image onto the (firmware manged) boot partition, and be done.
  - krzyk 4y ago
    Is cruptsetup standard nowadays, or something that one would call a "real storage support"? Yes I'm booting without initrd, because in my case I don't need it - no cryptsetup and I don't need optional drivers because my setup doesn't change the hardware. (e.g. general distro kernel has to have it because they add modules for every hardware there is to support each user). How is boot without initrd broken? I use it since my first kernel compilation and find it simpler than dealing with initrd.