Gorgeous-GRUB: collection of decent community-made GRUB themes | Hacker News Reader

Gorgeous-GRUB: collection of decent community-made GRUB themes

github.com

458 pointstodsacerdoti123 comments

I'm a huge proponent of customisation, but for me, the less I have to see or even think about GRUB, the better.

Yeah, I usually see it for seconds a year. If I saw it often enough to worry about theming it, I'd rather spend my time on fixing whatever caused me to have to see it so ofen.

You'd spend more quality time with it if it looked beautiful. Think about it going up and down those menus for hours on end. Quality grub.

Meanwhile, with kexec on a good day you can spend zero time in the bootloader for as long as the system doesn't need a full hard-off power down:)

Ah. You don't ever patch, I guess.

Or he is managing headless systems where you don't see the boot process unless something has gone wrong.

I never wait for a computer to boot by staring at it unless I'm fixing a problem with the boot process. I wander off and come back later.

When I'm on the move I'll power up a PC without sitting down and come back to it later, but never "wander off" if I'm already sitting there since it only takes about 20 seconds to cold boot, 5 seconds of which is intentional delay in case I want to choose something other than my default OS from the bootmenu.

I say it is really nice not to have any problems with the boot process myself.

> but never "wander off" if I'm already sitting there since it only takes about 20 seconds

Ah I take it you don't have ADHD then? For me, it's not the 20 seconds - it's the fact that this time it might be the 2 minutes boot because it did an update in the background. So I'm happy to assume that any boot/reboot is 2 minutes long.

That's where those few seconds a year comes from. My boot screen is visible for a second or two when I reboot - this isn't the 90s.

I think this is the kind of thing I would do If I had to choose between OSs with frequency, either home lab/experimentation or linux for stuffs and windows for games kind of scenario.

So there is nothing to fix, the nice choice screen is a feature.

Look at the screenshots. They are all about booting multiple OSes or distros, and should make sense for those who switch between them often. ("Why" is another question.)

I used to dual boot with Windows before WSL was a thing and I agree that back then I'd see GRUB on a daily basis.

BTW, before that, coLinux existed!

https://en.wikipedia.org/wiki/Cooperative_Linux

"Grand Theft Gentoo": https://raw.githubusercontent.com/Jacksaur/Gorgeous-GRUB/ref...

Oh my gosh, that one’s a gem! Rage Linus on the top right, smug confused Balmer on the bottom… the Gates mugshot is icing on the cake. awesome!

What I really would like: something that mimicked the old SGI start up, complete with boot audio and a micro distro for OS setup. These days, with snapshot filesystems, that shouldn't be too hard. Also, I've had to chroot to fix my system in my life a few times; I can't believe that's hard to automate.

On Arch, I think you could install a second "backup" copy of Arch Linux on a recovery partition that your motherboard firmware can boot into directly, and then use the `arch-chroot` program to recover your main OS. I'm sure something similar exists for other distros?

You can always do this on any distro, but not necessarily with the install wizard.

macOS has both these features, sort of.

Startup chime in SGI machines depended on model. So an Indy had a different one than an Onyx. My first PC (80286) also had iconic sounds when it started up. Never forget.

Micro distro, is recovery OS. All three major desktop OSes have such, or a key combination to activate such. Android has two recovery partitions I believe, redundancy is key.

If you like the power of snapshots, yep filesystems with CoW like ZFS can show a list during boot. An OS like NixOS wouldn't even need such. Works perfectly fine with Ext4FS, including boot menu with snapshots, rollback feature, etc.

> My first PC (80286) also had iconic sounds when it started up.

    BEEP BOP. bidiedi-bop. bip.

I feel like your best bet with this would be one of the kexec-based bootloaders, because then it's a "real" Linux environment there, with whatever tools you want in it, instead of something special.

Eg: https://github.com/kexecboot/kexecboot

I do wish more effort was made to polish all the bits and pieces because all of this exists in some form. I suppose some of it is that everyone is doing their own slightly different thing; NixOS lets you boot to earlier generations, but only by completely turning the filesystem inside out, OpenSUSE can do snapshots, but using BTRFS which means that not many other distros even can use the same implementation, ZFS is the bee's knees but on Linux licensing always adds friction, Ubuntu made boot super smooth via Plymouth but it's very... Ubuntu.

Anyways. If you're in a position to run Linux on ZFS, may I suggest zfsbootmenu?

