You are not logged in.
I read the message about "Latest News - Grub bootloader ...", and followed it of course last week.
Today came a further grub update
2:2.06.r322.gd9b4638c5-3 --> 2:2.06.r322.gd9b4638c5-4
but with the already known message again:
upgrading grub...
:: To use the new features provided in this GRUB update, it is recommended
to install it to the MBR or UEFI. Due to potential configuration
incompatibilities, it is advised to run both, installation and generation
of configuration:
$ grub-install ...
$ grub-mkconfig -o /boot/grub/grub.cfgQuestion: Do I have to re-run grub-install + grub-mkconfig now always after every grub update ?
Or was this a one-time hint for the specific version update step, and the hint is kept for users missed the 1st big grub update at 2022-08-30 ?
Last edited by ua4000 (2022-10-07 10:05:41)
Offline
The hint is there for every version at the moment, I'm not sure what they'll do at a later date, but it seems wise to prevent and recommend users that do mkconfig for xyz reasons to also do install on grub update.
Offline
Is it necessary to run these commands manually? Could these commands just be run from a hook?
Offline
Is it necessary to run these commands manually? Could these commands just be run from a hook?
Anything can be done with a hook.
The issue was not normal for several reasons, for starters, grub-mkconfig should™ have backwards support, that specific update was exceptional (that piece of code was changed already in a patch), but it could be considered an oversight.
Hooking up grub-mkconfig is also for specific scenarios (I'd imagine things like booting into btrfs snapshots), and doing so without also thinking about grub-install is a bit of a bad idea.
The big oof on this issue is typically all the spinoffs that have automagic grub-mkconfig but not grub-install, based on the assumption that it will always provide backwards support, or at least that it should™.
I personally just manage the configs by hand...
Offline
Ah okay. I can't exactly remember, but are you saying that the old hook only did grub-mkconfig without grub-install?
Now, given grub-install needs to be done first, these were removed from the official hook because the maintainers wouldn't be able to hard code the correct options? Then presumably if users know the options on their own systems, they can create their own hooks with these hard-coded in.
Offline
Ah okay. I can't exactly remember, but are you saying that the old hook only did grub-mkconfig without grub-install?
Now, given grub-install needs to be done first, these were removed from the official hook because the maintainers wouldn't be able to hard code the correct options? Then presumably if users know the options on their own systems, they can create their own hooks with these hard-coded in.
This is ArchLinux, there is no hook, all systems that where affected by the original issue either had a custom hook done by either the user, from the AUR, or where spinoff distros.
EDIT:
Apparently, grub-btrfs would regenerate the whole thing if grub-btrfs.cfg was not there, so there's a can of worms.
Last edited by GaKu999 (2022-10-07 01:29:17)
Offline
This is ArchLinux
I'm also using Arch, but I just checked the Arch Linux Archive, and I was wrong. I thought there was something that triggered this, but I must have mis-remembered. Actually, maybe I'm getting it confused with updating the kernel and initcpios.
Anyway I guess I'll just run the commands manually.
Offline
Recent changes in grub added a new command option to fwsetup and changed the way the command is invoked in the generated boot configuration.
That happened once, triggering this manual intervention. You better have done this *once* to align , afterwards it should™ not be required again.
Bootloader hooks are rather not an option, since not only is the installation very system specific, but the bootloader might be under control of a different system and the package only installed for tools/maintainance.
Offline
Recent changes in grub added a new command option to fwsetup and changed the way the command is invoked in the generated boot configuration.
That happened once, triggering this manual intervention. You better have done this *once* to align , afterwards it should™ not be required again.
Sorry, I don't entirely understand. Are you saying that we should only have needed to run these two commands once, and we shouldn't need to run them again for subsequent grub updates? i.e. as per the OP, these "hints" continue to be shown in case people missed the first hint?
Bootloader hooks are rather not an option, since not only is the installation very system specific, but the bootloader might be under control of a different system and the package only installed for tools/maintainance.
Thanks, that makes sense.
Offline
Basically yes. I'm assuming the newest update was made in order to drop the custom patch for allocating enough memory earlier that was used to fix certain faults on LVM/LUKS setups. If you use LVM/LUKS from within GRUB it might be beneficial to update GRUB itself again so you can benefit from the bigger memory allocation, but generally the config breaking change that hit most people has already happened and there should not be an explicit need to reinstall the GRUB loader again.
Offline
Thanks @V1del.
Having said that, I guess if I were to continually ignore the hint from now on, a future grub update might require those commands again. The "hint" would not be updated, and I wouldn't know to update. I wish there were some way to only trigger these "hint" hooks for the first update, but that doesn't appear to be simple.
Offline
There are various install scripts that do so via a version comparison, it's technically doable but since it's an install script this will be up to the packager to relevantly adjust.
Offline