[kelnos]

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.

[bravetraveler]

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

[versteegen]

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

[rodgerd]

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

[costco]

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