For those that suggested to drop nvidia drivers because it would be rejected by the newer kernels, keep in mind that Linux is moving towards systemd-boot instead of Grub as boot loader
(I dont even have Grub installed in my system)
And dropping nVidia driver support would cut down many users who are using nVidia cards at moment (me included), and thus force us to another distro that still works with it…
I didn’t mean the Kernel but more the development community, because it is part of systemd and installed by default…
All(most) the points you mentioned are non-points from a bootloaders p.o.v. because those are the responsibility of your kernel+initrd.
no automation for multibooting Linux distros: False
The entries made by the other distro’s are all automatically used in it’s menu.
no support for booting iso files from disk: True
This could be seen as a lack of feature, but this is not used widely and even with Grub it needs manual configuration.
no support for full disk encryption: Non-Argument
This is not the responsibility of your bootloader, but more of your kernel+initrd combo.
no support for legacy boot: True
This bootloader is for x64 UEFI only, which most modern desktop machines are nowerdays.
no theming: True / False
This is not a big deal for just being able to boot, even the default UEFI boot menu is just text…
If you meant boot animation then it is False because that’s handled outside the bootloader.
no automation for booting into btrfs snapshots: False
This is not the responsibility of your bootloader, but more of your kernel+initrd combo.
You could make a special entry whos only purpose and functionality is to select which snapshot to use by the other boot entry with a nice menu etc.
In short again: Non-Argument
no rescue mode: False
This is just a matter of an extra kernel option, which can be provided by a separate menu entry. Grub does this also…
And finaly “Grub is the most common bootloader for a reason.” that reason is: It has been used in the past because there were no other alternatives yet…
If you were to follow that same argument then we would all be using the older system managers instead of SystemD nowerdays, which has proven to be more and more useful and advanced in respect to SysV/etc, hence why most distros now use it as their default init process…
Don’t be shy and just embrace SystemD you will learn to it once you learn what/how it can do things more effectively.
A good alternative seems to be rEFInd, but i have not used that yet.
ANYHOW, this is all OFFTOPIC so lets drop this sub-topic…
So you have to manage the bootloader entries from all the distros you install. I don’t see that as automation. Also, even with a single boot, distros like manjaro that have multiple and changing kernel filenames require manual fiddling. There is sdboot-manage written by @dalto that can manage this. But my point is that from distro packagers perspective systemd-boot is actually quite a lot of hassle. You have to implement many things at distro level that you would get from upstream with grub. Having written systemd-boot support for manjaro-architect, I have some experience with this.
But it’s awesome and grub does it.
Grub supports storing kernel and initrd on encrypted partition. Systemd-boot does not. Still I conceed that it is not a major win for grub, because grub sucks at it, and it’s not that worthwhile anyway.
I contest this. Systemd-boot does not have automation for this, grub does. Providing kernel parameters is definately bootloaders job, and booting into btrfs snapshots is done by custom kernel parameters. Either you know something that I don’t, or you have misunderstood the point I was making.
With grub, I can very easily at boot time choose a snapshot that I boot into, with snapshots having been automatically generated on every pacman action and every boot. You can do special entries for this with systemd-boot, but my point was that grub does this automatically.
It seems to me that we are talking about different things, which is probably caused by me using a misleading term.
I have. It is awesome, I recommend trying it.
I don’t this systemd-boot is a bad bootloader, but from distro maintenance perspective, it ends up being a lot of hassle despite (or because) of its inherent simplicity. We used to have isos with syslinux+systemd-boot for bootloader to support both legacy and uefi systems. But we switched to grub, so that we could use the same bootloader for both options. Systemd-boot is simple, grub is feature rich. Both have their uses.
I love systemd-boot and use it whenever practical. However, one place where grub is definitely easier is managing a multi-boot system. There are a few reasons for this:
Since systemd-boot keeps all the kernels in the efi partition, you may need a larger efi partition than most people have. This isn’t a big deal if you recognize it upfront, but it can be a pain if you have a small partition such as the one Windows creates by default. Resizing the efi partition is often non-trivial. For example, I use systemd-boot to boot four Linux distros and the used space in my efi partition is currently 768MB. I suspect not many people have an efi partition that large. This has become a bigger issue since more distros are keeping multiple kernels installed.
Similarly, kernel collision is problem that needs to be worked around. For example, booting two versions of Manjaro or multiple Arch-based distros requires some acrobatics to get everything working where in grub it “just works”.
From my perspective, grub is a good solution when you want something “easy” and systemd-boot is better if you prefer “simple”. Personally, I prefer simple over easy.
No, each distro manages its own entry separatly from the other distros…
When it comes to sdboot-manage, IMHO that is buggy as hell and i prefer to write my own hooks…
And it’s no hassle at all from a distro pov. compared to what else they need to customize, a small text file can hardly be labeled as such…
Wrong thats not the job of the bootloader, its the job of the bootloader configurator.
About grub doing that automatically, you’re wrong update-grub aka “the bootloader configurator” is creating the menu entries.
Grub does not generate menu entries at runtime…(But sd-boot actually can and does for firmware setup, efi shell and M$)
I solve that by mounting the ESP at /efi and do a bind-mount of a subdir of the ESP as /boot eg: systemd-mount -o bind /efi/Manjaro /boot or inside fstab or like me in (auto)mount units…
So in short grub looks like it is easier because it already has scripts doing all the needed heavy lifting, while sd-boot (Systemd-boot) does not yet, which will change as time goes by and more and more people use it
Since this seems like an attack on something I spend my personal time on, I will just say that I have fixed every bug that I can verify and has been reported with sufficient information to resolve. In your case, of the four issues you reported, one was fixed, one was not a bug and the other two required more information to resolve.
That being said, it doesn’t work for everyone and may not be a good fit for your specific situation. The goal of it is to provide automation for people who are familiar with how grub works on Manjaro. Not to be a replacement for things a power user can do by hand.
That is what I was referring to as “acrobatics” and what you describe is the opposite of “just works”
systemd-boot has been around for a long time now. It doesn’t seem to me like lots of distros are moving to it in the near future. It seems more like the distros who want to use it, already are.
Again, I am a fan of systemd-boot so don’t take this the wrong way. I just don’t see it as the clear path towards the future. I see it as one option of many. It fits some use cases well but grub fits a bigger variety of use cases in a more automated fashion. Unfortunately, to do that, it brings with it a bunch of complexity that many of us find unnecessary.
To avoid misunderstanding, I recommend using more neutral language when criticising other projects.
Since both of you work on similar projects, how about some collaboration? Major issue for adoption of systemd-boot is the lack of ecosystem around it. If there was a cross distro tool similar to os-prober for systemd-boot, it would be quite beneficial.
Here is a link to a repo
When I talk about grub, I’m referring to the whole ecosystem around it, not just the bootloader itself.
This reply made me say that, as it will wipe pre-existing entries with its default config which is used at install time…
That reply clearly stated that he was unwilling to fix that behavior (my point 4 in that issue)
It also made me drop that topic instead of going into a debate…
I completely agree with the need and i have already mentioned it to the systemd devs.
But the fact is that different distros do things different wrt to kernel and ramdisk images, thats why they all need separate scripts to give the same results…
I use rEFInd, but I don’t believe it supports encryption, which I need for my laptops. I use rEFInd on my desktop though, and love it. That being said, I haven’t actually tried it with an encrypted drive myself, I’ve only read about it.
Yes it is. It’s more than just a simple text file that is needed. You need to write scripts, hooks, and modify the installer. The you need to package it and test it. With grub, all that is already done. So compared to no hassle at all, it sure is hassle.
Also, even if the work for grub wasn’t already done, you would still need to maintain another bootloader option for legacy boot. So even in that hypothetical scenario, it’s twice the hassle.
So, as a distro maintainer, you need to justify the extra time you would need to spend on it. And systemd-boot offers… Less features and marginally better performance on low power hardware.
If you eliminate every performance gain like that from the start, then your whole system will stay a powerhog at end…
It’s like a developer prefering VisualC over assembly to write a driver…(eg. bad choice)
Performance is important, but it is not everything. There are other factors to consider too. Assembly is not the right choice for every need. You always have to balance developer time with execution time. In my tests, systemd-boot is 0,5-1,5s seconds at booting than grub. Booting happens 0-10 times a day. That’s some added benefit, but not a lot. If someone else is putting in the time, then the tradeoff for me personally becomes better.
But it’s not just developer time versus execution time. It’s also less features and less supported hardware. It doesn’t support legacy systems and all, and some systems like my previous laptop, systemd-boot just refuses to install where other bootloaders start happily.
So, is there something else interesting that systemd-boot is bringing to the table as a a distro default? I think it is a great option for some use cases, but it doesn’t currently support enough use cases yet to become the default.