Matter hook disabled on grub upgrade about matter HOT 10 CLOSED

Yeah, I can see that becoming troublesome.

I'll look for some other solutions.

from matter.

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.

from matter.

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.

from matter.

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.

from matter.

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.

from matter.

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? 😁

from matter.

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.

from matter.

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?

from matter.

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.

from matter.

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.

from matter.