> ZFSBootMenu leverages the features of modern OpenZFS to allow users to choose among multiple "boot environments" (which may represent different versions of a Linux distribution, earlier snapshots of a common root, or entirely different distributions), manipulate snapshots in a pre-boot environment and, for the adventurous user, even bootstrap a system installation via zfs recv.

- https://docs.zfsbootmenu.org/en/v3.0.x/index.html

What's wrong with Plymouth? I use it on NixOS and it seems to just work and show a Nix logo on boot

Interesting, either it got a lot better or I misremembered. Last time I looked, using Plymouth on anything but Ubuntu was a lot of rough edges and manual setup. By skimming wiki pages it does indeed look like that's not true anymore (if indeed it ever was; I could have been wrong before).

I just found ZFSBootMenu and am really enjoying it so far. Cracks me up that all the zfs tutorials online are from circa 2010. I guess I missed the memo back then. For those wanting to try it, it took me a while to find the actual installation instructions: https://docs.zfsbootmenu.org/en/latest/guides/void-linux/uef...

On NixOS we get one new grub menu entry per “deployment”, be it when you deploy to another host or the local one. They both then get a new grub entry. Of course you can still shoot yourself in the foot by making your system inaccessible remotely, by screwing up ssh config for example. There’s also a solution for that called deploy-rs which has a magic rollback feature which rolls back the system if it can’t connect back to the computer initiating the deployment https://github.com/serokell/deploy-rs?tab=readme-ov-file#mag...

I’m using these features since multiple years now and can vouch for them.

Not exactly related to your initial question but I also have my system build in CI and do some playwright tests which become more and more comprehensive as time passes. This all gives me quite a lot of confidence I’ll find an issue early or be able to revert back.

Could you tell me more about the playwright tests? From what I can see it's a web testing framework, I don't see how that fits in here.

Ah you’re right. I should’ve been more clear.

I’m deploying on my server and it self hosts 10 or so services. Like Nextcloud and Vaultwarden. The playwright tests are to test those. It’s pretty basic like just checking I can create a user and still login. But it still caught a few regressions. And they’re still WIP. I’m getting close to being able to validate the LLDAP + Authelia config works too. It’s particularly useful in conjunction with automatically running flake update in CI. So all inputs get updated on a schedule and the tests give some level of guarantee that my server won’t break. It’s essentially QA tests automated.

This link shows what the playwright tests look like. They are parametrized on the service to test so I’m sure I’m testing the same functionality every time. https://github.com/ibizaman/selfhostblocks/blob/c2148eda7704...

Ah got it, thanks. I thought you were testing the image somehow, a bit like inspec.

Still cool though, nice.

Stuff like this is why I fell in love with Linux. Some amazing creativity in here. Almost makes me wish I dual booted with something so I’d have an excuse to see grub!

This, wobbly windows and rain effects. I wouldn't use any of that today, but it captivated me, at a time when customizing windows was becoming more cumbersome with each release.

While these are cool, I honestly wish GRUB was silent unless you’re holding a key during boot. The 5 seconds it takes to go away and just boot the OS by default is really unnecessary.

I'm pretty sure there is an option for this, holding shift makes it show the menu.

What if you don't remember the key you need to press?

You RTFM (which can be a quick search or LLM chat away on another device like your phone).

I think you can get that by setting `GRUB_TIMEOUT_STYLE=hidden` and `GRUB_TIMEOUT=0`. Then you can hold `Shift` to see the GRUB menu, otherwise it will boot the default option immediately.

Good tip. I've always felt like I'd like to be able to boot directly into the Second Option via a key, etc. like Shift + 2 etc

Make sure this works on your system before you really need it, as some keyboard/USB-controller combinations take a few seconds to wake up from whatever slumber they're in and start working. I ran into this several times.

That's likely something related to USB legacy support being on or off.

A lot of modern BIOS/EFI also allow a hybrid setting that enables legacy support until the OS takes over, which can sometimes be better too.

Why would you actually want this? Such a weird desire to hide this kind of stuff because it's so inconsequential in my mind.

Because sane OSes have sane defaults, and this is one of them. Hide information by default, unless called for. Want verbose boot log? Ask for it. Want boot menu? Ask for it. Need Bluetooth enabled at boot? Aak for it. Don't overburden the user with irrelevant info. When my 7 y.o. daughter fires up the Steam Decj, she doesn't need to see the boot menu.

>she doesn't need to see

My parents let me decide what I needed to see and learn how to customize things for myself. That seems like a sane default to me.

No, they don't; they let you decide some things which are relevant. People in the know decide defaults. This is how it works everywhere. Else you'd learn to bicycle with your own traffic rules. You'd end under a bus.

