(no title)
ftaghn | 2 years ago
Are you referring to this? https://archlinux.org/news/grub-bootloader-upgrade-and-confi...
This isn't the first time, and won't be the last time, something like that happens with grub, and it's entirely an issue with the user not doing what they should when they run archlinux or some other minimalist distribution that doesn't automate the process of updating grub.
Grub uses a configuration file generator that reads from the human readable/editable /etc/default/grub and creates a /boot/grub/grub.cfg, and the result of that generator doesn't have a stable "interface". At any time, an update to grub might read grub.cfg incorrectly, if you do not generate it again.
99% of the linux distributions out there had no breakage with grub because they run the grub-mkconfig command every time grub is updated through grub-install. It is automated within the scripts included in the packaging of the distribution and the user will never see any of this in Debian, Ubuntu, Fedora etc. If a newer grub package comes out on those distro, the scripts will run both grub-install and grub-mkconfig. There will never be a mismatch between the grub binary versions and the config file state.
Arch Linux users who knew how grub works also had no issue. If you update grub, you must regenerate the config file (it's a "if you update" because arch linux, by default, will NOT automatically update grub at all, updating the package is not the same as updating grub). If you edit the config file and regenerate it when you have a newer grub package installed, you must also update the grub binaries. So any time you do something with grub, you MUST run grub-install, then grub-mkconfig. Doing only one of the two is akin to doing a partial upgrade, which is a no-no.
If, as I suspect, you're an arch user, I would recommend switching to systemd-boot, which doesn't even need a configuration file at all if you set up your system to follow its conventions and use unified kernel images. EFI binaries are automatically scanned and shown in the menu and it uses EFI variables to remember the few settings you can interactively edit, like the preferred kernel to boot. It's robust and only has what is needed in a small, KISS boot manager. It can't even be truly called a boot loader because that part is managed by efistub which is part of the unified kernel image. Very unlike grub, which has the whole kitchen sink, including its own implementation of a ton of filesystems..
errantmind|2 years ago