site  contact  subhomenews

SFSget SFS management improved

August 12, 2019 — BarryK

There is a desktop icon labelled "sfsget", for downloading and installing SFS files. I have made improvements to how it works.

Firstly, it no longer probes the entire online repository every time it is started, as that is very slow. Now, the is a file named 'date-last-update' in the online SFS repository, which is downloaded. If the date is later than the local copy of the file (in /var/local/sfsget/date-last-update), then a full probe is performed.

Other improvements are handling of installation. In a nutshell, care is taken to make sure that a downloaded SFS can only install in the right place. For example the "kodi" SFS from here:

Must install into either a new container with the "xenialpup" SFS underneath, or in an existing container that has "xenialpup" as its base layer. It cannot be installed to any other existing container nor to the main desktop.

I am experimenting with dropping some Linux Capabilities when performing the switch_root from the initrd, so far dropping of 'cap_sys_mount', which will disable partition mounting and unmounting. In that situation, containers cannot be run, as they require mounting -- so only SFS files suitable for the main filesystem can be installed -- sfsget handles that too. 

There are other little twists to the installation logic, but the end result should be simplification for the user, eliminating any inappropriate installation choices. 

I should mention that if you are running Easy Buster, in sfsget you will see the Pyro SFSs -- these can be downloaded, and will run in their own containers. And you can have the "pyro" SFS as the Pyro desktop in a container. Just like we already have with Xenialpup. 

Tags: easy