Hi, On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote: > 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. I have lots of machines that fail to show the exact time boot happens (external monitor still powering up or blanking out) and will disable/ignore keys if you press too early. You won't see this with laptops as they are integrated machines and manufacturers pay a lot more attention to having a smooth display experience, but with workstations or servers the boot time is not the best experience ... > > 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 ... Anecdata, but I definitely never (maybe once 15 years ago?) had grub install issue, but plenty of dracut reconfiguration/upgrade failures over the years and the ability to edit the command line has been a life sacver. It is kind of a must have feature to do development on kernels so you can quickly change something w/o breaking your written down configuration for good if you make a mistake. Definitely not a fan of having to try a rescue disk, when you are 1000 miles from a server that you can access only via a remote console. That said I do not love grub, but being able to change the boot line is really a basic required feature for a developer OS. > > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
