Errors on 4.13

[bkmo]

Getting an error using 4.13 with Timeshift on Arch Linux when updating packages with pacman.
`

Found 9 snapshot(s)
Unmount /tmp/grub-btrfs.31Urx8N2pw .. Success
cannot open `/boot/grub/grub.cfg.new': No such file or directoryUsage: /usr/bin/grub-script-check [OPTION...] [PATH]
Try '/usr/bin/grub-script-check --help' or '/usr/bin/grub-script-check
--usage' for more information.
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.

I seem to only generate this error with grub-btrfsd.service running. Could the service be triggering an update at the same time that pacman's hook is running? This did not happen on the 4.12 version scripts.

EDIT: Replacing the 4.13 /usr/bin/grub-btrfsd with the 4.12 version cures the error.

Also for what it is worth, the version number in the config file of 4.13 is:
GRUB_BTRFS_VERSION=4.12-master-2023-04-28T16:26:00+00:00

[Schievel1]

Hi,

what are you using as 'pacman's hook' exactly? Is this generating the grub config itself?

[bkmo]

I use the hook from timeshift-autosnap. It creates a snapshot when there is a package upgrade.

[Trigger]
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Creating Timeshift snapshot before upgrade...
Depends = timeshift
When = PreTransaction
Exec = /usr/bin/timeshift-autosnap
AbortOnFail

And yes it is setup to work with grub-btrfs. See this part of the script:

if $(get_property "updateGrub" "boolean" "true") && [ "$(pacman -Qs ^grub-btrfs$)" ]; then
    grub-mkconfig -o /boot/grub/grub.cfg
fi;

[bkmo]

So as you can see timeshift-autosnap runs timeshift to create a snapshot and I think it interferes with the grub-btrfsd daemon . I did not have an issue on the 4.12 version of the daemon script. I could always configure timeshift-autosnap to not update grub I guess. This works perfectly except that timeshift-autosnap defaults to updating grub if grub-btrfs is installed.

[Schievel1]

hm yes, the grub-btrfs.service is watching for the new snapshots and triggers grub-mkconfig when there is a new one.
At the same time tirmeshift-autosnap triggers grub-mkconfig itself, which interferes witch each other, it seems.

But then again, I wonder why is it not finding /boot/grub/grub.cfg.new.

[bkmo]

But then again, I wonder why is it not finding /boot/grub/grub.cfg.new.

I have no clue what is causing this.
Disabling timeshift-autosnap from updating grub solves the interference with the grub-btrfs.service. Maybe just a note in the readme that this has to be done if using timeshift-autosnap. I have seen many tutorials that recommend the combination of Timeshift, Timeshift-autosnap and grub-btrfs.

[bkmo]

From what I can see the script grub-btrfsd of 4.13 is supposed to only create the submenu via 41_snapshors-btrfs but is creating the entire grub menu via grub-mkconfig. Here is the output of the service status. Also why are there 2 tasks running for /usr/bin/grub-btrfsd? The difference between the 2 scripts is that 4.13 runs grub-mkconfig and 4.12 runs 41_snapshots-btrfs as it should.

4.13 version of script:

     CGroup: /system.slice/grub-btrfsd.service
             ├─ 538 bash /usr/bin/grub-btrfsd --syslog -t -v
             ├─ 554 bash /usr/bin/grub-btrfsd --syslog -t -v
             └─9534 inotifywait -e create -e delete /run/timeshift