Addendum: You could say you want a sandbox, and that such is part of the sandbox to play with. Then you need some kind of way to clean up, like you can clean up the toys your kids play with (or ensure they clean up their own mess), or ensure their sandbox environment is safe (such as no fire hazards in your house). Then I would argue a VM is such. OS with rollbacks or a user account on an OS or locked down iOS/Android could suffice, too.

>you'd learn to bicycle

My parents gave me the bicycle in a box. I had to put it together if I wanted to ride it. They owned the bicycle shop too. They could have put it together for me, but they let me do it.

On a modern laptop running Linux, the three slowest things in the boot are:

- The firmware

- The bootloader timeout

- Waiting for the user to type the encryption passphrase

Everything else takes almost no time at all. So, if you can eliminate 5 seconds from the boot process in the normal case, without eliminating your ability to debug the system in the unusual case, that's a win.

But how often do you boot a modern laptop in the first place? I feel lke the time I save in not waiting those 5 seconds occasionally is all going to be spent again in the minutes wasted having to look up how I stop the instant autoboot (or failing to stop the autoboot and having to reset and try again) the first time I need to actually interact with grub...

Every time you update the Linux kernel, among other things.

Or, if you're working on speeding up virtual machine boots, in which case you skip the bootloader entirely and use the kernel's EFI stub.

Every time it runs out of battery power.

"I never let that happen." Cool.

if you use the TPM storage, you can avoid typing the encryption passphrase

That doesn't provide the desired security, unless you also then carefully lock down the system so that the TPM doesn't provide the key if the software has changed. That's theoretically doable but challenging, with many failure modes in both directions: not being able to get into the system, or someone being able to get into the system when they shouldn't.

Everybody complaining about grub forgot about lilo

RIP. Pouring one out for Linux loader.

Lilo is still alive and kicking on Slackware ;)

Does LILO work on EFI systems or is GRUB preferred in that case? I’ve not built a Slackware box in a long time… maybe this evening I’ll see about putting a VM together

Slack ships elilo package for EFI systems. AFAIK config (elilo.conf) should be pretty much the same as standard lilo.conf

I can’t think of a single reason to entertain Slackware or lilo. I have extensive experience with both.

I still prefer Syslinux but it's still not officially supporting UEFI yet :(

The only time I would want Grub is for that reason primarily. But it makes sense to be very familiar with Grub so you can not be screwed up by systems you encounter which may have been set up, "grub-reinstalled", or configured by those who are not as familiar as they should have been.

Once you do have a regular ordinary multiboot system or SSD that includes one or more Linux installs, with Grub working well, then adding the themes like this is only the icing on the cake.

Hehe I was like: What?! Grub was LiLo’s successor and much better! What happened to the time?!

Back in the day I had a cool self made theme from Ghost in the Shell, I remember making some very obscure image format from some jpeg I found online. Man what time I have put into customizing my Linux experiences. The computer was truly a (well trimmed) pet. With desktops on kubes with fish inside and reflections etc.

Oh dear, you transported me back to 2003

ITYM Lilililililililililili....

How do those background images scale on different monitors/resolutions?

Btw, how does grub figure out in what resolution to draw the interface?

judging from some of these repos, I think the answer is: they don't. It seems like you have to manually pick images with the correct resolution

You can set the resolution explicitly, otherwise it will render at resolution UEFI started the boot with.

This is a significant peeve of mine. The need to explicitly specify resolution in boot managers is annoying for both laptops and machines that aren’t always used with the same monitor, because no matter what it’s going to end up in fallback with an ugly stretched resolution some portion of the time, rendering beautification with themes somewhat moot.

This limit made sense 20+ years ago but today it feels highly anachronistic, kind of like finding a corded rotary phone mounted on a wall in the kitchen of an otherwise cutting edge home. Surely it’s something that could be fixed?

May be, but this is so minor in general, that I barely care as long as it boots properly.

Way bigger annoyance is that grub still doesn't support luks2 and uses some gimped variant of libcrypto without proper hardware acceleration that decrypts boot volumes for almost a minute. That is way more serious than boot resolution annoyances.

That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things

Yes - use newer libcrypto. They are in the process of switching, but it just takes very long. I don't see why bootloader won't be allowed to use the CPU features that accelerate decryption.

> They are in the process of switching,

Nice! Do you have a link with the progress of this? Maybe in a mailing list or something. I can't manage to find it

Also, do you know whether grub plans to support luks2?

