Grubs install process is a complete disaster. I went to use it to boot Fuchsia on bios systems at one point, when Zircon still supported multiboot chaining.
The "install" scripts and so on are all horribly broken, and extremely badly behaved in terms of grabbing arbitrary stuff from the environment that has nothing to do with your desired target system. Using them for anything other than modifying the current host system is extremely sketchy at best.
I ended up re-implementing the whole process in a pile of bash (it should have been in something else, but I started in bash, and finished there). The slicing up of the bios segment that it does is also unnecessarily fiddly considering how it's all constructed, it would have been far easier to keep those segments in separate files and then you could just write one buffer after another in any language/tool environment you want.
The whole thing seems like an accident of history that no one wants to fix, which would be approximately congruent with all of the tooling in that area of the boot path, partition tools and so on.
> The whole thing seems like an accident of history that no one wants to fix
I can’t really speak to Fuchsia systems, but a lot (most?) Linux desktop distros use stub or systemd-boot bootloading these days. And if you want to get fancy, there’s rEFInd.
> I can’t really speak to Fuchsia systems, but a lot (most?) Linux desktop distros use stub or systemd-boot bootloading these days.
Which ones are you thinking of? Most 'desktop' distros I've used recently still default to Grub (Debian, Fedora, Linux Mint, Ubuntu) though I'd certainly be glad if change is on the horizon.
Don't forget Syslinux[0], available for both legacy BIOS systems as well as EFI. All binaries except for the really low level stuff are in ELF format, so can be generated, linked and manipulated by tools which support this.
Windows is a bit better these days, if you create an EFI partition it'll just use that even if you've made it much larger than it normally creates for itself.
This means you can just partition everything from Linux and then install windows safely into where you select.
systemd’s efforts in the boot path are very welcome, they’re much better. Sadly as others have noted, a great many distros are still using grub.
To clarify a bit too, as it seems it may not have been clear: grub was never run or installed inside a fuchsia system, I was building disk images from Linux hosts.
I threw the code away again in the end. We didn't have that much of a need for non-UEFI targets, but I was experimenting at the time with booting on some cloud x64 machines that lacked UEFI support.
If I had to do it again, I'd probably just write a loader myself. It took about the same amount of time to fight grub as it would have done to smush together a basic GPT / FAT / jump chain.
It's pretty well documented with a pretty simple configuration language (if you already use a bourne shell (and you probably do), you already know how GRUB's syntax works).
I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.
... can you really fault software that has "Grand" and "Unified" right there in its name for trying to be just that? The number of systems supported by GRUB is really impressive, the number of special-sauce features supported (filesystems, RAID levels, snapshots, etc.) downright staggering. And if you don't like it, there's plenty of alternative, simpler options with a narrowere focus. I use systemd-boot on most non-Debian (which supports A LOT of other platforms, mind you) x86 EFI boxen of mine.
GRUB might be an unnecessary complexity for a number of use cases, but it's a solution that strives towards being universal (which is also a goal of Debian). I think it comes rather close, and I am happy it exists. Learning you way around it for an hour or two will yield payoffs down the road.
I think it's fair to wonder, if the job is that varied, then was it ever the correct design approach in the first place to presume to ever be able to predict and handle the unpredictable infinite permutations?
This is init vs systemd. 50 years ago, they could not predict all the crazy infinite things a unix system would want to do. And yet they made a system that handled it all possible needs by knowing enough to avoid making assumptions about the infinite other end users or the infinite future. They knew the most important thing which was not to pretend to know the unknowable.
They made a simple base framework and a toolbox, and everyone was able to serve their own crazy individual needs, still 50 years later.
And it still works. Systemd did not need to come along to fix some deficiency, it just came along anyway because for every wise engineer there are 10 clever engineers, and after 50 years of rapid growth the population of linux admins is less than 1% people that know how to reject a shiny new bad idea and 99% kids who do not. Plus of course a few huge businesses who just want that kind of appliance system for their own business reasons and don't care one turd about engineering or empowering the end user or anything like that outside of their own walls.
It's at least fair to look at grub2 and wonder if it's not just a huge self-inflicted wound from trying to deny the undeniable.
Maybe it should be something more like a library of smaller scope scripts that the end user uses a bit more manually.
The common cases can still be handled automatically so no change for 99%, the uncommon but known cases the user can configure their system to use something from the library for that situation, and totally new unknown situations are simpler to handle by writing a new script or adapting an existing one, because the framework is fewer layers and less indirect.
"And it still works. Systemd did not need to come along to fix some deficiency, it just came along anyway because for every wise engineer there are 10 clever engineers, and after 50 years of rapid growth the population of linux admins is less than 1% people that know how to reject a shiny new bad idea and 99% kids who do not. Plus of course a few huge businesses who just want that kind of appliance system for their own business reasons and don't care one turd about engineering or empowering the end user or anything like that outside of their own walls."
If you want to you can always run something like Devuan. You don't have to shit on other projects or people to run the software that you want.
Sure if I want, I can indeed run anything at all, including that. What's that got to do with anything?
The observation of majority linux and systemd and unix design principles remains a fact regardless what I happen to run. Even if the only thing I happen to run is freebsd which has no such problem. "you can run ..." is both true and irrelevant, doesn't change a thing.
Another thing I can do if I want to, is observe something and describe what I see, even if someone like you doesn't agree, and has no better way to handle that than to suggest the speaker should do something else besides speak their mind rather than actually argue or counter any of the points. (Everyone including me already knows the sales pitch for systemd, it's unlikely you have any argument that I don't already know, this is very much a religious issue at this point, as in there is no actual changing of anyone's minds on either side)
You like systemd and don't like hearing blasphemy criticizing it? Tough shit!
The complexity of GRUB isn't justified by the number of systems it has to support. The number of supported systems is also not the reason why GRUB is so complex. The cause of complexity is poor design choices, if you can even call it that, when it comes to configuration and defaults.
It doesn't matter that better options exist. GRUB is the subject of this discussion. If it were about systemd-boot, then it would've been legitimate to complain about it or to praise it. But, it's not the subject.
But, since you mentioned "other options"... they are both the indication of the larger problem: Linux boot process is poorly designed and that's why many independent teams tried to replace it to variable degree of success. GRUB isn't the only poorly designed piece of this process. And they work to obscure and make even less accessible the subject of system booting for the wider audience, creating a feedback loop where the only few people brave enough to dive in and try to understand it are the people who started way back and usually have very distorted ideas about how their code is used by the layers built on top of it.
The whole of the booting process didn't need to be this complex: it could have fewer stages, fewer utilities that are responsible for different stages, fewer possible boot scenarios, better defined order of device initialization... the list goes on. GRUB is only a part of the larger problem, albeit it's a big part.
Configuration in Bourne Shell is already a bad idea, documented or not. Add on top of it is that there isn't really a configuration... you edit some files (multiple!) then you need to know to run some other script, that on different distribution of Linux will be called differently (if it at all exists) to generate this configuration from another configuration. And the added bonus is that this script will also sometimes run when upgrading some (typically completely unrelated) packages, and if you were so naive as to try and edit the configuration w/o running the script, your changes will be undone without warning.
Configurations are supposed to use a languages that is just powerful enough to express it. The more declarative the better. Shell is a very bad configuration language because it allows to do way too much and is very forgiving of errors.
Now, add to this that GRUB installation is trying to do configuration too... and if you are doing stuff like creating VM images or similar, where you have to install packages in an environment that's not a real physical computer with a bunch of periphery attached, you will run into all sorts of problems (because for some reason GRUB wants to have a PTY and a bunch of other devices / pseudo-filesystems that it has no business sticking its fingers into) and if you aren't present at the keyboard during package upgrade / install you might not even notice that GRUB has failed to install / install correctly.
So does quantum field theory, which, as a matter of fact, has many manuals.
Doesn't mean either QFT or grub are understandable or even usable by mere mortals.
Difference being than in the case of grub, given what is does, the complexity and opacity of the manual, config languages and diagnostics message is completely unnecessary.
So assuming your machine supports UEFI, what are the common use cases that systemd-boot would not support, requiring you to use grub?
Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption. So not a common use case either, maybe a desirable one.
For root partition sure. But for boot? Normally when you choose an encrypted root partition you get an extra boot partition without encryption. Unless that has changed rather recently.
> Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption
Isn't it deliberately slow to resist brute forcing? At least at one point, the default number of rounds in cryptsetup was decided by counting how many rounds it could do in 10s as part of the setup process on your specific machine
I originally wrote ZFSBootMenu as a reaction to how awful Grub is. I was hacking on the Grub scripts and hitting all sorts of limitations that were just awful to work around (or not possible at all). I used Grub to chain load early versions of ZBM before I had the whole UEFI application build process worked out.
Iirc when I upgraded from ubuntu 22 to 23 grub stopped being able to boot my windows drive. I played around with it for like an hour and it just wouldnt work, so now whenever I want to boot windows I have to use the efi boot menu instead which is a good enough solution that I wont spend more time on the problem.
Linux feels like a jumbled mess, akin to a box of LEGO where none of the pieces fit together. With countless package managers, desktop environments, and distros, etc. it's a chaotic maze of choices. Yet, despite the abundance, usability remains a distant dream. It's frustratingly disappointing, to say the least.
One of the areas of Linux that I slunk away from defeated is understanding grub and the boot process in general for Linux. Either I am stopid or it is stopidly complex or both.
Nah, I never understood it. You'd probably be better off writing your own from scratch that does exactly what you want it to do. I've written both MBR and EFI bootloaders, but for MBR it's probably better to copy at least some of the very early boot stuff from somewhere else.
This.. For a moderate somewhat prosumerish user like me, it's these kind of stuff which is why can't have nice things. It used to be the ./configure, make, make install hell which modern package managers and distributions seem to have fixed for most software, now it's this.
Grub is just unnecessarily complicated. Simpler options exist (even ones with the same level of flexibility, though I am most familiar with embedded options there: Something like barebox shows an alternative approach that could be applied to desktop: basically just make a shell environment in your bootloader to script your more complex requirements). But 90% of users nowadays can just use systemd-boot.
barebox can be compiled as EFI payload and used on Desktop systems. The main impediment is packaging it for the OS and scripting the hooks that would write e.g. bootloader spec files on kernel updates.
-2 points, yikes.. not sure if if that's 3 angry people that had to deal with LILO not working or 3 people thinking I was just spamming who never had the pleasure of dealing with LILO.
Speaking of the devil: I just upgraded an Ubuntu install which I hadn't touched for around a month, and after rebooting I'm unable to boot Ubuntu.
It's very odd. Instead of the GRUB menu, only a countdown number shows up on the top-left (5,4,3,..) with an underscore behind it. "5 _". All the rest is black.
When the countdown finishes, the system boots into the (UEFI) BIOS.
If I use the BIOS' boot disk selector, then it also happens both when I directly select the Ubuntu installation as well as when I select the GRUB bootloader.
The "install" scripts and so on are all horribly broken, and extremely badly behaved in terms of grabbing arbitrary stuff from the environment that has nothing to do with your desired target system. Using them for anything other than modifying the current host system is extremely sketchy at best.
I ended up re-implementing the whole process in a pile of bash (it should have been in something else, but I started in bash, and finished there). The slicing up of the bios segment that it does is also unnecessarily fiddly considering how it's all constructed, it would have been far easier to keep those segments in separate files and then you could just write one buffer after another in any language/tool environment you want.
The whole thing seems like an accident of history that no one wants to fix, which would be approximately congruent with all of the tooling in that area of the boot path, partition tools and so on.