Bugzilla – Bug 1223153
snapper fails to create a btrfs snapshot if --cleanup-algorithm is used
Last modified: 2024-04-23 11:44:23 UTC
snapper fails to create a btrfs snapshot if --cleanup-algorithm is used, with at least kernel versions 6.8.4 to 6.8.6 It appears that on all my OSses (openSUSE Tumbleweed, Debian Bookworm, both x86_64 and aarch64) this is the case. Recent discovery is after an zypper dup for a laptop which then installed the Tumbleweed kernel. Before the update, with kernel 6.8.1-1-default, no problem. Earlier bug report is with Tumbleweed rootfs on RK3588S hardware and Armbian provided kernel, see: https://forum.armbian.com/topic/37473-snapper-fails-to-create-a-btrfs-snapshot-if-cleanup-algorithm-is-used/ On Tumbleweed, snapper version is: # snapper --version snapper 0.10.7 libsnapper 7.4.0 flags btrfs,lvm,no-ext4,xattrs,rollback,btrfs-quota,selinux On Debian Bookworm flavor, snapper version is: # snapper --version snapper 0.10.4 flags btrfs,lvm,no-ext4,xattrs,rollback,btrfs-quota,no-selinux So far on the x86_64 laptop, I see in /var/log/snapper.log: 2024-04-18 18:48:26 WAR libsnapper(5811) Btrfs.cc(checkSnapshot):490 - CAUGHT: open failed path://.snapshots/536 errno:2 (No such file or directory) 2024-04-18 18:48:26 ERR libsnapper(5811) Btrfs.cc(createSnapshot):328 - create snapshot failed, btrfs_util_create_snapshot_fd2() failed, errno:2 (No such file or directory)
Thanks for the report... (In reply to slager from comment #0) > snapper fails to create a btrfs snapshot if --cleanup-algorithm is used, > with at least kernel versions 6.8.4 to 6.8.6 ... > So far on the x86_64 laptop, I see in /var/log/snapper.log: > 2024-04-18 18:48:26 WAR libsnapper(5811) Btrfs.cc(checkSnapshot):490 - > CAUGHT: open failed path://.snapshots/536 errno:2 (No such file or directory) > 2024-04-18 18:48:26 ERR libsnapper(5811) Btrfs.cc(createSnapshot):328 - > create snapshot failed, btrfs_util_create_snapshot_fd2() failed, errno:2 (No > such file or directory) At first glance it doesn't look like anything kernel related. Could you please provide your snapper configs? Are you only using snapper/zypper for snapshot management, or have you manually modified them via e.g. "btrfs subvolume ..."? CC'ing Arvin.
Already fixed, see https://github.com/openSUSE/snapper/issues/894.
(In reply to Arvin Schnell from comment #2) > Already fixed, see https://github.com/openSUSE/snapper/issues/894. OK, I was just typing a long story, but I'll read the github info and then I'll get it working again I think.
Oh, damn it, it's all my fault. The problem is I didn't take the qgroup disabled case into consideration. I'll fix the behavior, but I also very appreciate the fix from snapper side too.
OK, I was preparing/changing some script of mine doing all the hosts backup to remove the '1/0' from the root snapper config file, but maybe I'll limit it to just the hosts that need latest/custom kernel. I see that the script works on one online host, but quite some are offline (and/or run older distro kernel). I have disabled quotas, but for many hosts, I have copied some own template/config for snapper root filesystem from some new Tumbleweed install 2 years ago or so. I only tuned the cleanup times per host manually, did not touch the QGROUP lines. For some older hosts, I have no QGROUP line or it is set to "". So that clarifies those hosts run/backup without issues in the last days.