I am remembering more about the decisions I made when originally designing this...BarryK wrote:sfs files placed under the 'sfs' folder are supposed to be created with special meta-data inside them. The way to re-make an existing sfs is to open it up and use 'dir2sfs' -- there is a blog post on that.davids45 wrote:Boot Manager problem
I'm trying to load some sfs of various things (games, pwidgets, printer driver) I've copied to the indicated directory but nothing seems to be loading on re-booting (screenshot). Is there a new type of sfs required?
However, traditional sfs files can be loaded, place them in /mnt/wkg/releases/easy-0.9.10, then run the menu Filesystem --> Easy BootManager and you can select them.
It requires a reboot. Not supporting load-on-the-fly, as when a change in sfs layers, there is special checking done in 'initrd' before the layers get loaded.
SFSs placed in /mnt/wkg/releases/easy-0.9.10 will NOT be recognised by the BootManager, only those under the 'sfs' folder -- and they must be built with 'dir2sfs' to have the required meta-data.
If you really want to use one of your SFSs, place it in /mnt/wkg/releases/easy-0.9.10 and manually edit /mnt/wkg/releases/easy-0.9.10/configuration, insert a variable
EASY_LAYER_RO1=name-of-the-sfs-here
Then reboot.
However, I do not recommend doing this. Well, you can, with caution.
SFS's should really be compiled for the host system in which they are going to run, with matching folders.
For example, your ace-of-penguins has /usr/lib64 folder, however, easy.sfs has /usr/lib64 as a symlink to /usr/lib. So does Xenialpup.
Easy does not have /usr/lib/X86_64-linux-gnu, Xenialpup has it as a symlink to /usr/lib -- so, if ace-of-penguins SFS is a layer above easy.sfs or xenialpup.sfs, it could totally mess things up.
Although it might seem to work, it will break other apps. For example, some apps are hardcoded to look in /usr/lib64 or /usr/lib/x86_64-linux-gnu, and their files will no longer be there.