Hi, > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > "w" pressed down it will automatically boot into windows, similar if > > you keep "l" pressed down it will automaticall boot into linux, "a" > > will boot into macos, all without showing any UI at all. This means > > the boot menu can be hidden entirely during boot with a zero timeout, > > but you can still boot into a specific boot entry. > > That's actually awful, in my opinion, Why? It's nice to have them and I can't see any downsides. > and objectively undiscoverable.. Indeed. Would be nice to show these hotkeys somewhere. Extend the help line which is shown when you press '?' for example. > If you'd like to see how it should be done, boot a VM with GRUB2 as > the bootloader. For a short period of time, you'll see a list of > options, with the default option highlighted. If you don't pick > something different, or don't need to enter a prompt to recover your > device, it'll automatically boot. Well, seems you have never actually used sd-boot ... There actually isn't much of a difference between grub2 and systemd-boot here. Both can be configured to show or not show a menu. The menu screen doesn't look fundamentally different either: List of boot entries for the kernels installed, entry to boot into firmware setup, default entry highlighted, a few seconds timeout with countdown. Both support editing boot entries. Yes, unlike grub2 sd-boot has no command prompt. I have not missed that so far. The vast majority of cases where I've actually needed the grub2 prompt have been grub2 install problems, like grub2 failing to find its config file for some reason. That is clearly not something I account in favor of grub2 ... > GRUB2 is nice in that it's powerful enough for those that need it, but > simple enough for those who don't want the complex features. Well, alot of the complex grub features are dragged forward from the BIOS world to the UEFI world and are somewhat awkward there. The BIOS provides block device access at sector level, so the boot loader has little choice but implementing drivers for all kinds of stuff. Or use fragile block lists like lilo did in the last century. With UEFI much more functionality is provided by the firmware and there is little reason for a bootloader to have tons of drivers. With the exception of filesystem drivers in case you want boot from something != vfat. But even that should ideally be implemented as uefi driver not as grub2 module. If you insist on comparing bloat it will be grub2 which is bloated, and it comes from being stuck in its own world and carrying its own implementation for everything instead of using firmware services. -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi -rwx------. 1 root root 2513224 Jun 19 18:24 grubx64.efi (binaries as shipped by fedora 32). take care, Gerd _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