And maybe even veracrypt - ok this one is unlikely. (cryptsetup can read veracrypt just fine and the Linux kernel copes with it, maybe it's a matter of porting this code to grub? One issue is that grub would need to embed the number of iterations of the key derivation function somehow - the thing veracrypt calls PIM - because unlike luks, veracrypt doesn't store it in a header that can be read before unencrypting)

The main bug is here: https://savannah.gnu.org/bugs/?55093

But I do recall some other post which went into more details and was saying that switching was taking time due to lack of stable API and other issues.

Try searching for grub 2 + libgcrypt. Some links are also in that bug.

What can I say? Feels weird to include a JSON library in a bootloader.

Maybe a stage 0 bootloader, definitely not a stage 3 one.

We are talking about a stage 3 bootloader which supports booting from encrypted volumes and ZFS snapshots.

JSON-support would be adding 0.001% extra to the overall package.

In terms of material impact, it is minor but as far as impression shaping papercuts go, bootloader jank is pretty high up on the list.

My pet peeve is that grub repartitions windows disks on chain load, so if it ever boots with the disks remapped, there's a chance it'll plow apart the partition table of whatever poor disk got mapped to that hd#.

I can finally make my computer look like the ones from hackers! Awesome.

Haha, my first thought when I saw the themes was, wow this is exactly like the movie!

Might rewatch it soon, been listening to the soundtrack while working lately :)

A soundtrack so good they made three separate soundtracks. The last one was entirely music that wasn’t in the movie.

Fantastic.

Grub is like a turd that won't flush. It's been completely unnecessary for years, is massively overcomplicated, pretty much unusable as a shell with it's 1995 idioms, and there are much, MUCH lighter (and as useful) replacements (extlinux etc) -- and you can even just remove it completely and boot the kernel directly these days with the EFI stub...

But still, it gets installed, trying to justify its existence.

Okay. I have a laptop here with windows, haiku and Linux. And actually the grub (2) configuration to get haiku to start was strange. What exactly do I install best to replace grub?

Or alternatively, I have a PC with only Void Linux. Compatibility mode for booting, since uefi mode did not work (I dont know why - some secure boot shenanigans? MBR vs GPT mode? There is no EFI partition as well). What could replace grub there?

I am on Void Linux too, and grub works fine. sighs. Why would I replace what has worked for decades?

I personally would like to be able to enable the UEFI boot mode of the board, so that I can enable Resizeable bar - for the performance benefit and to have the option to add an Intel GPU later. So cleaning up the GRUB situation could help me there - that's why my comment above was completely serious, I'd really look at suggestion.

Because otherwise I see it like you, why change what works. Even the move to Grub 2 with the more complicated config options wasn't all that bad, since it really needed less often to be configured manually. So after a bit I was fine with that.

In same boat here. I just do not understand the *EFI stuff anymore, and I've tried.

I somehow got refind to work, after disabling some vaguely named "secure boot" option in the BIOS. It shows my several linux options, and the only one that works is "rescue", that boots what is apparently a systemd bootloader with Nix generations. When I select Windows, I get some windows boot menu/loader instead of directly booting Windows.

I have no clue how it all works - there is some partition with some files, but I also must run some command to "apply" changes - I think. It's horrible.

I don't know if it will work for booting Windows, but have you tried installing Haiku's BootManager to the MBR?

https://www.haiku-os.org/docs/userguide/en/applications/boot...

On the booting Windows front, this thread has a few people describing how they successfully used BootManager to dual and triple boot Haiku, Windows 7, and/or Linux:

https://discuss.haiku-os.org/t/dual-booting-haiku-and-window...

