Hacker News new | ask | show | jobs
by raggi 799 days ago
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.

2 comments

> 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.

Arch install script defaults to systemd
I didn't know systemd had its own bootloader. I thought everything was still GRUB, I think all my systems are GRUB.

Course I'm a few years out of date

Pop!OS has systemd-boot on systems with UEFI
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.

[0]: https://wiki.syslinux.org/

Actually, with refind being a thing, I'm not sure why grub is still a thing.

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!!!!!!

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.

This is the reason why I disable all non windows drives in my machine before letting any Microsoft installer do its things.
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.

Isn't rEFInd a Hackintosh thing? That's the context I hear about it in, anyway.
Fwiw I've had pretty good experiences with getting LLMs to do the gruntwork of porting Bash to Python in my case. It's a translation task after all.
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.