Jun 13 13:57:48 Thinkpad460s grub-btrfsd[555]: Subdaemon function started, PID: 554
Jun 13 13:57:48 Thinkpad460s grub-btrfsd[557]: 554: Entering infinite while for timeshift
Jun 13 13:57:48 Thinkpad460s grub-btrfsd[560]: 554: Snapshot dir watchtimeout: 15
Jun 13 14:00:23 Thinkpad460s grub-btrfsd[2486]: 554: detected Timeshift startup, PID is: 2400
Jun 13 14:00:23 Thinkpad460s grub-btrfsd[2487]: 554: new snapshots directory is /run/timeshift/2400/backup/timeshift-btrfs/snapshots
Jun 13 14:00:24 Thinkpad460s grub-btrfsd[3137]: Grub menu recreated
Jun 13 14:08:00 Thinkpad460s grub-btrfsd[7052]: 554: new snapshots directory is /run/timeshift//backup/timeshift-btrfs/snapshots
Jun 13 14:08:01 Thinkpad460s grub-btrfsd[7703]: Grub menu recreated

This is from 4.12 grub-btrfsd

CGroup: /system.slice/grub-btrfsd.service
             ├─268290 /bin/sh /usr/bin/grub-btrfsd --syslog -t
             └─269323 inotifywait -q -q -e create -e delete /run/timeshift

Jun 13 11:47:56 Thinkpad460s grub-btrfsd[268293]: grub-btrfsd starting up...
Jun 13 11:48:39 Thinkpad460s grub-btrfsd[268779]: detected Timeshift startup, PID is: 268738
Jun 13 11:48:39 Thinkpad460s grub-btrfsd[269155]: Grub submenu recreated
Jun 13 11:48:40 Thinkpad460s grub-btrfsd[269314]: detected timeshift shutdown

[bkmo]

Ok, it seems the detection of the submenu fails on the 4.13 script, but not on the 4.12.

4.12:

if [ -s "${GRUB_BTRFS_GRUB_DIRNAME:-/boot/grub}/grub-btrfs.cfg" ]; then
        if /etc/grub.d/41_snapshots-btrfs; then
			log "Grub submenu recreated" "${GREEN}"

4.13

 if grep "snapshots-btrfs" "{grub_directory}/grub.cfg"; then
    	  if  /etc/grub.d/41_snapshots-btrfs; then
		        log "Grub submenu recreated" "${GREEN}"

[bkmo]

Ok I have narrowed it down to the "{grub_directory}/grub.cfg. If I hardcode the grub directory as /boot/grub/grub.cfg then the script will run the 41_snapshots-btrfs as it can now grep the grub.cfg file. So this seems to work for me. I'm not sure if it is the best way to do it though.:

if grep "snapshots-btrfs" "${GRUB_BTRFS_GRUB_DIRNAME:-/boot/grub}"/grub.cfg; then
    	  if  /etc/grub.d/41_snapshots-btrfs; then
		        log "Grub submenu recreated" "${GREEN}"

I have added a PR for this.....feel free to correct it as you see fit.

[Schievel1]

Also why are there 2 tasks running for /usr/bin/grub-btrfsd?

In 4.13 you can watch several directories for new snapshots.
grub-btrfsd does this by forking itself for every directory it should watch. See also https://en.wikipedia.org/wiki/Fork%E2%80%93exec

[bkmo]

Also why are there 2 tasks running for /usr/bin/grub-btrfsd?

In 4.13 you can watch several directories for new snapshots. grub-btrfsd does this by forking itself for every directory it should watch. See also https://en.wikipedia.org/wiki/Fork%E2%80%93exec

I am curious why it is forking a second task in --timeshift-auto mode?

[Schievel1]

One of those tasks is the parent process. This one is not watching a directory. It just keeps living because it is waiting for the termination signal (e.g. when you run systemctl grub-btrfsd stop). If it catches the signal it terminate all the child processes and then exit.

The other process is the actual watching. You can see this because only one of those processes spawned a innotifywait process. This is the process that actually watches the directory.

They are both in timeshift auto mode because that is what the parent process was started with. The parent actually doesn't need this other than start it's child processes with that option.

I don't know why systemd is displaying this so weirdly. Maybe pstree does a better job

[bkmo]

Thanks for the explanation, I was curious and now I get it.

[jfabernathy]

This fix seems to have solved my similar problem with the combination of grub-btrfs and timeshift-autosnap-apt on Debian 12.

