FS#57949 - [grub] ships non-trivial and incorrect grub.cfg
Attached to Project:
Arch Linux
Opened by Eli Schwartz (eschwartz) - Sunday, 25 March 2018, 12:36 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 27 November 2018, 21:52 GMT
Opened by Eli Schwartz (eschwartz) - Sunday, 25 March 2018, 12:36 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 27 November 2018, 21:52 GMT
|
Details
The grub 2 package installs a /boot/grub/grub.cfg file that
seems to have maybe been generated on the then-packager's
machine, and is completely unfit for any and all use.
(Directing grub to boot a nonexistent UUID obviously does
not work). The justification seems to be that it is "needed
in order to create a backup entry" but this is simply untrue
as many packages do not install a backup entry for
configuration files the user is supposed to create
themselves...
It then compounds the problem by performing configuration for the user that will never be used and does not add any utility, storing the results of a trivial automated script in a grub.cfg.example file when the user is *quite* capable of running the same script by hand after reading the excellent documentation. Also if one has a grub.cfg they created themselves prior to installing grub, and also had a .pacsave file (seems like an odd case but I can imagine it happening when cloning a disk and deciding to switch *back* to grub after it was previously used) it will overwrite that configuration and not even clean up the .pacsave afterwards. I'm not aware of any other packages which attempt to restore pacsave files on their own, and for good reason.... This seems needlessly convoluted as a workaround for pacman creating pacsave files due to a conf file that should never have been packaged in the first place... The result is a system that *cannot* work by default. This result is difficult and annoying to debug, as the grub.cfg file superficially appears to be correct, but will spawn weird error messages like "error: no such device: ad4103fa-d940-47ca-8506-301d8071d467" and make people wonder where on earth this UUID came from (answer: some Dev's build machine from 6 years ago). This all produces magic effects rather than putting the user in charge of their system. The packaged configuration file should be removed, the backup file should be removed from the backup array, and users should be warned to restore or generate their own config as god intended. :p This results in *no* additional work for users (neither for advanced users nor for clueless users), a simplified packaging process, and as a bonus avoids explicitly throwing value-added confusion at users who did not read carefully enough. See for example https://bbs.archlinux.org/viewtopic.php?id=235519 (although this has been bothering me for some time.) |
This task depends upon
Closed by Christian Hesse (eworm)
Tuesday, 27 November 2018, 21:52 GMT
Reason for closing: Fixed
Additional comments about closing: grub 2:2.02-8
Tuesday, 27 November 2018, 21:52 GMT
Reason for closing: Fixed
Additional comments about closing: grub 2:2.02-8
```
# compat cfg to prevent renaming peoples' existing configs to .pacsave
echo "please create your own grub.cfg"
false
```
This would not overwrite peoples' modified grub.cfg, but makes it fairly obvious why the bundled one does not work.
...
I wonder if there is some way to disassociate pacman backup files with a package ahead of time...
EDIT: nah, it looks like it just deletes the file altogether, so it is either package a stub, or back up the grub.cfg to grub.cfg.preupgrade and restore it in post_upgrade.
EDIT: Actually, this should really trigger for any upgrade no matter what the previous version of grub was. So version 2 of the patch checks for any previous version older than the prospective 2:2.02-6