Jarkko SakkinenLOL, apparently this feature was merged already in 2015. Heard first time this year...
Farce Majeure@jarkko it's simpler by way of supporting fewer types of systems and fewer things you can boot off of. TBH it has the same types of limitations, but more of them. It's not really a good way forward. OTOH using systemd-stub and putting the whole "bootloader" in an initrd is quite promising, but again only for UEFI systems.
@vathpela So, I'm now generating 2GB UEFI bootable image from BuildRoot recipes based on GRUB2. Previously based on busybox. So this is the context to be more specific. I don't care how my distribution works as long as I don't have to touch it :-)
I have no idea what "systemd-stub" even is (first time I'm hearing the word), but I guess in my use using systemd-boot could decrease the turn-over time in compilation by decreasing dependencies. I compile full operating system image from scratch when I do kernel development, not just kernel image, so decreasing that is already a benefit.
I have no idea what "systemd-stub" even is (first time I'm hearing the word), but I guess in my use using systemd-boot could decrease the turn-over time in compilation by decreasing dependencies. I compile full operating system image from scratch when I do kernel development, not just kernel image, so decreasing that is already a benefit.
@vathpela Anyway, I think I switch to systemd-boot in my kernel testing environment based on "less dependencies" :-) I.e. measurable benefit for the use case.
@vathpela One pleasant surprise is that changing to systemd from busybox with stripped down configuration does not cause any significant increase to compilation time of the image. So I can stick to this configuration from now and improve it :-)
Also it is a huge benefit that I now generate a single img file that QEMU can host or I can burn it to USB stick and run tests on real hardware. So I guess I'm a happy systemd user then...
Also it is a huge benefit that I now generate a single img file that QEMU can host or I can burn it to USB stick and run tests on real hardware. So I guess I'm a happy systemd user then...
Emil Renner Berthing@jarkko systemd-boot is simpler. It's just an EFI application that reads the files specified by the BootLoaderSpec, shows you a menu and then loads the next EFI app you choose (usually a Linux kernel). It doesn't need to implement all filesystems you might use for your /boot etc.
@esmil I do have file systems in BuildRoot of which I do not want to get rid of :-) I.e. I have separate ESP and rootfs.
But dropping dependency from my build makes more sense.
BTW, grub-efi is just an EFI application so in that sense there is zero difference. It is more related to fatness of the stack.
And if you want just to boot a kernel without rootfs why you even would bother using systemd-boot? You can compile just as well EFI stub to the kernel image... So systemd-boot would be in such scenario useless cruft. Just rename bzImage as BOOTx64.efi and you're set. Linux *is* an EFI. application.
Anyway, I'll go with systemd-boot because I need to build less by doing that :-)
But dropping dependency from my build makes more sense.
BTW, grub-efi is just an EFI application so in that sense there is zero difference. It is more related to fatness of the stack.
And if you want just to boot a kernel without rootfs why you even would bother using systemd-boot? You can compile just as well EFI stub to the kernel image... So systemd-boot would be in such scenario useless cruft. Just rename bzImage as BOOTx64.efi and you're set. Linux *is* an EFI. application.
Anyway, I'll go with systemd-boot because I need to build less by doing that :-)
@jarkko Yes, so with systemd-boot you might have to make your ESP a bit larger, since you need to put your kernel (and possibly initrd) on the ESP partition so systemd-boot can load and execute it.
On regular mutable distros kernel-install takes care of copying your kernel, initrd and configuration files to the ESP when you install the kernel package.
On regular mutable distros kernel-install takes care of copying your kernel, initrd and configuration files to the ESP when you install the kernel package.
@esmil Yeah, in my case kernel-install is not useful because I build rootfs as part of the kernel build itself :-) But keeping the build as minimal as possible is good goal for sure.
@jarkko Yeah, I thought so, but just wanted to give you the full picture ;)
@esmil I could actually do this without grub and without systemd-boot but I want to emulate the full stack for robustness sake. I.e. could just rename bzImage as BOOTx64.efi and place it correct location...