[oscarfzs]

Hello,
I'm someone who has been using grub-btrfs and timeshift-autosnap, and I've been getting this problem. But not only do I get the /boot/grub/grub.cfg.new not found errors, I also had the issue listed in this post: https://forum.endeavouros.com/t/timeshift-snapshot-problem-message-asking-to-restore-all-the-time/21534

The fix was, as was mentioned in this thread, to disable timeshift-auto's updating of the grub menu.

The thread on the endeavouros forum was posted back in December of 2021, before grub-btrfs 4.12 was released.

[bkmo]

The message of restoring the snapshot is baked into Endeavouros. It happens when you boot from a snapshot. This is not a grub-btrfs issue. Setting up timeshift-autosnap to not update grub should fix the issue described here.

[oscarfzs]

The message of restoring the snapshot is baked into Endeavouros. It happens when you boot from a snapshot. This is not a grub-btrfs issue. Setting up timeshift-autosnap to not update grub should fix the issue described here.

I know the message is part of endeavour, I was just saying that when timeshift-autosnap and grub-btrfsd both try to update the grub menu at the same time, it would not only spit out that error which you posted in your first comment, but afterwards trying to restore a snapshot and rebooting would cause the system to boot right back into the snapshot, even if the user did not go into the grub menu and select it. This side effect is not specific to endeavouros.

This isn't a grub-btrfs issue, I get that.

[jfabernathy]

Let me see if I understand this current issue with timeshift and grub-btrfs.

The recommended way to use on a Debian/Ubuntu system is to following the manual build instructions for grub-btrfs which include installing inotify-tools, and then modify the grub-btrfsd.service to include the --timeshift-auto option instead of /.snapshot.

After enabling and starting grub-btrfsd.service you can add timeshift-autosnap-apt but you need to edit /etc/timeshift-autosnap-apt.conf to set the parameter: updateGrub=false

This allows grub-btrfsd.service to update grub without any conflict with timeshift-autosnap-apt.

Does this sound correct?

[bkmo]

It conflicts with timeshift-autosnap for sure, but that is on Arch with pacman package manager. I have no idea what happens with the apt version, but your understanding of the issue is correct. The grub-btrfsd.service and timeshift-autosnap are both running grub-mkconfig at the same time.

[jfabernathy]

I can confirm that on Debian 12 that if I edit /etc/timeshift-autosnap-apt.conf and change updateGrub to false. I no longer get errors when I run sudo apt upgrade. I see the snapshots in timeshift and if I reboot I see the new snapshot in the grub list of available snapshots.

[Schievel1]

I will make a short note in the readme about this

[Cubuss]

im having the same error i got a pacman hook script to update initramfs i alsol have timeshift-autosnp installed