I have a laptop (Lenovo ThinkPad T410s) with Haiku, Linux Mint, and Devuan GNU/Linux. I use BootManager in the MBR, and it gives me a menu of all three to choose from. For the two Linux options, I have GRUB installed on each of their own partitions, so BootManager just sends me to the GRUB installed on whichever Linux partition. (Of course, this isn't exactly "replacing" GRUB altogether.)

I do it this way because I find dealing with BootManager to send me to individual GRUBs to boot a particular Linux partition much, much easier than fiddling with GRUB to boot Haiku.

(One last thought, parenthetical as I'm not sure it can even work from a USB drive: Worst case, you might make a USB "boot stick" that uses BootManager to choose between Haiku and Linux and let Windows do its jolly thing on the MBR?)

I tried to install the BootManager, but the limitations mentioned in the docs blocked the install. I think this part:

> BootManager isn't yet tested very well and still has a few restrictions that it will complain about if they aren't met: the menu can only be installed on your first harddisk and there has to be a 2KiB space after the Master Boot Record (MBR).

No idea how to create those conditions, the 2KiB space, and since I would have to do it with gparted in Linux anyway this made me install Linux instead first (with grub).

BootManager actually sounded nice - like you describe, I expected it to simply offer me the other OS(s) option(s), and I wasn't even set on installing Linux in the first place on that machine.

To your parenthesis: Yeah, I even had a boot manager on USB once for my PC, so it crossed my mind here, but for a travel laptop this would be a bit uncomfortable.

I thought the advent of UFEI would finally put GRUB to rest.

Worse, if you dual boot and each OS installs its own GRUB you can get all kinds of silly situations where one GRUB will chain load to another GRUB and then boot the OS.

Why not just hit F12 (or whatever) and UEFI gives you this nice little menu of all your boot options right there, before installers can come in and ruin it. (Like Windows that always seems to barge in and put itself on top trashing whatever you had before.)

Setting GRUB up with full-disk encryption and BTRFS snapshots is braindead easy. Maybe it'd be just as easy with Gummiboot or rEFInd, but you know what they say about fixing things that aren't broken.

What's the current state of the art on this? Last time I looked it was really not trivial, because of two things:

1) there is only one bootloader (grub2) that can load kernels from encrypted /boot partitions, but the support for that is limited, you have to use a weaker encryption if I remember correctly, AND decryption speed (after entering the luks password) is super slow, because the CPU extensions that speed that up (AES) are not yet online that early in the boot process

2) you can choose to not encrypt /boot, and have it as a separate partition, but now your btrfs snapshots will not include the kernel, so restoring after kernel upgrades is going to break your system

I am only really familiar with Arch and OpenSUSE, so I don't know how other distros do it, but OpenSUSE keeps the (I believe) latest 5 kernels, so I just have to delete snapshots older than the oldest kernel in my /boot. I like that system so I do the same thing on Arch (but don't tell anyone, otherwise I'm gonna get yelled at).

Doesn't deleting old kernels defeat snapshots? You do a system update, you get a new kernel, you delete the old ones, now all snapshots that depend on that older kernel are busted, what am I missing?

You may have misread, what I do is I keep the 5 latest versions of the kernel the distro ships and I delete snapshots which depend on kernels older than those 5. I could keep all the kernels and snapshots, but I don't have that much storage dedicated to / and /boot.

Check out Arch's wikipedia for plain dm-crypt.

It really is easy, it is just mostly a matter of proper initramfs, and a "linux" line in the GRUB configuration file. Arch wiki gets into it in detail.

I am perfectly fine with grub and os-prober.

Grub can't even boot my windows install. Maybe it's possible but after spending 4 hours on it I didn't feel like trying anymore.

`GRUB_DISABLE_OS_PROBER=false` ?

Doesn't work, no windows entry (I also ran sudo os-prober && sudo update-grub)

I don't get the hate. It just works for me, always has. And I have dual boot with encryption. It is such a small thing in the grand scheme of things.

Now compare that with booting on arm...

Not the parent, but I've spent enough time in the GRUB recovery shell trying to recover inexplicably corrupted GRUB installs even as recently as last year.

GRUB is shockingly fragile and painful to debug, though the recent movement on BLS hopefully will help with this.

> Grub is like a turd that won't flush. It's been completely unnecessary for years, is massively overcomplicated

shim + grub suck, but bare bones EFI sucks way more, generally speaking. Vendors of consumer-oriented EFI platforms ("client platforms") are batshit insane; they don't offer UEFI console redirection to/from the serial port even if the motherboard has one; they expose neither secure boot configuration nor boot options management to the user, and so on. A purely EFI-based boot loader such as systemd-boot or rEFInd remains the least annoying choice, IMO.

> completely unnecessary

Is it? How can you boot from encrypted volumes without it? I looked into systemd-boot, but I don't think it's capable.

What I don't understand is why GRUB needs to be regenerated every time you add a kernel or OS.

Make the bootloader smart enough to find read the underlying filesystems and find kernels. rEFInd does it. If I put in a bootable USB or install Windows on a second SSD, it just shows up on the menu without explicitly demanding it.

Maybe you have to say "/boot needs to be one of n well-supported filesystem types" but one-size-fits-most is probably good enough, relying on something GRUB for the people running ZFS-atop-RAID6-atop-a-collection-of-128-USB-floppy-drives.

