Hi. What is the function of eos-grub-fix-initrd-generation.hook? Why did it get rid of my /etc/grub.d/10_linux and created a backup /etc/grub.d/10_linux.bak that is not the one I had before?
AFAIK, the purpose is to enable grub to correctly handle entries for EnOS and other distros that may work in the same way as Arch. Called when either grub OR os-prober is upgraded.
It will back up the existing grub file, after first removing any previously backup it might have made. If your backup used the same filenaming convention, it might well have removed yours.
Is there a problem in what you ended up with? Or just the question as above?
3 Likes
I see. What seems to have happened is that the new grub package overrode the 10_linux file in /etc/grub.d and then the hook backed up the new file instead of my file. So it was probably the upgrade of the grub package that got rid of my file. I thought that package upgrades didn’t replace files in /etc/ that have been manually modified. Am I right in my understanding? Does that not apply to the grub package?
The problem I’m having is that I want grub-mkconfig to generate a different output than the default one. I edited /etc/grub.d/10_linux so that the output I want is generated. But then pacman got rid of my file. The non-ideal solution I have now is that I backed up my /etc/grub.d/10_linux file so that if pacman overrides it, I have a copy to restore it. The ideal solution would be that pacman doesn’t override the file in the first place.
No, only files in a the backup array of the package work the way you describe.
Also, if that file is being modified by the hook, that also wouldn’t apply. Because then it is the hook making the changes, not the package manager.
Is there a way to modify the backup array externally, ie not as the package mantainer? For instance, from /etc/pacman.conf?
Well, if my reasoning is correct, that wouldn’t be a problem because the hook does indeed create a backup. It’s just creating the wrong backup, probably because the package manager modified the file before the hook was run.
Still, in the ideal situation, the hook wouldn’t override the file, at least not the part that I’m changing which is just 4 lines.
I don’t believe so, it is part of the package.
I don’t use grub but I just took a look at how that works. It looks like that hook is taking a backup before it makes it’s changes to that file. It isn’t generally creating a backup.
The real issue here is not the hook, it is the package itself which is overwriting that file.
That means that file isn’t intended to be edited by the user.
Can you explain what your modifications actually do so we can propose a solution to the problem?
2 Likes
Sure. I change the case in line 93 of /etc/grub.d/10_linux to
case $type in
booster)
title="$(gettext_printf "%s with booster initramfs" "${os}")" ;;
fallback)
title="$(gettext_printf "%s with fallback initramfs" "${os}")" ;;
recovery)
title="$(gettext_printf "%s in recovery mode" "${os}")" ;;
*)
title="$(gettext_printf "%s" "${os}")" ;;
esac
Since that file is owned by Arch grub package, not in the backup array and subsequently being modified by the EOS hook the best way is probably with a separate hook.
Create a hook that runs after the eos hook.
1 Like
IIRC an IgnoreFiles directive in pacman.conf would apply. I’m off my PC to verify, but I use such a method to skip installing man/help files for unused locales.
I am also not in front of that machine at the moment but I don’t see an option like that in the man file.
$ man pacman.conf | grep Ignore
IgnorePkg = package ...
IgnoreGroup = group ...
IgnoreFiles, there doesn’t seem to be… 
NoExtract
2 Likes
Great! Got it!
NoExtract = file …
All files listed with a NoExtract directive will never be extracted from a package into the filesystem. This can be useful when you don’t want part of a package to be installed. For example, if
your httpd root uses an index.php, then you would not want the index.html file to be extracted from the apache package. These files refer to files in the package archive, so do not include the
leading slash (the RootDir) when specifying them. Shell-style glob patterns are allowed. It is possible to invert matches by prepending a file with an exclamation mark. Inverted files will
result in previously blacklisted files being whitelisted again. Subsequent matches will override previous ones. A leading literal exclamation mark or backslash needs to be escaped.
In this case, that will only help partially since it won’t inhibit the hook. If the OP wants to use that method they will need to override the hook and have it call a modified script that doesn’t edit that file.
1 Like
Right, I get it!
Thanks for the clarification!
I guess our hack is hacked 
.
We have to assume that, since the user feels fine overriding hooks, he assumes full responsibility of his system’s state 
1 Like
I think this could work. Thanks @petsam!
I added to /etc/pacman.conf
NoExtract = etc/grub.d/10_linux
My hunch is that if the file isn’t updated by pacman, then the sed command executed in line 79 of /usr/bin/eos-grub-fix-initrd-generation wouldn’t change the file. Then _show_result will say 10_linux not changed.
I will report back when the hook is triggered in the next update of the kernel.
If you want to test it, you can just reinstall your current kernel.
That being said, the post transaction hook is still going to run because it is a package trigger.
That is why writing your own hook that puts your changes in is probably the most reliable solution.
The kernel was updated today, but the hook triggers only with the update of grub, grub-silent or os-prober, none of which was updated today.
So I run
sudo pacman -S grub
in the terminal to test it. And the output of the hook was
(2/4) Fix 'grub' and 'os-prober' after upgrading either of them.
===> INFO: grub-tools / grub-fix-initrd-generation:
===> INFO: /etc/grub.d/30_os-prober changed. See file /var/log/grub-fix-initrd-generation.log.
Error: file '/etc/grub.d/10_linux' from package 'grub' does not exist. Note: if you have used grub-customizer, you may need to reinstall grub, but be careful!
error: command failed to execute correctly
This wasn’t what I expected. I presume the NoExtract option is somehow making pacman remove the old file and not add the new. I expected it to keep the old file.