schnapps issueshttps://gitlab.nic.cz/turris/schnapps/-/issues2023-08-16T13:59:28+02:00https://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/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/16Handle non-alphanumeric characters in description2021-04-07T22:11:01+02:00Maciej Lenartowiczmaciej.lenartowicz@nic.czHandle non-alphanumeric characters in descriptionWhen `"` character is in description of a snapshot we get an error:
```
/usr/bin/schnapps: /mnt/.snapshots/31.info: line 3: syntax error: unterminated quoted string
```
or in `/var/log/messages` (when trying to use `foris-controller` to...When `"` character is in description of a snapshot we get an error:
```
/usr/bin/schnapps: /mnt/.snapshots/31.info: line 3: syntax error: unterminated quoted string
```
or in `/var/log/messages` (when trying to use `foris-controller` to get the list of snapshots`):
```
foris-controller[29181]: ERROR:foris_controller.message_router:Internal error occured <class 'json.decoder.JSONDecodeError'>('Expecting ',' delimiter: line 1 column 2386 (char 2385)')
```
Please see if other characters can break it. :)Turris OS 5.2.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/25Error message when there are no snapshots2020-09-16T10:51:04+02:00Vojtech MyslivecError message when there are no snapshotsOn a plain new system after medkit reflash:
```
root@turris:~# schnapps list
# | Type | Size | Date | Description
------+-----------+-------------+-----------------------------+---------------------...On a plain new system after medkit reflash:
```
root@turris:~# schnapps list
# | Type | Size | Date | Description
------+-----------+-------------+-----------------------------+------------------------------------
ls: /mnt/.snapshots/*.info: No such file or directory
```
We should suppress `ls` error output and probably add some error/warning message there are no snapshots present.Turris OS 6.0Michal HruseckyMichal Hruseckyhttps://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/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/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/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/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/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/49Rename snapshot identifier in json output from "number" to something more fit...2022-01-17T16:21:06+01:00Martin MatějekRename snapshot identifier in json output from "number" to something more fittingAFAIK Commit https://gitlab.nic.cz/turris/schnapps/-/commit/89952d49938aaa4ffdd0797ba347d8cc63a6fd3d is intended to fix turris/schnapps#47.
However in turn it broke [reading list of snapshots in foris-controller](https://gitlab.nic.cz/t...AFAIK Commit https://gitlab.nic.cz/turris/schnapps/-/commit/89952d49938aaa4ffdd0797ba347d8cc63a6fd3d is intended to fix turris/schnapps#47.
However in turn it broke [reading list of snapshots in foris-controller](https://gitlab.nic.cz/turris/foris-controller/foris-controller-schnapps-module/-/issues/10), thus breaking reForis snapshots page too.
>In listing snapshots, the snapshot number does not necessary need to
> be a number anymore, especially with remote snapshots. So let's put ti
> in quotes so it is always a string.
I see the reasoning behind the fix, but I wouldn't call it "number" anymore.
Based on its name, anyone could assume numeric value and try to validate it like number (actually as integer in foris-controller) or process it like number, which would fail on arbitrary string.
So I would suggest renaming it to "snapshot_id" or something more fitting.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/48sync doesn't work the way it's described2023-08-16T13:59:13+02:00theerrorsync doesn't work the way it's describedThe description of sync says, it should load all snapshots to remote location and should be readable by rlist. However it's not true.
It's more like "upload" or "export" then sync with remote location, but without .info file.
I had do...The description of sync says, it should load all snapshots to remote location and should be readable by rlist. However it's not true.
It's more like "upload" or "export" then sync with remote location, but without .info file.
I had download version of schnapps from one of [patch version](https://gitlab.nic.cz/turris/schnapps/-/raw/93e5a20f9daaa86b71156ca53c83ae955ea58331/schnapps.sh?inline=false), because of webdav fix.
Turris 1.0, TurrisOS 5.3.3
Usecase:
1. Download patched version
```
wget -q https://gitlab.nic.cz/turris/schnapps/-/raw/93e5a20f9daaa86b71156ca53c83ae955ea58331/schnapps.sh?inline=false -O schnapps.sh
```
2. configure webdav in /etc/conf/schnapps
3. Compare list of locations
```
root@turris:~# ./schnapps.sh list
# | Type | Size | Date | Description
------+-----------+-------------+---------------------------+------------------------------------
30 | post | 8.76MiB | 2021-11-13 18:59:16 +0100 | Automatic post-update snapshot
32 | time | 8.70MiB | 2021-11-21 01:05:03 +0100 | Snapshot created by cron
33 | time | 8.70MiB | 2021-11-28 01:05:03 +0100 | Snapshot created by cron
34 | time | 8.72MiB | 2021-12-05 01:05:04 +0100 | Snapshot created by cron
35 | time | 8.72MiB | 2021-12-12 01:05:03 +0100 | Snapshot created by cron
36 | pre | 8.72MiB | 2021-12-14 16:02:42 +0100 | Automatic pre-update snapshot
37 | post | 8.72MiB | 2021-12-14 16:02:54 +0100 | Automatic post-update snapshot
38 | time | 816.00KiB | 2021-12-19 01:05:02 +0100 | Snapshot created by cron
39 | pre | 288.00KiB | 2021-12-20 12:42:03 +0100 | Automatic pre-update snapshot
40 | post | 128.00KiB | 2021-12-20 12:43:10 +0100 | Automatic post-update snapshot
41 | pre | 128.00KiB | 2021-12-20 16:27:24 +0100 | Automatic pre-update snapshot
42 | rollback | 257.08MiB | 2021-12-20 21:57:27 +0100 | Rollback to snapshot 38
43 | pre | 160.00KiB | 2021-12-20 22:01:27 +0100 | Automatic pre-update snapshot
44 | post | 96.00KiB | 2021-12-20 22:02:32 +0100 | Automatic post-update snapshot
45 | pre | 144.00KiB | 2021-12-21 01:24:27 +0100 | Automatic pre-update snapshot
46 | post | 12.20MiB | 2021-12-21 01:39:15 +0100 | Automatic post-update snapshot (TurrisOS 5.3.3)
47 | single | 220.00KiB | 2021-12-21 18:45:19 +0100 | post upgrade TOC5
root@turris:~# ./schnapps.sh rlist
# | Type | Size | Date | Description
----------------------+-----------+-------------+---------------------------+------------------------------------
```
4. Run sync
```
root@turris:~# ./schnapps.sh sync -t time
./
./bin/
./bin/killall
./bin/vi
./bin/test
...
...
...
...
./.gnupg/random_seed
./var
./boot.scr
Current system was exported into /NetBackup/turris on webdav://xxxx.yyyyy.zz:5006/ as schnapps-medkit-20211222
```
5. Check results
```
root@turris:~# ./schnapps.sh list
# | Type | Size | Date | Description
------+-----------+-------------+---------------------------+------------------------------------
30 | post | 8.76MiB | 2021-11-13 18:59:16 +0100 | Automatic post-update snapshot
32 | time | 8.70MiB | 2021-11-21 01:05:03 +0100 | Snapshot created by cron
33 | time | 8.70MiB | 2021-11-28 01:05:03 +0100 | Snapshot created by cron
34 | time | 8.72MiB | 2021-12-05 01:05:04 +0100 | Snapshot created by cron
35 | time | 8.72MiB | 2021-12-12 01:05:03 +0100 | Snapshot created by cron
36 | pre | 8.72MiB | 2021-12-14 16:02:42 +0100 | Automatic pre-update snapshot
37 | post | 8.72MiB | 2021-12-14 16:02:54 +0100 | Automatic post-update snapshot
38 | time | 816.00KiB | 2021-12-19 01:05:02 +0100 | Snapshot created by cron
39 | pre | 288.00KiB | 2021-12-20 12:42:03 +0100 | Automatic pre-update snapshot
40 | post | 128.00KiB | 2021-12-20 12:43:10 +0100 | Automatic post-update snapshot
41 | pre | 128.00KiB | 2021-12-20 16:27:24 +0100 | Automatic pre-update snapshot
42 | rollback | 257.08MiB | 2021-12-20 21:57:27 +0100 | Rollback to snapshot 38
43 | pre | 160.00KiB | 2021-12-20 22:01:27 +0100 | Automatic pre-update snapshot
44 | post | 96.00KiB | 2021-12-20 22:02:32 +0100 | Automatic post-update snapshot
45 | pre | 144.00KiB | 2021-12-21 01:24:27 +0100 | Automatic pre-update snapshot
46 | post | 12.20MiB | 2021-12-21 01:39:15 +0100 | Automatic post-update snapshot (TurrisOS 5.3.3)
47 | single | 220.00KiB | 2021-12-21 18:45:19 +0100 | post upgrade TOC5
root@turris:~# ./schnapps.sh rlist
# | Type | Size | Date | Description
----------------------+-----------+-------------+---------------------------+------------------------------------
```
Listing of target folder:
```
dav:/NetBackup/turris/> ls
Listing collection `/NetBackup/turris/': succeeded.
Coll: old 0 Dec 22 00:57
*schnapps-medkit-turris-20211221.tar.gz 103378475 Dec 22 00:05
*schnapps-medkit-turris-20211222.tar.gz 103378786 Dec 22 01:08
dav:/NetBackup/turris/>
```
---
---
EXPECTED: Local and remote location are in sync, snapshots + .info
ACTUAL: Only one exported medkit file, nothing else, no .info for later import etc.https://gitlab.nic.cz/turris/schnapps/-/issues/47schnapps rlist -j produces invalid JSON2023-08-16T13:59:11+02:00Luca Beltrameschnapps rlist -j produces invalid JSONExample:
```json
schnapps rlist -j
{ "snapshots": [
{ "number": omnia-medkit-seldon-22, "type": "time", "size": "57.1M", "created": "2021-10-28 15:51:50 +0200", "description": "Pre-export snapshot" }
] }
```
The snapshot was created b...Example:
```json
schnapps rlist -j
{ "snapshots": [
{ "number": omnia-medkit-seldon-22, "type": "time", "size": "57.1M", "created": "2021-10-28 15:51:50 +0200", "description": "Pre-export snapshot" }
] }
```
The snapshot was created by:
```
/usr/bin/schnapps create -t time "Pre-export snapshot"
```
Then uploaded with
```
/usr/bin/schnapps upload $ID_OF_SNAPSHOT
```
In other words, the "number" for a remote snapshot is the full name, rather than simply 22. Thus the JSON produced is invalid.https://gitlab.nic.cz/turris/schnapps/-/issues/46using other root option throws ntfs errors2021-10-20T09:34:16+02:00th1j5using other root option throws ntfs errorsI tried to use schnapps instead of the lower-level btrfs tools to snapshot my (RAID) btrfs filesystem, by using the `-d root` option.
Then I get weird ntfs-3g errors...
```sh
root@turris:/mnt# btrfs sub list /mnt/DATA_NAS/
ID 256 gen 15...I tried to use schnapps instead of the lower-level btrfs tools to snapshot my (RAID) btrfs filesystem, by using the `-d root` option.
Then I get weird ntfs-3g errors...
```sh
root@turris:/mnt# btrfs sub list /mnt/DATA_NAS/
ID 256 gen 1570 top level 5 path @
ID 260 gen 29 top level 5 path @DATA_other
ID 261 gen 1572 top level 5 path @DATA_NAS
```
```
root@turris:/mnt# schnapps -d "/mnt/DATA_NAS" list
ERROR: unable to access /dev/sdb
/dev/sda: No such file or directory
ntfs-3g: Failed to access volume '/dev/sdb
/dev/sda': No such file or directory
ntfs-3g 2017.3.23 integrated FUSE 27 - Third Generation NTFS Driver
Configuration type 1, XATTRS are on, POSIX ACLS are off
Copyright (C) 2005-2007 Yura Pakhuchiy
Copyright (C) 2006-2009 Szabolcs Szakacsits
Copyright (C) 2007-2017 Jean-Pierre Andre
Copyright (C) 2009 Erik Larsson
Usage: ntfs-3g [-o option[,...]] <device|image_file> <mount_point>
Options: ro (read-only mount), windows_names, uid=, gid=,
umask=, fmask=, dmask=, streams_interface=.
Please see the details in the manual (type: man ntfs-3g).
Example: ntfs-3g /dev/sda1 /mnt/windows
News, support and information: http://tuxera.com
Can't mount root partition
```
It would be nice to use schnapps as a high-level tool, so if I can provide any other information, let me know.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/44SMB1 mounts are not supported2021-10-20T09:34:48+02:00Michal VasilekSMB1 mounts are not supportedTrying to mount a Synology NAS, I get this error:
```
mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Can't access remote filesystem
root@omnia:~# dmesg
...
[ 56...Trying to mount a Synology NAS, I get this error:
```
mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Can't access remote filesystem
root@omnia:~# dmesg
...
[ 5686.349245] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
```
Adding `-o vers=1.0` to the mount.cifs command fixes this issue for me. I think the defaults are correct now, maybe adding an option (with a warning) to use the 1.0 version or documenting this would make life easier for some people. If this is the default behavior of some (?) older (?) Synology NASes, this issue would be common.
Either way, I think this message in dmesg is logged even when the server supports SMB3, so it should probably be silenced with `-o vers=default`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/43Can not connect to remotes when the password contains special characters (:@+...2021-08-16T14:25:23+02:00Michal VasilekCan not connect to remotes when the password contains special characters (:@+\) with CLIThis can probably be solved by adding `-p <password>` and `-u <username>` options.This can probably be solved by adding `-p <password>` and `-u <username>` options.https://gitlab.nic.cz/turris/schnapps/-/issues/42schnapps cli should exit when given invalid arguments2022-03-15T17:05:08+01:00Michal Vasilekschnapps cli should exit when given invalid argumentsRunning `schnapps cleanup 10` or a different command with invalid arguments should fail with an exit code 1 and an error message. Otherwise, users might think that their command was correct and succeeeded, but only the valid part of it w...Running `schnapps cleanup 10` or a different command with invalid arguments should fail with an exit code 1 and an error message. Otherwise, users might think that their command was correct and succeeeded, but only the valid part of it will be executed.
For example users might expect `schnapps cleanup 10` to leave 10 most recent snapshots, the 10 argument will be silently ignored.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/41Lock file is left in /tmp in rescue SSH shell2021-08-13T09:34:29+02:00petrcechLock file is left in /tmp in rescue SSH shellSchnapps do not remove LOCK directory in `/tmp` when started in rescue mode 5.
The reason is missing `rmdir` command in busybox.
----------------------------------------------------
Zdravím,
při startu MOXe a režimu 5 - ssh na 192.168...Schnapps do not remove LOCK directory in `/tmp` when started in rescue mode 5.
The reason is missing `rmdir` command in busybox.
----------------------------------------------------
Zdravím,
při startu MOXe a režimu 5 - ssh na 192.168.1.1 nemaže schnapps LOCK-adresář v /tmp.
Příčinou je chybějící rmdir příkaz v busyboxu. "Testováno" po pokusu aktualizovat pár balíčku v Turris 6.0 a následném zamrznutí.
rm -rf je podporováno
PetrMichal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/40Support Samba2021-07-22T09:11:15+02:00Michal HruseckySupport Samba