I was not really aiming at persistence, but at a way of obtaining a pristine environment at each bootup, particulary the user's home directory.
Perhaps a simplified example may help. Your build on a bootable USB flash drive is used to boot the system with persistent / and non-persistent user home. The user now installs an additional app that looks to place its configuration file in the user home area.
Once user is satisfied with persistence changes, user should then remaster to create a new, pristine linuxfs file...
This will capture the application executables but not its configuration file.
...and then run without persistence...
The app configuration will not exist in this circumstance.
...or only run with home persistence...
In which case there is no longer a pristine user home.
...and have the home data encrypted.
In order to read and write to the encrypted user home, the encryption must first be "unlocked". Once this has been done, the system has transparent access to the user home. In this condition the user home is persistent and non-pristine. It is also non-selective. At shutdown everything in the user home area is saved and encrypted. The encryption will help prevent unauthorized access to the data in a persistent user home area when the USB stick is attached to a machine that was not booted from the stick.
The idea of using preserved.tgz is to capture app config files without enabling home persistence
. It would also be able to capture similar files in /. It is very selective. Only the configuration files explicitly specified by the user are retained in preserved.tgz, all other files in the user home area are destroyed once the system is powered off. In so doing a fresh / and a pristine user home are always created at each boot up. The outcome is a self-protected system which is insulated from unwanted changes and maximizes reliability.
If preserved.tgz cannot restore the configs to the USB live file system then the idea is redundant. It is also redundant if the user home must be persistent. I am looking for information on these points but have not found any up to now. Perhaps BitJam
might be willing to offer a view on these particular aspects? If they are not "blockers", then it is likely that it can be done without needing changes to the way antiX live USB works. The idea is as yet untested in antiX and I won't be able to test it for a while.
I found this file on the local system /usr/share/antiX/FAQ/persistence.html. It is refering to antix2usb and indicates
Persistence. There are four options here.
- No persistence - just leave as default.
- home persistence - check home and select size
- root persistence - check root and select size
- Both home and root persistence - check both home and root and select sizes.
If this is correct then LiveUSB can be run with non-persistent user home