On a Classic system the
/etc/os-release is different on the rootfs that from what a snap sees.
root@jetson-xavier-nx-devkit:~# cat /etc/os-release
PRETTY_NAME="ST OS 0.3"
Running the same inside a snap
root@jetson-xavier-nx-devkit:~# snap run --shell thinghub
root@jetson-xavier-nx-devkit:/root# cat /etc/os-release
PRETTY_NAME="Ubuntu Core 20"
We need access to the
/usr/lib/os-release on the hostfs instead of the
base snap. I think it would make sense for snapd to allow access to
/var/lib/snapd/hostfs/etc/os-release. The latter is the symlink to the former.
Can you give some information on the reasons this access is required in your snap? It feels slightly odd to inspect what is the host system given that the snap is executing on a known base (core20 in this case). The idea is that you should not need to care about such detail.
Our app is supposed to be a kiosk, which shows details about the OS, along with other features. The “os” in our case is the information that’s embedded in
/etc/os-release on the hostfs.
In that case, there’s a system-observe interface which gives what you want. The caveat is that the interface is not auto connected, unless there is a snap declaration in place. If your snap is published to the store, you can open a forum topic and ask for auto connection. Otherwise, you can probably do it yourself once the snap is installed.
I ended up settling on
/etc/lsb-release instead. It seems a confined app is able to read that file from the hostfs.