It's far from clear how grub package updates work on Ubuntu
utcc.utoronto.ca
utcc.utoronto.ca
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.
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.
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.
Course I'm a few years out of date
Also why MS' bootmgr stuff is still a flaming pile of junk.
Edit: And why MS has never given us a way to dictate where it installs its junk and/or to not install its junk!!!!!!
This means you can just partition everything from Linux and then install windows safely into where you select.
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.
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 far from clear how grub works, uprade or otherwise, period.
Much less how to configure it or install it.
Sendmail.cf or jq level configuration language in terms of obscurity.
Cryptic error messages the severity of which is impossible to infer (actual impact being from no impact whatsoever to my computer won't boot anymore).
Not my favorite piece of Linux software by a very large margin.
I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.
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.
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.
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.
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!
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.
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.
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.
Granted, prior to Debian Bookworm I had to roll my own initramfs- and kernel-hooks, but there were blog posts and I didn't need to develop them.
I even tried directly booting into Linux EFISTUB, but thats uselessly annoying compared to a proper bootloader.
it's a literal checkbox install option on Ubuntu at least a few versions back (i'm not up to date), so I wouldn't call it uncommon.
The theory is that messing with boot can compromise your system and leave you vupnarable despite encryption.
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
IMHO it contains enough functionality (filesystem access, user interface, program execution, etc.) that it could already be considered an OS itself.
That's what ZFSBootMenu[1] is, an OS to start the OS. And as sibling points out, if you're using EFI you got an OS booting your OS booting your OS...
Flexibility.
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.
I hope I'll enjoy the ride.
It's what I use for dualbooting Windows and Linux. It's really easy to Install, Use & Understand.