What led me to look at symlinks in AUFS -- Part I chrooted Iron Browser
@mikewalsh , has built a chrooted iron browser, which I find quite useful due to its portability. For a wide range of puppies dating back to puppy 4 (e.g. Darry's "Phoenix" build of Puppy 4.3.1 [1] ) The browser will just work and as a consequence provides a nice fallback if one needs a chrome based browser and has trouble getting other versions to work (e.g. versions available via the package manager).
The design is interesting because within the SFS file there is a chroot folder called "/cont" (short for container). The SFS file provides a nice simple script to start the browser within this folder.
The chrooted iron is based on Sailor's Slacko 571 [2] which often comes up as one of the recommendations for older hardware. Given that we have a system that both runs a modern chrome based browser and works on older hardware it is of great interest to me.
Some things that I might want to try with it are:
1. Break it up into smaller units possibly for the purpose of trimming. I think that that mikewalsh has already done some of this (see post)
2. Add Scottman's man's package manager to it (i.e. pkg) if not included already (as a separate sfs) also with the root at "/".
3. Add option to boot into it as a standalone system via an additional SFS, which will include anything needed to do this (as separate sfs files).
One tool that I'll use to do this is my psandbox utility, which lets me mount mikewalsh's chrooted iron with a save file.
Adding Layers to mikewalsh's chrooted iron
Most sfs files are built with the root at "/". Since the chrooted iron is built with the root at "cont" some care is required. Several aproaches come to mind:
1. Rebuild the chrooted iron sfs so that the root is at "/"
2. Try to build the chrooted iron from scratch using either (Sailor Enceladus Slacko 5.7.1_r6231.iso or mikeslr Slacko 5.7.2 CE) and( mikewalsh's portable version of iron).
3. create symlinks that link from "/" to the folders in "/cont" (e.g. /bin -> /cont/bin)
4. Symlink individual files into "/". This approach is used in tinycore for packages (see post) and is advocated for by @wanderer .
5. create the following symlink (/cont -> "/")...note this approach doesn't work with aufs but in theory a layered file system could be developed in such a way where this would work. A possible alternative is to create a sfs file where items in /cont are hardlinked to "/" and then one can block out what they don't want [3].
I took a stab at "#3" and it worked for me but I have an issue to work out related to the closing of the chroot folder (see post). Approach #4 is similar to #3 and adds more flexibility at the expense of processing time and io resources.
Limitations of symlinks and hardlinks in aufs file systems
One could immage a layred file system approach where merging a layer (either on top of or under depending on the implementation) preserves the symlinks of one of the layers and instead of blocking the other layer merges the files into where the sylinks pointa. In the aufs file system it doesn't work this way. The top layer blocks. If the top layer is a folder then it will block the symlink. If the to layer is a symlink then it will block the folder. This has implications when loading sfs files. For instance, if you load a sfs file developed from a newer puppy into an older puppy then the multi-arch symlinks might block files within the sfs. In later versions of puppy the multi-arch symlink hack has been removed.
pseudolinks (AKA plinks), hardlinks and workarounds for symlink/folder blocking
As an experiment I tried hardlinking the files from "/cont" into "/" using a technique I mentioned in (another post). This approach seems to duplicate the files into "/" and make these files look as though they are hardlinked by modifying the reported number of links to the file. There is also a directory created in the savefolde, which contains the name plink (for pseudo link. I think that this plink folder contains an inode mapping between the save file and the merged aufs.
My thought here is that I can copy the merged aufs contents into a new sfs file. Then I can can sort of implement apprach #3 above by blocking the /cont with a symlink in a higher layer, or alternatively if I want the chroot to be symlinked based then I block files in "/" with whiteout files. The idea here is to have a single sfs where I can experiment both with sylink based merging and also more traditional based merging. With hardlinks I expect that this won't add much additional space to the sfs file.
Having components divided into seperate folders within the sfs could be useful for experimenting with a more modular system. One simply sylinks the components from the sfs they want into "/". The symlinks can be quickly created and edited and then when one is happy with the final system then they can copy the symlink targets into a new sfs file.
Notes:
1. I can't find a link to a specific puppy by darry called Puppy 4.3.1. However, is a link to his remaster of 4.3.2, and links to his related puppies: Anitaos(432k2.6.30.5SMP).iso (2014-07-05) and AnitaOS4.31v3.iso (2017-09-19).
2. Closely related to Sailor Enceladus’ Slacko 5.7.1_r6231.iso is mikeslr's Slacko 5.7.2 CE.
3. The symlink approach to packages used in tincycore and corepup could provide an alternative to layered file systems where one might not be able to do layered file systems (e.g. they lack root premissions). For instance, the sylink approach might be sued to create a termux/proot version of puppy (see post).