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. > > > 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). You're right, and that's yet another reason it's not a good idea to use childish names as "systemd-bloat". I agree that grub2 is more bloated and that it doesn't make sense to bring all the complexities of BIOS boot to UEFI. However, the real question is, why does it matter? It's only a boot loader. It does its job in a fraction of a second and then it's all done, and the kernel takes it up from there. None of the "bloated" bootloader code stays in memory. And wasting 2.5 MB instead of 94 KB of disk space would only matter if we lived in the times when hard drives were 10 MB or 20 MB :) It's true that the extra complexity means it's more prone to bugs, but it has already been debugged fairly well and does its job just fine, so what's the problem? My real problem with grub2 is not that it's complex, but the fact that it exposes its complexities to the user. I wish it had an "easy" mode, where you could configure it easily for the common things that 99% of the users would do, such as: 1. setting the boot menu timeout 2. choosing the default boot option - e.g. always Fedora, or always Windows, or always a single entry, or, alternatively, as an option, remember the last chosen option, and just repeat it, if the timeout expires - this is invaluable when you dual boot Windows and have to install Windows updates, because they are notorious for rebooting the system several times, and you can't always sit in front the computer for hours, so that you can catch the 5 seconds when the boot menu appears, so you can choose Windows again. :) 3. changing the kernel boot options 4. adding passwords to certain menu entries These are common things, that I'm reluctant to do, because I'm put off by the complexities of grub2 configuration. I wish it had an easy mode that just covers these common scenarios. I don't want to remove features from it, I think it's great to have extra features for those that want them, but I see no reason why simple things have to be complicated also. IMHO, all this talk about bloat is just distracting us from the real issues, which is bootloader configuration difficulties. I'm willing to try systemd-boot on a virtual machine, to see if it makes things easier, but the fact it doesn't support BIOS makes it not very usable for me. There are systems, where I can't use it, and there are systems where I can use it, but I don't want to repartition and reinstall both Windows 10 and Fedora, because they are dual boot systems. And no, I wouldn't trust Microsoft's MBR to GPT upgrade tool on a dual boot system. :) Best regards, Nikolay _______________________________________________ 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
