Hacker News new | ask | show | jobs
by costco 1068 days ago
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
    }
2 comments

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.

[1] http://www.rodsbooks.com/gdisk/mbr2gpt.html

[2] https://www.patreon.com/posts/thirty-years-86196804 (There's nothing on the website or announce mailing list)

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?

[1] https://gist.github.com/rversteegen/32bb0b2786ee1092762627f0...

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

There's not really any benefit, I was just surprised that after deleting most of the lines it still worked.