I have a custom Grub2 theme that accommodates both my tastes and my need to actually read what’s on my 4k screen.
Any time there is an update involving grub, my theme directory gets deleted. This is wholly unnecessary, and makes it pointless that the script run as part of the grub update kindly backs up [FONT=fixedsys]/etc/default/grub. The only reason for performing this backup is so users can merge [/FONT]/etc/default/grub.old[FONT=arial] back into the new version, run [/FONT][FONT=fixedsys]grub2-mkconfig, and easily restore any lost customization, which can’t be done if the customizations pointed to in [FONT=fixedsys]grub.cfg have been casually zapped.
Yes, I could (and do) keep a tarball of my theme, but I’m human and I forgot to update it with my latest changes. Frankly, I shouldn’t have to: updating grub like this effectively kills the grub theming feature as it’s meant to operate.
This is stupid, and a fix merely requires some scripting that isn’t totally half-arsed.
I can’t find a public bug tracker on the site where I can raise this formally: is there one?
Can anyone suggest which package is likely doing this? I don’t know a huge amount about rpm development, but I suspect I don’t need to in order to contribute a workable fix on this one. If all else fails ‘cp -r /boot/grub2 /boot/grub2.old’ before anything else happens should at least achieve the minimal objective of not discarding what a rational user would want to keep, and would do so, if not elegantly, at least without wreaking wholesale destruction.
How to I submit such a patch when done?
[/FONT]
[/FONT]