Arch Linux User Repository

@racehd Ah, the daemon parts and snapshots "directory" in grub make sense, thanks! I don't think kernel/initramfs will be an issue for me, as I always use /efi for esp and no separate /boot partition (specifically so that kernel and initramfs in /boot are included in /@ snapshots). As for manual snapshots, I'd instinctively update grub after making one anyway.

For now I'll keep using grub-btrfs as I like the snapshots directory in the grub menu, and set updateGrub=false for timeshift-autosnap.

Hi @Karnage42. both timeshift-autosnap and grub-btrfs can trigger snapshots when doing a pacman upgrade, but beyond that the differences start. Grub-btrfsd is a daemon that can monitor a specified directory, multiple directories, or recursive directories for snapshots which would include if you ever ran any manual snapshots. If you don't need any of that then you could disable the grub-btrfsd (daemon). But grub-btrfs overall still offers functionality like adding the btrfs snapshots sub-menu in GRUB, and automatic detection of kernels, initramfs, and microcode within snapshots. I haven't tried uninstalling grub-btrfs completely but I imagine this would make it more difficult to use snapshots if you ever need to load from one.

Hello @racehd, thanks for maintaining this! Quick question (based on the README diff of the GitLab repo and the codeberg one): is grub-btrfs even necessary anymore if timeshift-autosnap is capable of the same output? Not that I am biased against grub-btrfsd, it's just a bit easier to maintain one fewer installed package and/or service.

@racehd, thank you for the suggestions. I've traced the problem to doas being symlinked to sudo. Long story short, this was my own doing. Timeshift-autosnap is not at fault.

@Mel, thanks for the logs. The error is coming from Timeshift when you run the timeshift --create command, not from timeshift-autosnap. The timeshift-autosnap project is at its core just a pacman upgrade hook that calls timeshift --create and monitors its exit code to determine if snapshots should be deleted.

• If Timeshift is returning exit code 1: timeshift-autosnap will abort before deleting old snapshots, and you'd need to manually manage them over time.

• If Timeshift is returning exit code 0: (and only dbus-launch is giving exit code 1) - then timeshift-autosnap would be working as expected, creating snapshots and deleting old ones. The error would just be cosmetic.

From your logs I do see an exit code 1 but its not clear to me if that is timeshift exiting with code 1, or the dbus-launch exiting with code 1 while timeshift still returns 0. Either way, this is an issue with either Timeshift or your setup's interaction with Timeshift. It's not something I can fix in timeshift-autosnap. I'd recommend asking in the Arch forums for help with the error since it feels to me like something is off with your system and the dbus-launch but I'm not familiar enough with it to know what. If you can confirm your system isn't the issue then I'd report it upstream to Timeshift.

You can find the output here:

pastebin(.)com/CvcGE1jA

Manually triggering snapshot creation outputs this:

pastebin(.)com/9mk9eDMN

@racehd I'm unfortunately away from my desktop pc where the issue occurs for the duration of the holidays. I'll update you as soon as I'm able.

@Mel I haven't seen that error before. What do you get from the following commands?

$ timeshift --version
$ dbus-launch --version
# systemctl status dbus
# journalctl -xeu dbus-broker.service

Also, does the error occur when you manually create a snapshot via timeshift CLI? ( # timeshift --create --comments "test" ).

Anyone else getting errors during Creating timeshift snapshot before upgrade such as 'Error spawning command line “dbus-launch --autolaunch=f0f3291a486b4cb682c1e0e12cbc7bbd --binary-syntax --close-stderr”: Child process exited with code 1'? Seemingly bogus, timeshift snapshots do get created as expected.