I'm still waiting for a bootloader that will show up right from the beginning on my external monitor like my desktop + CRT monitor could do 20 years ago. systemd-boot (included with Pop!_OS) doesn't do that - so I have to actually take out my (Thinkpad X1 extreme) laptop from its stand and open it up to be able to switch between boot options; would be good to know people's experience with Grub on this front.

It's definitely a "you" problem. It works for me over a monitor connected via a docking station. I have tries pop os a while ago but it definitely worked.

My setup is as Linux friendly/vanilla as it comes; my laptop and dock are both Thinkpad and the monitor is Dell. Nothing exotic. It didn't even work when my monitor was directly connected via USB-C or HDMI so I guess I'm out of ideas about how it is a "me" problem.

If you go into your UEFI, does your external monitor work? As Linux drivers wouldn't be in play when GRUB is running.

I suspect it may depend on the monitor, not the bootloader. Some of them have a longer delay when turning on than others. My 4k connected over displayport has no problem, but my old VGA/DVI monitor that I use for homelab recovery cannot turn on fast enough.

Check your bios for primary display. If you manage to have the bios screen on the external display, it's very likely that the following bootloader will also use it. Works well on my ThinkPad+Dock.

Check the Thinkpad firmware settings to make sure the external monitor and/or dock GPU is the primary display which is effective during boot. On some PC's though you will then see nothing during boot on the laptop's own screen, sometimes even when the laptop is standalone. If Initial Graphics Device is set for "Auto" instead of a specific device, that may be OK but also may not be any different than you have now.

The external monitor may also have multiple inputs to choose from, like VGA, DVI, HDMI, which also might be set to "Auto" scan for which one is active, and that can sometimes take more time to succeed than it takes to boot. If so, using the Input Option settings on the external monitor you may be able to specify your preferred input connection exclusively, or as default, and then be able to see something during the time that it's blank now.

I respect the craft, and I have riced my distro, but theming my boot loader is the last thing I would waste time on.

I use my motherboard F8 menu to switch between Win11 and Arch boot loaders (so they can ignore each other, much simpler to maintain), so systems-boot appears only exactly 3 seconds to give me an opportunity to boot Linux-LTS instead of the last kernel version. And if I need to do anything fancy at boot time (eg: repair a borked boot config), I use a USB key with arch iso, and chroot into my install and then I have the full power of the command line.

I really really fail to see the point of spending hours to theme that.

What I'd like would be to have GRUB docs that are understandable enough for regular users and their use cases, rather than just eye candy. For example, right now most users start with a Windows install. What can they do if they want GRUB to handle a dual boot? (BTW, disabling os-prober due to security reasons might be the right call, but it's not helpful at all to newbies wishing to dual boot).

I am weary of GRUB and try to avoid it. The codebase is legendary for its inscrutability, bugs and performance issues abound and its configuration ritual is ridiculous.

And yet, it is king of bootloaders for a reason. It can frigging boot HannaMontanaBSD on an ENIAC. It can boot in UEFI mode, in BIOS mode, it is a chameleon that fits the hardware it is situated in. The devs have made a heroic piece of software.

Perhaps the inscrutability of the code and its issues are inevitable given the scope of the project. I don't know, I just wish we had a more sane codebase with GRUB's capabilities.

Love the concept of BSOL, might give that a try.

I only need/want the Beefy Miracle

https://major.io/p/bring-back-fedora-beefy-miracle-boot-spla...

The mustard indicates progress :)

Useful for dual boots, especially for beginners that get nervous when things don't look pretty.

Very timely. I’m currently in the middle of upgrading Ubuntu inside chroot to get a new version of grub that doesn’t have a bug with encrypted ZFS hoping it’ll fix my boot… Note to the universe: don’t touch ZFS with a 10 foot pole unless it’s your full time job to maintain storage clusters.

Personally... love it. Great for the people that want to flex this kind of aesthetic.

I had one from Distro Themes once in Manjaro up until one of heavy updates overwritten it with default theme.

Also, github gives me "You have exceeded a secondary rate limit" message while it's the first time I'm visiting it today. Yey.

https://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-b...

Very pretty. Is it still impossible to change the order of the boot list from inside grub?

Just like good ol installers, like the one made for C&C. When things had some soul.

I use and like rEFInd as my primary bootloader to dualboot Windows and Fedora.

Hackernews is obviously full of technical volks with need for encryption and what not, but I just like the macOS bootloader inspired looks that i could not replicate with grub.

Reply on news.ycombinator.com