Follow-up to my first Gentoo install.
Follow-up to my first Gentoo install.
TL;DR: Do. Not. Share. Boot. Partitions. Across. Linux. Installs.
------------~
++~------------<
So a couple days ago I posted a screenshot of my first Gentoo install in a VM. I mentioned that I planned on putting it on my hardware in a triple boot setup (Arch - Main, BillyG-O$ - VR games, Gentoo - Pain). This is a follow-up on my adventures doing that.
Everything went well initially, I followed almost the exact same steps as the VM and things went by much faster (as it had access to all my resources). However I made 1 respectfully sized blunder, for some stupid reason, I tried to share boot partitions between my Arch and this Gentoo. DO NOT DO THAT, I can speak from this experience.
Because of sharing boot partitions, GRUB got absolutely buggered 6 ways from Sunday resulting in GRUB unable to find my Arch initramfs. Not good at all. So for about 2 days my system was unbootable (I took a break from the computer, I'd just about had it).
Thanfully though it turns out my previous Arch-only GRUB install still existed so with a quick boot override I was finally able to get back into Arch. I then proceeded to totally destroy every last trace of Gentoo from my boot drive and reinstall the kernel, thereby remaking my initramfs. My system is restored 🥹.
So, in conclusion, I feel that Gentoo is definitely good fun and worth doing, however if you're installing it on the same drive as a pre-existing OS be. Hyper. Vigilant. I'm not sure how or why my old Arch-GRUB still existed but by golly am I thankful it did.
This did not scare me off Gentoo at all because it was my error. So I'm probably going to reattempt it soon. I also jusy wanted to say thanks for the engagement and tips on my previous post, I love the Linux community and our little corner of the internet. I await the day where our pride and joy is mainstream, along with so many others I'm sure. I hope you have a great day/night :).
You're viewing a single thread.
There’s no issue sharing boot partitions unless you use Grub. (Please stop using Grub)
That's the first time I heard some argue against Grub. Can you expound? I'd be interested to hear more.
- Single config file for the entire boot loader, which makes exactly this case of booting multiple installations unnecessarily hard because one OS has to generate the config for all the others (which can generate unbootable entries, like for NixOS which needs a special init= argument)
- Of course, the Rube Goldberg config generator itself, which is a big source of problems with the system not booting, but is pretty much needed because of the complexity of the config file. It doesn't need to be this way, rEFInd for example might not need a config file at all, and systemd-boot can do with a very simple ~5 line file per boot entry
- The latest release is 2.06 (from 2021), there's distros that have almost a hundred patches on top to fix CVEs, which isn't very maintainable for distros and doesn't make the upstream look well maintained either (other distros just use an unstable version)
- 300k LoC as opposed to rEFInd's 50k or systemd-boot's 13k. Of course, code size alone doesn't mean anything, and I haven't checked but I assume most of that is code that was needed for BIOS boot which nowadays just reimplements UEFI features, this includes at the very least: graphics code, network support, file system support
That's just some I can think of off the top of my head, I'm sure there's more. Apparently the code itself is pretty horrendous too, but I haven't looked too closely at it. Given the way some command line tools act though (like grub-mkfont, which iirc always exits with 0 even if there's an error, which led me to do questionable workarounds in a shell script to let me detect errors while still printing its output), it seems to check out.
My latest "experience" with it is that a couple weeks ago I had to deal with a machine which would just get stuck at the Grub prompt. Turns out Grub just wouldn't load its config file anymore. You could manually load the config with a command I already forgot, it just wouldn't do it by itself. Running grub-install made it work again, I still have no idea what caused it though.
IMO, the whole thing is a hot mess and the only thing it's got going for it is the extensive theme support, like that Minecraft one that was pretty popular recently (but do you really need to theme something that you see less than 5 seconds per day?).
rEFInd has cool themes too.
That does make sense. Thanks for the extensive write-up.
I wonder though why it's then still the default option on most distros.
I assume because it's the only well known boot loader which fully supports both legacy boot and UEFI and as such less work to support both is needed, when the boot process is automatically managed. And probably also because it's not broken enough (yet?) to put in the effort of getting rid of it.
However according to https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader, there's also Limine which I've never heard of, which supports both as well. I'll have to check it out sometime.
Yeah, I guess that makes sense. The bootloader isn't exactly something where anyone desperately needs innovation over stability.
I like GRUB, it's what I've always used and it's never failed me. I don't like messing around with bootloader stuff for reasons like this. If I was only using 1 OS then yeah I'd probably use efibootmgr or something and just have it jump straight in.
it's never failed me
Are you sure that it's never failed you? Because that's not what this sounds like; you may have Stockholm syndrome.
There's a whole specification for sharing
/bootand/efipartitions across multiple distributions. GRIB doesn't implement it. Give systemd-boot a go, the transition is painless.