-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
grub-btrfs.path for timeshift is not working anymore #211
Comments
Hm since there are two timeshifts now (https://github.com/teejee2008/timeshift, https://github.com/linuxmint/timeshift) no one seemed to notice. But this breaking change is going to be introduced into the original version (the first link) sooner or later. |
There are some people complaining about the same problem: https://forum.manjaro.org/t/grub-doesnt-list-my-manual-btrfs-timeshift-snapshots-anymore/113618/5 As a temporary workaround, I am using this: #138 (comment) |
Yeah, I'm having this trouble too |
I confirm that the workaround proposed above works for me (in case, I've also blogged about that https://www.lorenzobettini.it/2022/07/timeshift-and-grub-btrfs-in-linux-arch/) |
Very nice guide! Although it doesn't work properly for me. In order for grub-btrfs to refresh the snapshots I must update grub. grub-btrfs doesn't automatically monitor the snapshots and update accordingly |
Fixed the above with this comment: #138 (comment) |
@JimPix1 |
I did. Obviously timeshift-autosnap will regenerate grub for me, but outside of autosnap, any other snapshots made don't appear unless you update grub |
Then grub-btrfs is not configured correctly.. |
It definitely is, You need a oneshot service to regenerate grub on shutdown or reboot in order for it to always update. Either that or do it yourself or just let timeshift-autosnap do it for you. Grub-btrfs does not regenerate grub for you. |
Ok, you have to update grub once and for all (so that the submenu for snapshots it's added) and then grub-btrfs simply automatically regenerates its submenu from then on, as soon as a snapshot appears in the configured directory. If that doesn't happen you have a problem in it's configuration. At least that's how it's supposed to work and how it works for me. |
Odd, it doesn't automatically regenerate it's submenu for me, and I didn't change the grub-btrfs configuration. |
That's the point: you have to change its configuration since, by default it looks for snapshots in |
Yes, I changed that already |
Then I wouldn't know.. as I said, it works for me |
I think the important information here is that the name of this directory in For OpenRC I simply watch |
Guys, I wanted to discuss a thing with you. Since we wrote that openrc daemon that is using inotify to fix this issue, I thought maybe we could use this daemon also for the systemd service, instead of depending on systemd mount units. So, basically have a look at that: https://github.com/Schievel1/grub-btrfs/tree/systemd-inotify
This service is now just starting a script as a daemon. And the daemon itself, which goes into /usr/bin: #!/bin/sh
# Copyright 2022 Pascal Jaeger
# Distributed under the terms of the GNU General Public License v3
# Update GRUB when new BTRFS snapshots are created.
timeshift_pid
watchtime=0
echo "im running" >> /home/pascal/daemontest
snapshots="/.snapshots"
timeshift_auto="true"
if ! [ "${#snapshots}" -gt 0 ] && ! [ ${timeshift_auto} ]; then
echo "Please specify the snapshots directory" >&2
exit 1
fi
if [ ${timeshift_auto} ]; then
watchtime=15
else
watchtime=0
fi
echo "entering while" >> /home/pascal/daemontest
while true; do
if [ ${timeshift_auto} == "true" ] && ! [ "${#timeshift_pid}" -gt 0 ] ; then
inotifywait -e create -e delete /run/timeshift && {
echo "pid: ${timeshift_pid}" >> /home/pascal/daemontest
echo "snapshots: ${snapshots}" >> /home/pascal/daemontest
sleep 1
timeshift_pid=$(ps ax | awk '{sub(/.*\//, "", $5)} $5 ~ /timeshift/ {print $1}')
snapshots="/run/timeshift/${timeshift_pid}/backup/timeshift-btrfs/snapshots"
}
else
while [ -d "$snapshots" ]; do
sleep 1
inotifywait -e create -e delete -e unmount -t "$watchtime" "$snapshots" && {
echo "got shot" >> /home/pascal/daemontest
sleep 5
if [ -s "${GRUB_BTRFS_GRUB_DIRNAME:-/boot/grub}/grub-btrfs.cfg" ]; then
/etc/grub.d/41_snapshots-btrfs
else
${GRUB_BTRFS_MKCONFIG:-grub-mkconfig} -o ${GRUB_BTRFS_GRUB_DIRNAME:-/boot/grub}/grub.cfg
fi
}
done
timeshift_pid=""
fi
done Keep in mind, this I just a quick draft to see if this works at all. The variables should later not be hardcoded of course. I also left the echos in there for debugging. If you want to test this out, change /usr/lib/grub-btrfs.service accordingly and put this script into /usr/bin and make it executeable. So if someone with more knowledge in systemd could help me out here (@Kr1ss-XD, @LorenzoBettini) :
|
To answer the second point: Apparently using the same config file is a no no.
So I have to make a file in /etc/systemd/system/grub-btrfs.service.d/grub-btrfd.conf where I override the ExecStart somehow. Well alright, I think I could at least reuse the daemon itself then |
I have got it working now - systemd now auto updates GRUB when I create or delete timeshift snapshots so I have created a guide to getting this configured correctly. Configuring systemd to update grub after modifying timeshift snapshotsNeither timeshift nor grub-btrfs will update your grub menu after you create or delete any snapshots so we have to manually configure systemd to do this for us, if we want the ability to boot directly into snapshots from GRUB. First, we must check the base path used to store your timeshift snapshots. Create at least one snapshot with timeshift and then run
We can see here that the path of the snapshot is systemd has a function called PathModified that we'll use to monitor
You must replace
To check systemd has registered the new mount point. Create
Edit (or create)
Now by enabling / starting
|
Glad you got it working now. it’s kind of a hack to make users fiddle around with their mount points in /etc/fstab. What do you think about my previous post, using the daemon we created for openrc with systemd? |
I'd not noticed your openrc solution before I had posted mine. A cross init solution would be good but my systemd solution is much simpler for systemd users to read and understand so I think I'll be sticking with my solution but I'd be tempted to switch to yours if it got more testing, dropped the debug statements and got included in grub-btrfs by default. I couldn't see where in @LorenzoBettini 's wiki guide for setting this up with systemd it ever called grub-mkconfig, which was the main reason it was never going to work on my system, apart from the base snapshot path being wrong for my OS (Debian Testing). You'll notice in my guide |
I am far from telling you what to do, but I think you can spare yourself the effort for that PR. I'm working on the daemon for both, systemd and openrc. |
You seem confident this repo isn't dead then? Did I miss anything from my revision of the systemd scripts? |
Apparently it isn't #217 |
@JimPix1 @danboid I can't tell you why the steps in my tutorial do not work for you... I'm using that in 4 installations (Arch and EndeavourOS), and they work perfectly. My suspect is that I'm using also timeshit-autosnap (as described in the tutorial)... maybe it works when timeshift-autosnap kicks in while it doesn't work if you create snapshots from the Timeshift GUI? Here's some log during an update, and you can see that the grub menu is correctly generated with the snapshot just created:
|
I am working on a daemon right now to watch for snapshots and triggering grub-btrsd instead of relying on systemd mounts and its almost finished. Maybe you want to give it a try. I put instructions into the PR, #218, for more instructions visit https://github.com/Schievel1/grub-btrfs/tree/update-daemon. |
grub-btrfs.path is not working anymore as /run/timeshift/backup is not used anymore to mount the snapshots directory, but rather a random numeric folder inside /run/timeshift, such as "/run/timeshift/35373/backup/"
It seems to be a change made by the Linux Mint team.
The text was updated successfully, but these errors were encountered: