How is this different from "save66sfs"?
Each save is a complete save, so a single ".sfs" file contains all the save data files at the time of the shutdown.
There is no consolidation of multiple ".sfs" files, either during 'init' or via a utility.
----------------
I have uploaded 'local-initrd.gz', 'pm66sfs-01.pet', and 'pm66sfs-01.sfs' to https://www.mediafire.com/folder/66yek13pef2hv/pm66sfs.
You need 'local-initrd.gz' and 'pm66sfs-01.pet' or 'pm66sfs-01.sfs'.
This is a proposed update to the current pupmode=66.
It saves to a ".sfs" file instead of a ".tar.gz".
Changes:
1. Pupmode=66 is no longer restricted to "fat32" and "exfat" partitions.
Although the AUTOSAVE function in 'shutdownconfig' still selects pupmode=66 for only "fat32" and "exfat" save partitions.
No matter the filesystem of the save partition, you can issue the following command to enter pupmode=66:
Code: Select all
echo "PUPMODE=66" >> /etc/rc.d/PUPSTATE2. On save, a ".sfs" file is written, containing all the "real" files from the current RW layer,
including anything mounted at '/initrd/pup_ro1'.
The "whiteout" files are written to a ".tar.gz" file.
Both these files have the same date/time string as part of their filename.
e.g 's15pup64save66_241014-0005.sfs' and 's15pup64save66_241014-0005.tar.gz'
The "whiteout" files are kept out of the ".sfs" file so there is no possibility of there ever being a redundant "whiteout" file trapped in a ".sfs".
3. If the currrent 'mksquashfs' supports "zstd" it will be used, otherwise "gzip" will be used.
4. On boot, the "whiteout" files are culled against the contents of the current stack,
which at this point in the 'init' script, should contain all the Puppy ".sfs" files, but no save files.
So redundant "whiteout" files should be automatically removed from Puppy.
5. On boot, the most recent ".tar.gz" file is extracted into the RW directory in RAM.
If a corresponding ".sfs" file is found, it is prepended to the stack as '/pup_ro1'.
6. The PUP_HOME variable in '/etc/rc.d/PUPSTATE' is now set,
so the symbolic link '/mnt/home' should now point to the mount-point of the save partition.
Pros:
1. After installing a few ".pet" (".deb" etc...) files, and then doing a save,
the installed software does not get extracted back into RAM on the next boot,
the ".sfs" file is simply mounted.
2. The inclusion of a date/time string in the save filenames, provides an automatic backup/rollback facility.
(Provided you don't delete all the old save files.)
Just remove any more recent save files, out of the way.
3. The save ".sfs" file could be moved to become the top of the RO stack, e.g. as a pseudo adrv.
If you opt to do this, make sure that all previous save files are moved out of the way,
leaving only the curent save ".tar.gz" file.
(Booting will continue to work fine with only a ".tar.gz" save file.)
4. As a ".sfs" file, it could easily be recreated using different compression, if size is a problem.
5. As with current pupmode=66, on shutdown, you get a choice to "save" or "not save".
Cons:
1. There is no single save "file/directory", a complete save consists of a ".tar.gz" file and a corresponding ".sfs" file.
The 2 files should usually be manipulated together, (deleted or moved), except in the case of "Pro 3.".
2. You need to monitor the number of save files, and remove old ones when necessary.
3. Creating a new ".sfs" file on shutdown can be a little slow, even though the process has been "optimized" for speed rather than size.
(Not a big deal if you "not save" a lot more frequently than you "save".)
local-initrd.gz
Contains the new 'init' script to support the new booting process, and '/sbin/do66'.
The bulk of the new pupmode=66 code is in '/sbin/do66' which gets included in 'init' if required.
Simply drop 'local-initrd.gz' into a frugal install directory,
if the grub2 menuentry for the Puppy was generated by FrugalPup, this file will automatically be loaded.
pm66sfs-01.pet
Contains the new '/usr/sbin/savesession-archive' to implement the shutdown functionality.
pm66sfs-01.sfs
Contains the same as the 'pm66sfs-01.pet' file.
If you use it, make sure that it is mounted in the stack above the 'puppy...sfs' file.
The included '/usr/sbin/savesession-archive' has to "cover" the existing file.
Loading with 'sfs_load' will not work.