Matter hook disabled on grub upgrade

[mateosss]

Matter adds to the end of the /usr/sbin/grub-mkconfig script a call to itself so whenever the grub is updated (on a new kernel installation for example) matter can overwrite grub.cfg to put the icon classes in place.

However when the grub itself is upgraded, grub-mkconfig is overwritten effectively removing the Matter hook at the end, and you as an user need to "install" Matter again for keeping the correct icons.

One solution that comes to mind would be to place the hook on the package manager instead. With apt something like this would be needed. A problem with this approach is how to gracefully handle other package managers.

Hopefully there are other alternatives that you can come with. Any ideas are welcomed.

[nik-gautam]

I do have an alternative solution, but there a few issues I am facing.

So, instead of placing a hook to package manager itself, we can watch the shell commands which are being executed, which we can do watching files like bash_history or zsh_history.

When a command like sudo apt upgrade or sudo dnf upgrade is executed, we can if check grub version is upgraded or not, if upgrade we execute a re-install script for Matter or re-write whatever previously written on grub-mkconfig.

Problems with this approach:-

• So, by this, we'll know a system upgrade is started but not when it ended. So, our script will be running while the upgrade is underway, during that time grub version wouldn't have increased from last time. Hence, the re-install script won't be executed.
• We'll also need to add support for different shells like zsh, fish, etc.

[mateosss]

Something that bothers me as well with that solution is having Matter read every command the user issues to his system. I don't know if that level of intrusion and use of resources is justifiable for a grub theme.

Also you will need to account for every possible way of upgrading the grub. Is he using apt, apt-get, aptitude, dpkg, pacman, rpm, dnf, guix, and so on.

[nik-gautam]

Yeah, I can see that becoming troublesome.

I'll look for some other solutions.

[nik-gautam]

How about we run a systemd service at shutdown? We check if the changes in grub-mkconfig are there, if not we put them there.

This might slow down the shutdown a little bit, I am not sure about this.

Excuse me, if I sound a bit noob, very new to grub.

[mateosss]

That's definitely a better approach, but not quite enough yet I think.
While I don't know the possibilities of systemd, having a theme execute something every time the user shuts down their machine may still be a bit annoying. Imagine if a bug was introduced in matter that interfered with the shutdown process, I personally wouldn't be very happy.

An idea that comes to mind now that may lead to something is to dive into what happens when the grub is upgraded. It would be reasonable to think that maybe package managers execute a particular script from grub when upgrading it, like a post-upgrade hook that resides in the grub files itself and is not bound to a particular package manager.

[mateosss]

Something that may turn out to be very useful to tackle this issue, is to find an easy way to reproduce this problem. We'll not be able to implement this if we can only test if it works during real grub upgrades, will we? 😁

[nik-gautam]

Testing will certainly be painful...

Ok, I did some research i.e. a few google searches, and I found this article, according to which we can add scripts directly to update-grub command.

But again, similar problem, if something goes wrong it might mess up the bootloader, which will be very bad.

Also, comments on this stack exchange also mention a few useful tips.

[mateosss]

Ok, I did some research i.e. a few google searches, and I found this article, according to which we can add scripts directly to update-grub command.

I completely ignored these types of scripts for some reason. For what I understand everything that those files throw at stdout with echo or cat will be written into grub.cfg. If we add a script that doesn't write to stdout it should be totally safe. If additionally we make it run the same command that is currently placed at the end of grub-mkconfig, it might be able to survive grub package upgrades. We need to be sure this executes after all entries have been added to grub.cfg as well.

Could you check if these ideas are correct? It may be a solution to this issue if upgrades don't delete our script.
Also we still need a way to test if this works, maybe uninstalling and reinstalling grub on a VM?

[mateosss]

On a recent apt upgrade, I found the packages that replaced /usr/sbin/grub-mkconfig (in Lubuntu 18.04, I assume the same is true for many other distros with grub):

• grub-common
• grub-pc
• grub-pc-bin
• grub2-common

Everytime I tried to upgrade just one, apt will tell me it would upgrade the others.

[mateosss]

Solved in latest v1.1.0 release

It was implemented with the idea of the grub scripts in /etc/grub.d/.
It turns out that grub upgrades do not delete those scripts so now there is one there that checks whether grub-mkconfig has been reverted and if so puts the hook back onto it.