3 ms·

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 b

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.

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.