schnapps issueshttps://gitlab.nic.cz/turris/schnapps/-/issues2023-10-16T09:58:41+02:00https://gitlab.nic.cz/turris/schnapps/-/issues/55Schnapps doesn't display snapshot sizes2023-10-16T09:58:41+02:00Lukas JelinekSchnapps doesn't display snapshot sizesSchnapps doesn't display anything in the **Size** column. Originally from [our forum](https://forum.turris.cz/t/turris-os-6-4-3-is-released/19376/29).Schnapps doesn't display anything in the **Size** column. Originally from [our forum](https://forum.turris.cz/t/turris-os-6-4-3-is-released/19376/29).Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/schnapps/-/issues/37btrfs instruction not supported on TurrisOS 5.2.12023-08-16T14:00:43+02:00Mikebtrfs instruction not supported on TurrisOS 5.2.1`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on ...`➜ ~ btrfs sub show -ruh /srv
ERROR: uh is not a valid numeric value.
➜ ~ btrfs sub show -ru /srv
ERROR: u is not a valid numeric value.
➜ ~ btrfs sub show -uh /srv
ERROR: can't find uuid '6d650000-a875-5100-2000-000000000000' on '/srv'
[1] 22243 illegal hardware instruction btrfs sub show -uh /srv
➜ ~ btrfs sub show -u /srv
btrfs subvolume show: exactly 1 argument expected, 0 given
`https://gitlab.nic.cz/turris/schnapps/-/issues/50Readonly snapshots2023-08-16T14:00:39+02:00Jip-HopReadonly snapshotsIt looks like schnapps creates writable snapshots. Why is that? Would all schnapps features still work if read-only snapshots would be made instead?
Schnapps features look great, especially the `rollback` command! I'd like to use it for...It looks like schnapps creates writable snapshots. Why is that? Would all schnapps features still work if read-only snapshots would be made instead?
Schnapps features look great, especially the `rollback` command! I'd like to use it for my Debian home server with btrfs root filesystem (data is stored on ZFS disks). Possibly combined with [grub-btrfs](https://github.com/Antynea/grub-btrfs) to boot into snapshots. But booting into a writable snapshot made by schnapps would modify its contents, which could mess up the last known working state of the system. I think that's why e.g. `snapper` doesn't create writable snapshots by default.
Would it be possible to make read-only snapshots the default? Or if that's incompatible with some features, add a parameter to create readonly snapshots instead?Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/51Local sync2023-08-16T14:00:38+02:00Adam UhlířLocal syncSchnapps seems very powerful but I am missing one feature that would make it in my eyes complete.
I would like to sync Schnapps's snapshots onto another **local** harddrive.
My use case is that I have BTRFS RAID1 with HDD that works ...Schnapps seems very powerful but I am missing one feature that would make it in my eyes complete.
I would like to sync Schnapps's snapshots onto another **local** harddrive.
My use case is that I have BTRFS RAID1 with HDD that works as "cold" storage and then another USB flash drive where I have all the LXC containers, logs etc. as I am trying to minimize spinning the HDDs as they are close to my bed and they make ugly noise 😅 I understand that sooner or later the USB flash drive will die so I want to back it up to the HDD from time to time and Schnapps would be perfect for this task except that it can't sync locally.
I am planning to try to work around this by SSHing to localhost, but I would say that this feature should be supported natively.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/52schnapps -d /srv with zstd compression leads to periodical load average of 30+2023-08-16T14:00:34+02:00Orest Worhaczschnapps -d /srv with zstd compression leads to periodical load average of 30+Hi,
I am using msata drive formatted with Storage Plugin and I have chosen in Luci to mount it with:
```
/dev/sda2 on /srv type btrfs (rw,noatime,nodiratime,compress=zstd,ssd,space_c
ache,subvolid=743,subvol=/@)
```
While it was working...Hi,
I am using msata drive formatted with Storage Plugin and I have chosen in Luci to mount it with:
```
/dev/sda2 on /srv type btrfs (rw,noatime,nodiratime,compress=zstd,ssd,space_c
ache,subvolid=743,subvol=/@)
```
While it was working it was working but I think that using schnapps on such a system leads to load average range 30+ in some cases and the system becomes totally unresponsive. Cannot even login via ssh.
I was wondering that its acctually doing something so I let it be that much loaded and at some point it went down to load average 5+ and I could login and see htop and netdata and the cpu was at 50% and according to netdata it was used by 'system'. But later on it went back to unresponsive state and dropped ssh connection.
I had this problem before as it lead me to invalid snapshots half-made as the router just hang in the middle of creating a snapshot. So I taken out the drive connected it via adapter to my laptop. Deleted all btrfs subvolumes except @ and recompressed all files with btrfs defrag and connected it back and it was all again around 1-4% cpu usage.
Before I also tested that taking out the drive from Omnia also fixed this extreme load. With the drive unresponsive, without just fine.
So I request to test schnapps with btrfs compressed drives as all problems begin when I try to do some schnapps operation like creating or deleting the snapshot.
Thanks!Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/53Race condition when trying to delete two snapshots at once2023-08-16T14:00:32+02:00Michal VasilekRace condition when trying to delete two snapshots at onceAfter deleting a lot of snapshots at once in Reforis, some of the snapshots I deleted no longer exist and don't have a size, but are still shown in `schnapps list`. I can reproduce this with plain schnapps by running two `delete` command...After deleting a lot of snapshots at once in Reforis, some of the snapshots I deleted no longer exist and don't have a size, but are still shown in `schnapps list`. I can reproduce this with plain schnapps by running two `delete` commands at once, so I think the protection against multiple concurrent runs is not correct.
```
root@turris:~# schnapps list
# | Type | Size | Date | Description
------+-----------+-------------+---------------------------+------------------------------------
1 | single | 16.00KiB | 2022-08-19 22:11:15 +0200 | User created snapshot
3 | single | 16.00KiB | 2022-08-19 22:13:04 +0200 | User created snapshot
4 | single | | 2022-08-19 22:13:05 +0200 | User created snapshot
5 | single | 16.00KiB | 2022-08-19 22:13:16 +0200 | User created snapshot
6 | single | | 2022-08-19 22:13:16 +0200 | User created snapshot
7 | single | 16.00KiB | 2022-08-19 22:13:17 +0200 | User created snapshot
10 | single | | 2022-08-19 22:13:19 +0200 | User created snapshot
11 | single | | 2022-08-19 22:13:20 +0200 | User created snapshot
12 | single | 16.00KiB | 2022-08-19 22:13:20 +0200 | User created snapshot
13 | single | 16.00KiB | 2022-08-19 22:13:21 +0200 | User created snapshot
14 | single | | 2022-08-19 22:13:22 +0200 | User created snapshot
19 | single | | 2022-08-19 22:13:26 +0200 | User created snapshot
20 | single | | 2022-08-19 22:13:27 +0200 | User created snapshot
43 | pre | | 2022-07-19 11:19:55 +0200 | Automatic pre-update snapshot (TurrisOS 6.0)
48 | post | | 2022-08-11 18:56:15 +0200 | Automatic post-update snapshot (TurrisOS 6.0)
root@turris:~# schnapps delete 48
WARNING: Snapshot number 48 does not exists!
```
`schnapps delete` should either delete the snapshots properly or not delete them at all.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/54Remote user not respected with sshfs2023-08-16T14:00:30+02:00Michal HruseckyRemote user not respected with sshfsSetting user in config doesn't change the username tried when mounting via sshfs.Setting user in config doesn't change the username tried when mounting via sshfs.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/14Make `schnapps diff` default to diffing the latest two snapshots when argumen...2023-08-16T13:59:58+02:00Vojtech MyslivecMake `schnapps diff` default to diffing the latest two snapshots when arguments are missingMoved from [github #2](https://github.com/CZ-NIC/turris-schnapps/issues/2) by [TomasHubelbauer](https://github.com/TomasHubelbauer)Moved from [github #2](https://github.com/CZ-NIC/turris-schnapps/issues/2) by [TomasHubelbauer](https://github.com/TomasHubelbauer)https://gitlab.nic.cz/turris/schnapps/-/issues/11Consistency checking and fixing2023-08-16T13:59:56+02:00Lukas JelinekConsistency checking and fixingMetadata about snapshots is currently saved in `*.info` files. In some circumstances, these files need not to be consistent with the snapshot `btrfs` subvolumes. For example, there are `*.info` files without the pertaining subvolumes. Th...Metadata about snapshots is currently saved in `*.info` files. In some circumstances, these files need not to be consistent with the snapshot `btrfs` subvolumes. For example, there are `*.info` files without the pertaining subvolumes. These files are listed as "snapshots" but `schnapps` can't do anything with them (each attempt fails with a non-explaining error message). And there is no way (other than low-level manual cleanup) how to fix it.
I think that schnapps should provide solution for this. There are two possible ways:
1. Before each operation, a consistency check/repair is executed.
2. `schnapps cleanup` enhancement (consistency checking and fixing before removing old snapshots)
The first way is more comfortable but may lead to delaying of operations.https://gitlab.nic.cz/turris/schnapps/-/issues/10[feature suggestion] provide PARTUUID as designation for ROOT_DEV2023-08-16T13:59:54+02:00Ghost User[feature suggestion] provide PARTUUID as designation for ROOT_DEVIf the system is booted from another drive other than the eMMC the `ROOT_DEV` has to be changed but is currently limited only to the `/dev/sdX` designation set by the kernel, which in case of multiple hard drives being connected could va...If the system is booted from another drive other than the eMMC the `ROOT_DEV` has to be changed but is currently limited only to the `/dev/sdX` designation set by the kernel, which in case of multiple hard drives being connected could vary.
`u-boot` provides `root=PARTUUID=` which makes it independent of the kernel's `/dev/sdX` designation and thus I trust it would be handy for `schnapps` being able to set the `ROOT_DEV` with `PARTUUID=` as well.https://gitlab.nic.cz/turris/schnapps/-/issues/23Incorrect processing of SSH upload URL2023-08-16T13:59:51+02:00Lukas JelinekIncorrect processing of SSH upload URLIf a path is a part of an SSH upload URL it is incorrectly processed.
### Steps to reproduce
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use for up...If a path is a part of an SSH upload URL it is incorrectly processed.
### Steps to reproduce
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use for upload. Don't jail the user inside his home directory (the problem isn't dependent on this situation but it's necessary to define the test conditions well).
2. Login to your Turris and try to upload some snapshot, e.g. `schnapps 311 ssh://192.168.1.200/srv/turris`
### Expected results
The snapshot is uploaded into `/srv/turris` on the given machine.
### Actual results
The snapshot is not uploaded at all. `schnapps` fails to mount (*read: Connection reset by peer*) and then creates the snapshot tarball in the local directory (`/mnt/.remote-snapshots`) despite of no remote filesystem is mounted on it.Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/schnapps/-/issues/22Absolute SSH upload path treated as relative2023-08-16T13:59:48+02:00Lukas JelinekAbsolute SSH upload path treated as relativeIf an absolute upload path for SSH is specified it is treated as relative.
### Steps to reproduce:
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use ...If an absolute upload path for SSH is specified it is treated as relative.
### Steps to reproduce:
1. Prepare an SSH-capable machine, create a directory on it (e.g. `/srv/turris`) a set permissions to write for the user you want to use for upload. Don't jail the user inside his home directory.
2. Login to your Turris and try to upload some snapshot, e.g. `schnapps 311 ssh://192.168.1.200 /srv/turris`
### Expected results:
The given snapshot is uploaded to `/srv/turris` on the given machine.
### Actual results:
If `/srv/turris` doesn't exist under the default working directory after logging in (usually the home directory) it fails with *"Export takes target directory as argument!"*. If the directory exists under the default working directory the snapshot is uploaded into it which is unexpected/unwanted behavior.Lukas JelinekLukas Jelinekhttps://gitlab.nic.cz/turris/schnapps/-/issues/20Handle sub-subvolumes correctly2023-08-16T13:59:45+02:00Karel KociHandle sub-subvolumes correctlyTop level subvolume can contain additional subvolumes (such as created by LXC). Schnapps does not handle them correctly. The main problems are as follows:
* [ ] When snapshot is created those subvolumes are left out. That causes rollback...Top level subvolume can contain additional subvolumes (such as created by LXC). Schnapps does not handle them correctly. The main problems are as follows:
* [ ] When snapshot is created those subvolumes are left out. That causes rollback to remove LXC containers or in other words to remove that snapshot all together.
* [ ] When snapshot with subvolumes in it is being removed it can't be because it is not empty (it contains other subvolumes) (issue https://gitlab.labs.nic.cz/turris/schnapps/issues/17)Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/17It is not possible to remove rollback snapshot if it contains other subvolumes2023-08-16T13:59:40+02:00Karel KociIt is not possible to remove rollback snapshot if it contains other subvolumesCurrently we create rollback snapshots by moving existing `@` to rollback one. The problem is that if there are some subvolumes created inside we move those as well. These subvolumes are kept in that snapshot which can be even considered...Currently we create rollback snapshots by moving existing `@` to rollback one. The problem is that if there are some subvolumes created inside we move those as well. These subvolumes are kept in that snapshot which can be even considered correct but such snapshot can't be removed simply by `btrfs subvol delete` because it reports that snapshot is not empty.
We should instead of rollback possibly do just plain snapshot and drop subvolumes or possibly remove snaphosts recursively.
Just to point out how those snapshots were created. LXC creates snapshots so it is enough to run LXC on schnapps managed drive to reproduce this.Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/15[-d root] should override configuration (ROOT_DEV)2023-08-16T13:59:36+02:00Ghost User[-d root] should override configuration (ROOT_DEV)`schnapps -d /dev/<root partition>` works as expected when the node is booted to the default */dev/mmcblk0p1* but it does not when booted to an USB partition (maybe also SSD but could not test since *u-boot* GPT support is not implemente...`schnapps -d /dev/<root partition>` works as expected when the node is booted to the default */dev/mmcblk0p1* but it does not when booted to an USB partition (maybe also SSD but could not test since *u-boot* GPT support is not implemented).
When booted to an USB partition (interior USB 2.0 with MBR) the root path specified with `-d` is entirely neglected and *schnapps* only deals with the current root partition.
Curiously however, manipulating */etc/schnapps/config* with `ROOT_DEV="/dev/<root partition>"` works as expected when booted to an USB partition.
Tested with HBS | HBD | Master and reproduces reliably on each installation.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/27LOCK-folder handling not correct2023-08-16T13:59:33+02:00MarkusLOCK-folder handling not correct**Describe the bug**
Any local user can prevent schnapps from starting.
If schnapps is started without proper authorization a LOCK folder is created anyway.
However, this will not be deleted again.
This causes all following starts ...**Describe the bug**
Any local user can prevent schnapps from starting.
If schnapps is started without proper authorization a LOCK folder is created anyway.
However, this will not be deleted again.
This causes all following starts of schnapps to fail.
A reboot or manual deletion of the folder is necessary
**To Reproduce**
$ sudo -u nobody schnapps
'''
ERROR: not a valid btrfs filesystem: /
ERROR: unable to access : No such file or directory
mount: only root can use "--options" option
Can't mount root partition
'''
'# schnapps list
'''
mkdir: can't create directory '/tmp/schnapps.lock': File exists
Another instance seems to be running!
'''
**Expected behavior**
schnapps cron-job starts despite the single start of another user
**Environment**
OS: Turris-OS 5
Snapshot version: 2.3-1 (also checked actually git version )Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/34Turris 1.x routers - can not rename @factory and there is no statsfs2023-08-16T13:59:28+02:00Josef SchlehoferTurris 1.x routers - can not rename @factory and there is no statsfsWhile trying to use `schnapps import` on Turris 1.x routers, it says:
```
mv: can't rename '/mnt/.snapshots/@factory': No such file or directory
ERROR: Could not statfs: No such file or directory
Your factory image was updated!
```
Howe...While trying to use `schnapps import` on Turris 1.x routers, it says:
```
mv: can't rename '/mnt/.snapshots/@factory': No such file or directory
ERROR: Could not statfs: No such file or directory
Your factory image was updated!
```
However, it works, but the output is confusing. Can you please take a look at it?
This happens on Turris OS 3.x, but I am sure that this happens on newer versions as well.Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/32Fix info file naming upon import2023-08-16T13:59:26+02:00David HopfmuellerFix info file naming upon import**Current behaviour:** Upon import, schnapps prepends a `@` to the info file's name, e.g., `@19.info` (`@19` is the subvolume's name). This makes it 'invisible' to schnapps, e.g., `schnapps list`.
**Expected behaviour:** A file name of ...**Current behaviour:** Upon import, schnapps prepends a `@` to the info file's name, e.g., `@19.info` (`@19` is the subvolume's name). This makes it 'invisible' to schnapps, e.g., `schnapps list`.
**Expected behaviour:** A file name of `19.info`.
This issue was reported in the [forum](https://forum.turris.cz/t/schnapps-import-does-not-work/14474). Patch !15 should rectify it.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/19Add auto rollback functionality with reboot (savepoint and commit)2023-08-16T13:59:22+02:00Karel KociAdd auto rollback functionality with reboot (savepoint and commit)After some discussion with @ljelinek I come up with idea to have automatic rollbacks with restart. The functionality would be that you could call something as `schnapps savepoint` (optionally setup reboot with some timeout) and do config...After some discussion with @ljelinek I come up with idea to have automatic rollbacks with restart. The functionality would be that you could call something as `schnapps savepoint` (optionally setup reboot with some timeout) and do configuration that could potentially cut you from router. When all goes correctly then user could call `schnapps commit` to discard savepoint.
The use case is to simply make remote management even more resilient against breakage without even needing someone to go to location and rollback router using button. Also it is easier to explain router restart (just pull power out and plug it back in) than rollback to other people.
The implementation details would be that schnapps would simply move current root (`@`) to snapshot (same as it is done with rollback) and marked it by new type `savepoint`. In place of `@` new read-write snapshot from original `@` would be created. With reboot router would boot to old version of system while new one would be now old savepoint snapshot. `commit` operation would do flip of new and old root back. That means that with commit savepoint snapshot would become old version of system and current root would become again `@`. It might be beneficial to instead of introducing just `savepoint` snapshot type to introduce two new types instead. `savepoint` for the committed save point and something like `savepoint-rollback` for original root that was not committed and rollback with reboot occurred because of that.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/33Add command to know version of schnapps2023-08-16T13:59:19+02:00Josef SchlehoferAdd command to know version of schnappsI noticed that there is no way how I can check version of schnapps in command-line interface. I can figure it out by opkg, but there should command in schnapps e.g. `schnapps --version` to know which version I have installed. This can be...I noticed that there is no way how I can check version of schnapps in command-line interface. I can figure it out by opkg, but there should command in schnapps e.g. `schnapps --version` to know which version I have installed. This can be useful while testing this binary in CI and current test inside Docker container is that it tries to use:
```
schnapps --version
schnapps -version
schnapps version
```
But it didn't found the version. For example, pkgpdate provides such opinion.
```
root@omnia:~# pkgupdate --version
pkgupdate 69.0.0
```Michal HruseckyMichal Hrusecky