Found 8 snapshot(s)
Unmount /tmp/grub-btrfs.xrS6RBqqDz .. Success
cannot open `/boot/grub/grub.cfg.new': No such file or directoryUsage: /usr/bin/grub-script-check [OPTION...] [PATH]
Try '/usr/bin/grub-script-check --help' or '/usr/bin/grub-script-check
--usage' for more information.
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.
:: Processing package changes...

here is my hook :

`[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
Target=nvidia
Target=nvidia-dkms
Target=linux-zen
# Change the linux part above and in the Exec line if a different kernel is used

[Action]
Description=Update NVIDIA module in initcpio
Depends=mkinitcpio
When=PostTransaction
NeedsTargets
Exec=/bin/sh -c 'while read -r trg; do case $trg in linux) exit 0; esac; done; /usr/bin/mkinitcpio -P'
`

[Cubuss]

Let me see if I understand this current issue with timeshift and grub-btrfs.

The recommended way to use on a Debian/Ubuntu system is to following the manual build instructions for grub-btrfs which include installing inotify-tools, and then modify the grub-btrfsd.service to include the --timeshift-auto option instead of /.snapshot.

After enabling and starting grub-btrfsd.service you can add timeshift-autosnap-apt but you need to edit /etc/timeshift-autosnap-apt.conf to set the parameter: updateGrub=false

This allows grub-btrfsd.service to update grub without any conflict with timeshift-autosnap-apt.

Does this sound correct?

i did the same and it seem to work now with auto-snap correctly

[jgdub]

set updateGrub to false and I am good again.... Not sure i understand what changed that make these two not coexist anymore.

[Absolutely-Free]

This is really a rather nasty bug that has rendered two different systems of mine unbootable because I didn't notice these errors popping up during updates. I am aware this is my fault, but it was not obvious what the issue was until I did some investigating. The readme file should really mention that if you are combining grub-btrfs and timeshift-autosnap, you must set updateGrub to false in /etc/timeshift-autosnap.conf or else your GRUB can wind up mangled and your system made unbootable unless you manually run grub-mkconfig -o /boot/grub/grub.cfg (on Arch, or whatever the equivalent is on other distros) before your next reboot/shutdown.

[tmm360]

I don't think to avoid to regenerate grub is an optimal solution. Grub should be always updated as soon as possible with real existing snapshots. Otherwise trying to boot on a snapshot could try to invoke a no more existing once (maybe because it has been pruned), or an existing and potentially useful snapshot could not be listed.

[Absolutely-Free]

I don't think to avoid to regenerate grub is an optimal solution. Grub should be always updated as soon as possible with real existing snapshots. Otherwise trying to boot on a snapshot could try to invoke a no more existing once (maybe because it has been pruned), or an existing and potentially useful snapshot could not be listed.

According to @Schievel1 earlier in this thread:

hm yes, the grub-btrfs.service is watching for the new snapshots and triggers grub-mkconfig when there is a new one.

grub-btrfs is also updating GRUB, it is just happening in the background. Problems occur when both timeshift-autosnap AND grub-btrfs are set to update GRUB because they are both trying to update it at the same time. Disabling the auto update functionality in timeshift-autosnap is just allowing grub-btrfs to handle the updating of GRUB.

A more ideal long term solution though would be to automate this process by integrating a check into either grub-btrfs or timeshift-autosnap (or both) that prevents them from stepping on each other's toes. Requiring manual intervention when both are installed is a pretty serious footgun.

[tmm360]

@Absolutely-Free I see your point, but timeshift manage snapshots itself, and for example in my case each hour it creates a new snapshot, manages labels and removes old ones. These changes wouldn't be reported on grub configuration.

Long term solution looks good.

[undefined-landmark]

I'd like to add that an absent mind during a pacman update also left one of my systems unbootable. Recovery was fine with an arch usb. For now I edited my timeshift-autosnap.conf, but it would be ideal if these programs worked together like they used to do for the last number of months. I'm willing to do some testing if that's helpful in any way.

[Schievel1]

They never worked together. That they did get into each others way was completely coincidental

[undefined-landmark]

I might've been a bit too quick with my reply. Timeshift and grub-btrfs work well together. The issue is mainly with timeshift autosnap, a combination which grub-btrfs is not explicitly targeting. I'll probably just switch out timeshift autosnap for scheduled timeshift backups as a permanent "fix".

[Migsi]

What issue does the related PR exactly tackle? I've implemented that one manually, but didn't notice any change. The original problem only got away after disabled updateGrub to false as stated above. Is there a plan on how to go forward with this?

[Schievel1]

These are two issues here. One is fixed by this PR, it is about how the configuration values are loaded into the environment of the grub-btrfsd daemon. Before this PR and with version 4.13 we were sometimes running into problem that the configuration could not be aquired and then we would not have the path where grub.cfg is stored.

The other problem is that sometimes grub-btrfsd tries to update grub at the very same time like something else is. This would create a race condition and therefore errors out. There is no fix for this other than not running grub-mkconfig twice by different programs simultaneously.