Friendly reminder that grub-mkconfig generates unnecessarily complicated grub.cfg files and that they can be as simple as this (which allows me to boot custom kernel, default kernel with initrd, and Windows):
default=0
timeout=3
menuentry 'Custom Kernel' {
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt6'
echo 'Loading Linux 5.10.172zeus ...'
linux /boot/vmlinuz-5.10.172zeus ro quiet rootfstype=ext4 root=/dev/sda6
}
menuentry 'Devuan GNU/Linux, with Linux 5.10.0-21-amd64' {
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt6'
echo 'Loading Linux 5.10.0-21-amd64 ...'
linux /boot/vmlinuz-5.10.0-21-amd64 root=UUID=a788be97-7ba6-4c15-ad6e-e91d38604c39 ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-5.10.0-21-amd64
}
menuentry 'Windows Boot Manager' {
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 4828-3FFF
else
search --no-floppy --fs-uuid --set=root 4828-3FFF
fi
chainloader /efi/Microsoft/Boot/bootmgfw.efi
}
Man I miss good old GRUB, which I guess is called GRUB legacy now? Most entries only required 4-5 lines of config and there was no ugly shell syntax, a million options, conditionals etc.
Probably just because I grew up with it, but MBR and disk/boot management on Linux was so much simpler back then.
512 bytes of partition table + bootloader(well, the bootstrapping part anyway). Partitions had one simple, 3 character name in /dev. No weird FAT32 partitions full of mysterious files, UEFI stuffed full of unnecessary features, but you can be damn sure a desktop or laptop board is gonna provide all the ones that make your life harder, and none of the actually useful ones.
I'm sure there are lots of good technical reasons why everything needs a UUID now, and so on and so forth, but none of all this complexity solved any problem I actually had in the before times. It just added the problem of now having to read a buttload of documentation every time I even think about touching this stuff.
At some point a few years back, I wanted to switch DNS servers on my laptop running some ubuntu derivative at the time. resolv.conf was still there, so I edited it. Nothing happened. Eventually I ended up finding like 4 different files in various places specifying DNS. And only one was the right one to change. Others might do nothing or actually break DNS.
One of these days I'll probably throw up my hands, put my mobo in legacy mode, and install some bare bones, Systemd free distro. Maybe Crux Linux or Slackware if those even exist still.
I'm using Slackware-current with manually maintained [edit: actually, I wrote a python script to generate it, see other comment] grub.cfg (grub 2.06) on a MBR system, and happy I don't have GPT. Recently I tried to convert a Windows installation from MBR to GPT. What a disaster, never doing that again (but if you do need to, use gdisk [1]. It's great, I had unrelated issues). I suppose I'll eventually have to convert my Linux PC to GPT when replacing the motherboard. I haven't ever reinstalled Slackware (I just upgrade), since switching to it in 2007. Honestly there are issues with that.
Slackware just celebrated its 30 year anniversary two days ago [2] and still going strong without systemd ;) Well actually it now has eudev, which is the small unintrusive part of systemd which a lot of software these days has as a dependency. Everything is still done with rc files. Best of both worlds.
At the risk of sounding silly, the move to systemd and the headaches encountered, such as you describe, are the very reason I left my brand new system which could work well for Linux, including the graphics card, as a single boot windows machine.
It just wasn't worth the headache on top of having to keep windows for work (many programs don't have a Linux option nor do they work properly in wine etc, and vm isn't reasonable for gpu intensive operations like video editing).
IMHO, systemd really messed up the ecosystem and the "Trust" value that Linux in general had built with me.
Aside from the complexity of the autogenerated configuration file, is there any benefit to maintaining it yourself? I recall when I used to have a Windows partition, the 'update-grub' script included with Debian would find all kernels (including custom ones) and other OSes as well.
I'd much rather have to maintain nothing rather than something.
Ditto, I'm not really worried about the complexity of my GRUB config - just that it works. It tends to if I don't go poking/looking directly at it.
Leaving them to manage the config has worked a-okay for me, even with a cmdline that would cause shudders in most. grubby has been a frustrating introduction
If I were to invest any effort in my bootloader at all, it would be to get closer to the 'metal' through systemd-boot/efibootmgr
TLDR: looking at the GRUB config invokes a "why am I still doing this" emotion, I'd rather not
Well I wish I didn't have to, but I ended up writing a small python script [1] to generate my grub.cfg boot entries (After 8 years I've forgotten many of the reasons for doing so). At least it's clearly inspectable and I can make customisations that won't be erased by regeneration. For example my root partition is a btrfs subvolume, but how does grub know which subvolume I want mounted as the root? The current one I assume, but what about my backup root on my HDD which isn't mounted? Or which alternative kernels in /boot?
> I'd much rather have to maintain nothing rather than something.
The pain point is that when you can't boot for some reason, grub2 is significantly harder to reason about and fix than classic grub, lilo, systemd-boot, and so on.
The only thing I don't like is your render distance is drastically limited. Under Linux I can only set it to 12 (I believe), whereas in Windows I can go all the way out to 51 if I so choose (which is useful when looking for end cities).
Minecraft has made this a bit confusing, but there are two completely independent implementations of minecraft, the java edition and the bedrock edition. The poster above you was referring to the bedrock edition for linux.
* The java edition has always had a fairly limited render distance, although recently they split render distance and simulation distance into separate options which allows for higher render distance than in the past. (There are also mods like bobby, but it wouldn't help you find end cities: https://www.curseforge.com/minecraft/mc-mods/bobby)
* Bedrock edition, designed to be capable to run on mobiles, has the ability to run very high render distances on pc.
There are launchers on Flathub and Lutris for playing Bedrock Edition on Linux, but at the end of the day it was originally called Minecraft Windows 10 Edition.
I get the ideals are on point, but it doesn't look like the place to campaign about it.
Hopefully the author doesn't have any anxiety or issue about politely saying "The issue description doesn't look to me like a bug in my code." and closing it.
I agree that that’s a bit annoying but it is normal to use the Issues tab for feature requests and things like that. I guess that’s why it’s called Issues instead of Bugs
Maybe a bit off topic, but does anyone know about themes or GUIs for LUKS password entry? The command line version has pretty unintuitive behaviour for family members which are used to modern GUIs.
Ah, by GUI I assumed you meant something good indeed booted for hunting things like homes. For during the boot process for mounting an encrypted root, a TUI using something like dialog (https://invisible-island.net/dialog/dialog.html#screenshot and commonly available in Linux distributions standard repositories) would probably be more suited. IIRC it is what Debian use for their text installer. It should be pretty light weight, though it is still something you are scripting and adding to initramfs yourself so there may be more pre-made options that require less manual maintenance.
I misread this as "Microsoft Grub Theme" and was definitely interested in the irony. This is super fun, though, and impressive. I didn't know you could do all this in a grub theme.
It would be a pretty fun project to write a CPU software rasterizer that works in UEFI… (Obviously GPUs are out of the question, but it might be possible to use multiple CPU cores)
Just scrolling a panorama along would probably look good enough
I think the real game uses a cubemap so the camera is inside a cube with six textured faces which I guess should be easy enough to render if you wanted to do it properly
Is that even possible in Grub? Last time I checked there was a tool called "Burg" that would animate backgrounds like a gif, but otherwise it was very clunky and not a great experience.
GRUB is a common bootloader for Linux systems: it gives you a menu of boot options when you turn on your machine, and boots whichever installed operating system you choose.
So with this theme, that menu for choosing which OS to boot looks like the Minecraft menu!
GRUB is a bootloader. A bootloader takes care of getting the operating system started up. It is also responsible for allowing the user to select between multiple operating systems at boot.
