The snapshots are on the same device that has the current root. If /dev/sda1 is your root then your snapshots are on /dev/sda1. You can even browse these snapshots if you mount the device without subvol=@. schnapps is a simple frontend for btrfs snapshots and subvolumes.
The link is created with ln -s @/boot/boot.scr boot.scr in the real root of the filesystem.
I don’t think so. First they are trying something schnapps was probably never designed to do. Second there are some assumptions about the used root subvolume that is named @. schnapps is a simple frontend to btrfs snapshots and does its job great but was never meant as a generic snapshot manager.
History and background as seen by me
root on SSD was not designed to be used as root device. SSD was meant to be used as /srv for LXC and other data. This is a much simpler use case and works like a charm. Minimized writes on MMC and you got all your data with speed. This is the way the system is designed and works.
There was no real need for root on SSD back then apart from running debian or other Linux distributions. My motivation for root on SSD was to allow me to run ArchLinux on my Omnia.
The original work for TurrisOS was done later. These threads are a bit about the motivation for others.
It was about destroying data or having enough space for opkg install '*'…
[SOLVED] - Extroot - (expanding Turris package space) - #16 by adminX - Turris Omnia - Turris forum
Root fs on mSATA drive? - Omnia HW tweaks - Turris forum
So me was a bit shocked to see /dev/sda1 got supported in the rescue image. I didn’t even notice the new image and this feature until now. Maybe it was a solution for some devices with broken MMC.
Back to 2020.
There are a least 3 hardware revisions of the omnia. These have at least 2 different u-boot and rescue images running.
The pre-2019 ones have a rescue that does not support SATA but there is a update with SATA support available. It has to be installed manually. Everything except cert-backup works with SATA the same way it works with MMC then.
Then we got Mox and it needed a more capable bootloader and rescue system that only has MMC. The micro SD card is accessed using mmcblk0 internally like on the Raspberry PI.
The rescue system for Mox got support for Omnia too. So there are 2 rescue images built from basically the same source.
Now comes the catch with it: Mox got the Turris Shield version and Omnia got contract versions. These probably run basically the same TurrisOS with some UI changes to tailor them to the target audience, e.g. simplified entering of user credentials for internet access on the omnia or something like that.
Up to here we got a bunch of devices which all run from MMC and got a quite capable rescue system. It even is able to reset the u-boot environment variables if you use rescue mode 3 (4LEDs).
There is no real need to run root on SSD apart from broken MMC. This should not happen unless you fill your MMC and write tons of data. Modern eMMC devices are quite durable and work like SSDs. Mobile phones have a ton of writes to eMMC and still work for years. OpenWRT and TurrisOS write seldom compared to Android. Compiling software is something different and can be really a flash killer.
I just got a working rescue image done and it supports SATA and MMC but required some hacks and a small patch. I may put them untested in the bug tracker but i am not sure. I am just in a really really bad mood and totally upset by OpenWRT.