Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ronald van Haren (pressh)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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
Comment by Ronald van Haren (pressh) - Sunday, 25 March 2018, 14:30 GMT
Removing that file will leave numerous people with a broken system. You simply cannot assume that all people with read an install message that they will need to restore their grub config. I don't think there is a good solution here, but please correct me if I'm wrong.
Comment by Eli Schwartz (eschwartz) - Sunday, 25 March 2018, 14:36 GMT
I'd like to say they should read the message, but the alternative would be to keep shipping a stub file that simply says

```
# 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.
Comment by Eli Schwartz (eschwartz) - Sunday, 25 March 2018, 15:06 GMT
This seems to work fine.

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

Loading...