An approach to persistence for overlayfs Puppy frugal installs.

[gyrog]

Or, yet another 'init' script.

By default, Puppy would run in pupmode=66, no matter the filesystem of the install location or the save location.
So 'pup_rw' is always in RAM.

At every shutdown:
1) User is asked to save, "Yes" or "No"?
2) If "Yes", an archive of 'pup_rw' is created, e.g. using 'savesession-archive'.
The archiving process is "smart", ignoring files that don't need to be persistent.

In 'init':
If a "save" exists:
(A "save" could be a savefolder, savefile, or even a savesfs.
This version does not include support for a savesfs.)
1) The "save" is loaded as an RW directory at 'pup_ro1'
2) If a save archive exists, it is extracted into 'pup_ro1'.
The save archive file is then deleted.
3) The "save" could be re-loaded as an RO directory at 'pup_ro1'.
4) 'pup_ro1' is added to the stack immediately below the RW layer.
If no "save" is found:
If a save archive file exists, it is extracted into 'pup_rw'.
If no "save", and no archive:
It's a first-boot, pupmode=5.

Notes:
1) Only 2 pupmodes are really needed, pupmode=5 for first boot, and another for 'rc.shutdown'.
This is implemented as pupmode=66, because then a current 'rc.shutdown' will do the appropriate thing.
Hmmm... need pupmode=5 during first boot, but pupmode=66 during first shutdown.
This is done with a simple 'shutdownconfig' replacement in 'pm66plus01-ydrv.sfs'.
Or possibily:
If 'snapmergepuppy' were replaced with a symbolic link to 'savesession-archive',
maybe pupmode=13 could be used when a 'pup_ro1' is in play.

2) Out of the box, Puppy just runs with persistence, independent of the filesystem it is installed on,
no surprising questions for first-timers, e.g. no savefile setup on first shutdown.

3) Files that are deemed to not require persistence are NEVER saved to disk.
(Controlled by which files 'savesession-archive' includes in the archive.)

4) Since the "save" is never the top RW layer, there is never any issue with a "work" directory.
Also the "save" is strictly RO in the running system, so if it is a savefile, it is remounted RO.
The partition containing a savefolder could possibly be remounted RO, but that might impede "outside the stack" activity, e.g. installing new Puppies.

5) If a 'pup_ro1' is being used, it can be backed-up at any time during a session, since it is RO or is effectively RO.
Though the backup would not include any changes from the current session.
If 'pup_ro1' is not being used, the save archive can be copied at any time.

6) There needs to be a utility to create an empty "save" in the save location.
This could be run whenever the user deems the save archive is getting too large.
It could even be run before first-shutdown, so that it is in place for second-boot.

7) There could be an "archive location" concept introduced to Puppy.
This would be a partition dedicated to having save archive files written to it.
If it is on a different partition to the "save location" then the "save" partition could be remounted RO by 'init'.
The 'savessession-archive' process would mount and umount this partition.
This would enable a Puppy running with a "save" to approach the robustness of pupmode=5 in relation to sudden shutdowns.

8) This is not about the addition of an extra save mechanism, it's a replacement for the whole of the 'init' save mechanism handling.

9) Yes, there is no support for optical drives.
Although it could include support for booting image files, as per current 'init', e.g. ".iso" files.

10) Yes, it's the end on my beloved pupmode=12.

11) "RO" means "read-only"
"RW" means "read and write"

To try this first working version:
Download 'pm66plus01_local-initrd.gz' and 'pm66plus01-ydrv.sfs' from https://www.mediafire.com/folder/hutn1c5w6g9e7/pm66plus
Move both files into a fresh Puppy frugal install directory.
(I used FrugalPup for the install, if you do the install some other way, you need to ensure that the 'grub.cfg' menuentry includes support for a 'local-initrd.gz').
Rename 'pm66plus01_local-initrd.gz' to 'local-initrd.gz'.
Rename 'pm66plus01-ydrv.sfs' to an appropriate ydrv...sfs filename for the Puppy. e.g. 'ydrv_s15pup64_22.12.sfs'
Reboot.
Assuming a sucessfull boot to the desktop, fill-out the 'QuickSetup' form.
Reboot and click on the "Yes" button to save the session.
Assuming another sucessfull boot to the desktop, make further tweaks, and reboot.

The Puppy is now running in classic pupmode=66.

If you installed Puppy with a Linux save location (often the install directory), you can now start using a savefolder.
Create a new directory in the save location with the appropriate "save" name for the Puppy. e.g. 's15pup64save'
Reboot and click on the "Yes" button to save the session.
Assuming another sucessfull boot to the desktop, the Puppy is now running with a savefolder at 'pup_ro1'.

If you installed into a non-Linux partition, you can start using a savefile.
Create a new savefile with a name appropriate to the Puppy and reboot. e.g. 's15pup64save.4fs'
This should result in the Puppy running with the savefile at 'pup_ro1'.
Note that in the running Puppy the savefile is mounted RO.

Classic pupmode=66:
On shutdown the contents of 'pup_rw' in RAM are archived.
In 'init' an empty 'pup_rw' in RAM is populated by extracting the archive.
Current Puppy uses this only on fat32 partitions, e.g. usb sticks.

Extracting archive to ro1:
1) Unfortunately, the busybox tar in many Puppies 'initrd.gz' will not clobber existing files as I would expect,
so the files in the archive are removed from 'pup_ro1' before the extraction.
2) Whiteout files in 'pup_ro1' seem to work, even though they are not in 'pup_rw'
3)The whiteout files in 'pup_ro1' are then validated by checking if they "delete" a file in 'pup_sfs'.
If it does not, it is removed because it is a "defunct" whiteout file.
4) A list of overlayfs whiteout files can be obtained with this command:
find -H /initrd/pup_ro1 -type c

'pup_sfs':
This 'init' uses my "singly-init" algorithm to create an RO overlay at 'pup_sfs', of all the ".sfs" files defined for this session.
If a file does not exist in 'pup_sfs' then it's not in any of the ".sfs" files.
This overlay is then used as a "lowerdir" for the main RW overlay.
(If a savesfs were implemented, it would not be part of 'pup_sfs', it would be 'pup_ro1'.)

'pm66plus-ydrv.sfs':
'pm66plus-ydrv.sfs' contains an "improved" version of 'savesession-archive',
a very simple replacement for 'shutdownconfig' to force pupmode=66 on first-shutdown,
and a '/root/.config/save-exclude.lst' file.

savesession-archive filter:
'savesession-archive' combines the lines of "$HOME/.config/save-exclude.lst" file into a filter for a "grep -vE" command.
Editing this file will change which files get included in the save archive and hence 'pup_ro1'.

[ozsouth]

@gyrog - this looks promising. When I tried something like this using your 2019 script (mine was a crude process), folk wanted the option to manually interim save (sort of pupmode 13). Is that possible or codeable using this approach?

[gyrog]

@gyrog - this looks promising. When I tried something like this using your 2019 script (mine was a crude process), folk wanted the option to manually interim save (sort of pupmode 13). Is that possible or codeable using this approach?

Yes.
Theoretically, 'savesession-archive' can be run at any time.

[gyrog]

In the next version, the pm66plus 'init' actually pretends to implement pupmode=13.
The 'pm66plus-ydrv.sfs' includes a simple replacement for 'snapmergepuppy.overlay' that runs 'savesession-archive'.
This works fine at shutdown. (I haven't tried doing a manual save during a running Puppy yet.)

[gyrog]

Overlayfs supports 'pup_ro1' being a directory on any filesystem, (not just Linux filesystems).

With pm66plus, maybe we could use a "savefolder" no matter what filesystem is in play.
I'll give it a go.

Later edit:
Well I tried it on fat32, and it failed.
What was I thinking?
'pup_ro1' contains symbolic links, and overlayfs whiteout files, which are special character device files.
To provide a savefolder on any filesystem, the 'pup_ro1' would need to contain only "ordinary" files.
And that becomes significantly more complicated.

[ozsouth]

@gyrog - yes, character files are difficult to handle. Sometimes you want them there (if you deleted from the base sfs) & other times you don't, as added files won't copy over them. I wound up snapshotting my running system before saving, & comparing the savefile sfs contents, then backing up the difference, to restore next bootup. Very slow - I had to use gzip on low compression or it took minutes. Was thankful that dinkr's overlay system allowed savefolders, & abandoned my idea. That's why your approach interests me.

[gyrog]

@ozsouth, yes, processing overlayfs whiteout files, is one of the challanges of this project.
I'm about to try an approach which saves the whiteout files separately.

When you say a "savefile sfs" do you mean 'pup_ro1' is a ".sfs" file?
I would call that a "savesfs".
And I maybe able to do that by doing the processing during 'rc.shutdown', we'll see.
A new ".sfs" file could be created during shutdown, but with a different filename.
Then if 'Init' finds a file with the different filename it moves it to replace the old "savesfs".

[gyrog]

pm66plus version 03 is available.

The noticeable difference is it now pretends to be pupmode=13 when a savefolder or savefile is introduced.
Clicking the "save" button, does work, although I see no visual feedback.

There is no "savesfs" feature, because there is no 'mksquashfs' or 'unsquashfs' in the initrd environment.
(Of course this is not an insurmountable challange, but for now it is suficient.)

There are also some bugfixes, i.e. things that did not work properly but now do.

If you try this on an older Puppy e.g. FossaPup64, on shutdown you will get the old "ask-to-save" dialog rather than the current GUI one.

To try this updated version:
Download 'pm66plus03_local-initrd.gz' and 'pm66plus03-ydrv.sfs' from https://www.mediafire.com/folder/hutn1c5w6g9e7/pm66plus
Move both files into a fresh Puppy frugal install directory, or the one you used for pm66plus01.
(I used FrugalPup for the install, if you do the install some other way, you need to ensure that the 'grub.cfg' menuentry includes support for a 'local-initrd.gz').
Rename 'pm66plus03_local-initrd.gz' to 'local-initrd.gz'.
Rename 'pm66plus03-ydrv.sfs' to an appropriate ydrv...sfs filename for the Puppy. e.g. 'ydrv_s15pup64_22.12.sfs'
Reboot.

Thinking on the "savefolder everywhere" idea, I'm going to try a slightly different approach to implementing this thing.
So, unless I get bug reports, this could be it for a little while.

One issue with the currrent implementation is that all the updating of 'pup_ro1' is done in 'init',
while / is not a mounted overlay, and 'pup_ro1' is just a directory, not a layer in an overlay.
This works well with overlayfs, but in an ideal situation, this updating would be done in rc.shutdown,
which doesn't sit well with overlayfs while the overlay is still mounted.
It would be good if root could be switched away from the overlay in rc.shutdown, so it could be unmounted.

[gyrog]

FYI:
To work as intended, the 'init' script needs the new 'savesession-archive', so it needs 'pm66plus03-ydrv.sfs' to be mounted.

[Clarity]

Hi @gyrog

Glad you're continuing improvements in start-shutdown processing of WoofCE distros.

I do not and have not installed, frugal or otherwise, since GRUB2 Pup updates starting in 2019.

Today, I ONLY boot forum distro ISO files as I, personally, have all my needs satisfied in persistent savefolders for all distros.

Your upgrade back then for SAVESPEC has made this so simple because NO GRUB stanza need be interrupted to indicate where savefolders are found/used at distro boot time. (Your utility to setup-edit SAVESPEC seems to continue to be missing in some modern WoofCE PUPs)

This, so far, means that most WoofCE PUPs have no problems with all its necessary information for boots, saves, and shutdowns, CORRECTLY, without user intervention BEFORE, DURING, OR UPON REBOOTS. SG2D and QEMU ISO boots of these WoofCE distros are without issue.

THANKS AGAIN FOR MAKING THIS SO SO SO SIMPLE!

Today, FATDOG and KLV are the 2 families of forum distros whose ISOs boot without issues, not only via SG2D and QEMU, but also, directly, via Ventoy. There are only 2 WoofCE distros which boot directly via Ventoy; namely Slacko v7.0 AND Friendly versions. All others seem to run into problems finding things and either drops to a GRUB menu or abends trying to boot when selected in Ventoy. Although, if one boots the SG2D ISO/IMG from Ventoy first, then selects the offending WoofCE ISO, SG2D will boot it properly to desktop in most cases.

I dont think this is due to any of your work, and suspect it could be due to timings as all of my Ventoys and SG2Ds ISO files are kept in a BOOTISOS folder on a USB device where all system boots occur.

This info is merely FYI as I am sure this has already been noticed by most.

FYI

[gyrog]

pm66plus version 04 is available.

Note: This is still at the "proof of concept" stage, although it should function correctly.

It supports "savesfs".
But shutdown is quite slow, when you choose to save the sesssion.

Whiteout files are alwsays stored separate from other files:
At shutdown they are always saved in "${DISTRO_FILE_PREFIX}_RAMsave.tar".
In 'init' this archive is always extracted into 'pup_rw'.

'pup_ro1' contains only "normal" files and symbolic links, as does the main pupmode=66 "${DISTRO_FILE_PREFIX}_66save.tar".
So creating one "save" mechanism from another, is not very difficult.

This is still not suitable for "savefolder everywhere", but it could be modified to do so.
'savesession-archive' is now setup to process each file type, ("normal", symbolic links, and whiteouts) separately.
So it should just be a matter of redirecting the symbolic links to "${DISTRO_FILE_PREFIX}_RAMsave.tar".

It includes a 'pm66plus' utility to support:
Creating a "save" and transitioning from pupmode=66 to pupmode=13.
Also switching between pupmode=13 and pupmpode=66.
(More detail further down)

To try this updated version:
Download 'pm66plus04_local-initrd.gz' and 'pm66plus04-ydrv.sfs' from https://www.mediafire.com/folder/hutn1c5w6g9e7/pm66plus
Move both files into a fresh Puppy frugal install directory, or the one you used for pm66plus03.
(I used FrugalPup for the install, if you do the install some other way, you need to ensure that the 'grub.cfg' menuentry includes support for a 'local-initrd.gz').
Rename 'pm66plus04_local-initrd.gz' to 'local-initrd.gz'.
Rename 'pm66plus04-ydrv.sfs' to an appropriate ydrv...sfs filename for the Puppy. e.g. 'ydrv_s15pup64_22.12.sfs'
Reboot.
OR
If you have a computer that boots with uefi:
Download 'JammyPup32-22.04-230901-66plus.zip'(360MiB) from https://www.mediafire.com/folder/hutn1c5w6g9e7/pm66plus.
Unzip it into an empty bootable USB drive (fat32 partition), then boot the USB drive.
This JammyPup32-22.04 has pm66plus already installed.

How to use Puppy with the pm66plus environment:
On first-shutdown there is no 'shutdownconfig', there is just a "Save session? - Yes/No" dialog.
An affirmative answer produces a pupmode=66 "save".
You can keep running Puppy in this mode as long as you like, but the more software you install, the slower shutdown, and boot, gets.
The idea is that you can use this simple mode to do Puppy configuration.

When you are ready to start installing extra packages, (not ".sfs" files or "portabable" apps),
you run the 'pm66plus' utility and create a real "save", (either a savefolder or savesfs, at this stage).
(But you could manually convert the savesfs to a savefile later.)
The 'pm66plus' utility will transition you to pupmode=13, via a "no-save" reboot.

But here's the twist:
The current pupmode=66 "save" is "parked", so you can use the 'pm66plus' utility to switch back to it at any time.
And when you switch back to pupmode=13 you get your "save" back as it was before you switched to pupmode=66,
unless you have directly modified it while running in pupmode=66.
The idea is to use the pupmode=66 "save" as a fully configured "base" that runs totally in RAM.
So you can switch to it when you want to directly manipulate your real ro1 "save".
Yes, you actually have 2 independent "saves".
I recommend booting with "pfix=fncopy" for switching back and forth with a savefolder, this will "copy-to-ram" in pupmode=66, and not "copy-to-ram" in pupmode=13.
(The partition containing the savefolder will always remain mounted in pupmode=13, anyway.)

If you have a "savesfs", you can run totally in RAM, since it wil be copied into RAM if the system ".sfs" files are. Boot with "pfix=copy" for this.

[gyrog]

@ozsouth, I just found your "s15pup64-ovrly" topic, and noticed that you were trying to get 'sfs_load' to work with overlayfs.
This 'init' provides no support for 'sfs_load' at all.
It doesn't even look for 'sfs_load' type sfs file specs.

Apart from the standard woof-ce ?drv...sfs files, it depends solely on definitions in a 'DRV_SPECS' file in the install directory.
In my testing of pm66plus, I use:

Code: Select all

DRV_PRE='k a b m6 y'
DRV_m6=':/tpups/pm66plus-ydrv.sfs'

to mount 'pm66plus-ydrv.sfs' just above the 'ydrv', as 'm6drv'.

[ozsouth]

@gyrog - I actually used a Feb2023 init for s15pup64ovrly. I think v1 without sfs_load_overlay is more robust.

[dimkr]

2) If a save archive exists, it is extracted into 'pup_ro1'.

Does this mean very slow boot compared to PUPMODE 13?

The save archive file is then deleted.

Many old laptops have bad batteries, and people will lose data on unclean shutdown (like power failure). Do I understand correctly?

savesession-archive filter:
'savesession-archive' combines the lines of "$HOME/.config/save-exclude.lst" file into a filter for a "grep -vE" command.
Editing this file will change which files get included in the save archive and hence 'pup_ro1'.

Isn't saving super slow and super I/O intensive? If I have 200 MB of files in pup_ro1 but only one 1 MB sized file has changed, does savesession-archive write 1 MB to disk or rebuild the whole archive again?

---

And, another question: why does the title say "for overlayfs", if the same concept can be applied to aufs as well? Today's woof-CE already supports PUPMODE 12, 13 and 66 with overlay, so I wonder why it needs complicated special handling.

[gyrog]

@dimkr

The following is a direct quote from the kernel overlayfs documentaion:
"Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock."

Pm66plus is overlayfs friendly because it implements that statement to the letter.
'pup_ro1' is never modified in the running Puppy, only in 'init' before it is mounted in the overlay.

Could pm66plus be implemented with aufs?
I would expect so.
But I am not interested in developing anything "new" based on aufs.

I'm not talking about enhancing the 'init', for me it's a replacement.
It changes the way I interact with Puppy.
No matter where I install a Puppy, or what partition I define as the save location,
on every shutdown, including first-shutdown, there is never more than a single question:
"Do you want to save the session?"
Because it defaults to pupmode=66, or as I have come to call it "archive" mode.

Creating a savefolder, savefile, or savesfs is done at my own leisure, using a utility in the running system.

Puppy is always running with the top layer of the overlay in RAM.

RO1 processing, "layer" mode:
If there is an "ro1", all your saved files are in the "ro1", the "rw" layer contains only whiteout files and files written during the session.

On shutdown:
If a save is requested:
'savesession-archive' generates lists of the files and empty directories in "rw".
These lists are filtered to produce minimum lists of files that need to persist.
The files in the lists are then archived with tar.

So, only some of your 1MB of files actually get copied.

In 'init':
If the required tar files exist, then a save was done at shutdown:
So "ro1" is updated with the contents of the tar files, and the tar files are deleted.
If "ro1" is a savefile, it is remounted read-only.
Otherwise:
The current "ro1" is used.

If there is a power failure, during a ssession, everything in RAM is of course lost.
But the file system containing "ro1" has a good chance of recovering since it's not being written to.

Is it slow:
If you add lots of files to the "rw" layer, e.g. by installing a number of .debs or .pets,
then there will be pauses while all the files are processed,
but I have not noticed it when I change a single configuration, and request a save.

Of course, if you don't request a save, there are no delays.

Is it slower than the classic aufs pupmode=13?
I wouldn't have a clue, I never use aufs pupmode=13.

Using a savesfs is an exception to the "ro1" processing described above.
1) By it's nature, a new ".sfs" has to be created combining the old and the new.
2) There is no support for mksquashfs in the current 'initrd.gz',
So a new ".sfs" is created by 'savesession-archive', which is moved to replace the old one in 'init'.
(mksquashfs could be added to 'initrd.gz', but I am trying to limit the amount of changes to a woof-ce Puppy required to run this thing.)

[dimkr]

"Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock."

This sentence means that direct changes to pup_ro1 or pup_rw trigger undefined behavior. For example, if I cat /root/x, then modify /initrd/pup_ro1/root/x, then cat /root/x again, I get the original file contents (because they're still cached). After echo 3 > /proc/sys/vm/drop_caches, I see the modified file.

As long as you don't modify the files under pup_ro1, pup_rw or pup_work directly (and you shouldn't; you should let overlay do that for you), overlay is safe to use and no special treatment is needed. The classic pup_ro1 and pup_rw model works as long as you don't modify, delete or add files in pup_ro1 or pup_rw directly.

Could pm66plus be implemented with aufs?

Why not?

The files in the lists are then archived with tar.

So, only some of your 1MB of files actually get copied.

Does this mean that every time I save, a new archive is added, with nothing but the changed files? Or, does savesession-archive rebuild the entire archive to replace a single modified file?

[gyrog]

Why not?

Already answered that.

Does this mean that every time I save, a new archive is added, with nothing but the changed files? Or, does savesession-archive rebuild the entire archive to replace a single modified file?

Your "Or" is non-existent, there is no archive to rebuild, it was deleted by 'init' after it had been used.
So every time you save, a new archive is created, for just the files that need to be transfered to the next boot.

[gyrog]

pm66plus version 05 is available.

Well 'pm66plus05-ydrv.sfs' at least, the 'init' remains unchanged so use 'pm66plus04_local-initrd.gz'

The 'pm66plus' utility has been enhanced:
It is more particular in showing only the facilities that are possible in the current Puppy.
It supports the creation of a savefile as a sparse file so the size on disk depends on how much data is stored in it.
This facility is not provided on a "vfat" partition, because "vfat" does not support sparse files.
The savefile is 4GB in notional size, and formated with ext4.
There are no questions, it just does it.

But there is still no ".desktop" file in '/usr/share/applications' so it has to be started by:

Code: Select all

pm66plus

in a terminal.

(Yes this utility could do with a lot more work, but it does enough to demonstrate the concept.)

To try this updated version:
Download 'pm66plus04_local-initrd.gz' and 'pm66plus05-ydrv.sfs' from https://www.mediafire.com/folder/hutn1c5w6g9e7/pm66plus
Move both files into a fresh Puppy frugal install directory, or the one you used for pm66plus03.
(I used FrugalPup for the install, if you do the install some other way, you need to ensure that the 'grub.cfg' menuentry includes support for a 'local-initrd.gz').
Rename 'pm66plus04_local-initrd.gz' to 'local-initrd.gz'.
Rename 'pm66plus05-ydrv.sfs' to an appropriate ydrv...sfs filename for the Puppy. e.g. 'ydrv_s15pup64_22.12.sfs'
Reboot.
Or
If you already have pm66plus04 installed, just replace the ydrv with 'pm66plus05-ydrv.sfs'.

[dimkr]

So every time you save, a new archive is created, for just the files that need to be transfered to the next boot.

If so, does this mean that the entire browser cache (both changed and unchanged parts) gets compressed and written to the drive each time I save?

[gyrog]

If so, does this mean that the entire browser cache (both changed and unchanged parts) gets compressed and written to the drive each time I save?

In the current implementation, no.
BUT even here, what files are excluded is defined in a text file:

Code: Select all

filterFFN="$HOME/.config/save-exclude.lst"

this is used by grep on the list of all files in 'pup_rw':

Code: Select all

 | grep -v -f "$filterFFN"

so a user could include the cache if so desired.

'savesession-archive' is the gate-keeper, in the long run it depends on how "smart" it is programmed to be.

Including the cache could be a bit confusing if you only do a save every now and then.

Having used this thing for a while now, the speed of a save, and subsequent reboot are not terribly important to me,
since I do it very infrequently, only when I make changes to Puppy itself, that I want to keep.
Most of the files I "work" with are outside the Puppy overlay, so they don't come into play.
For me that incudes the browser cache.
And that's why I prefer "portable" apps over ".sfs" files, over ".pet" files, or ".deb" files ...etc..

[gyrog]

The 'pm66plus' utility has a GUI, but it is started with a terminal command.

It has 7 facilities, but it only shows buttons for the ones it can do in the current environment.
If you run 'pm66plus' in a normal Puppy, it will say "There is nothing to do here.".

The facilities are:

1) "Switch to use a save${saveType}", where ${saveType} can be "folder", "file" or "sfs".
This only appears if you are running in "archive" mode, and a "save" has been detected.
It reboots into "layer" mode, without saving the current session.

2) "Switch to use save archive"
This is shown if you are running in "layer" mode, and a "PARKED" "archive" mode tar file has been detected.
It reboots into "archive" mode, without saving the current session.

3) "Make a savefolder"
This is shown if you are running in "archive" mode and no "save" has been detected.
Makes a savefolder and then reboots into "layer" mode, without saving the current session.

4) "Make a savefile"
This is shown if you are running in "archive" mode and no "save" has been detected.
Makes a savefile and then reboots into "layer" mode, without saving the current session.

5) "Make a savesfs"
This is shown if you are running in "archive" mode and no "save" has been detected.
Makes a savesfs and then reboots into "layer" mode, without saving the current session.

6) "Enable copy-to-RAM"
This is shown if Puppy was booted with "pfix=fncopy" and "copy-to-RAM' is currently disabled.

7) "Disable copy-to-RAM"
This is shown if Puppy was booted with "pfix=fncopy" and "copy-to-RAM' is currently enabled.

Note:
"archive" mode means pupmode=66
"layer" mode means pupmode=13

[gyrog]

pm66plus version 06 is available.

Previous versions all had a flaw, the "backend" did not handle multiple savefolders/savefiles well.
So, this version represents a significant rewrite of the "backend".

Changes:

1) All "saves" contain the same set of files i.e. "normal" files, empty directories, and symbolic links.
Whiteout files are always processed using a separate tar archive. These whiteout archives persist.

2) Multiple savefolders/savefiles are supported, updates are always applied to the savefolder/savefile in use when they were generated.

3) On every boot any outstanding tar archives pertaining to any savefolder or savefile, are processed.
So if you switch from running in "layer" mode to running in "archive" mode,
by the time you get to a running Puppy, all saved data is in the savefolder/savefile.

4) The utility is now called "SaveManager", although the script is 'saveman'.
It now has a .desktop file, so it should appear in the "Setup" menu.
All it's facilities result in a reboot on sucessful completion.
If you choose to save the current session, it is saved to the current save mechanism.

To try this updated version:

Download 'pm66plus06_local-initrd.gz' and 'pm66plus06-ydrv.sfs' from https://www.mediafire.com/folder/hutn1c5w6g9e7/pm66plus
Move both files into a fresh Puppy frugal install directory.
(I used FrugalPup for the install, if you do the install some other way, you need to ensure that the 'grub.cfg' menuentry includes support for a 'local-initrd.gz').
Rename 'pm66plus06_local-initrd.gz' to 'local-initrd.gz'.
Rename 'pm66plus06-ydrv.sfs' to an appropriate ydrv...sfs filename for the Puppy. e.g. 'ydrv_s15pup64_22.12.sfs'
Reboot.

Filenames:

In "archive" mode (pupmode=66):
Whiteout files are written to ${DISTRO_FILE_PREFIX}save_66ram.tar
Other saved files are written to ${DISTRO_FILE_PREFIX}save_66.tar
To switch away from "archive" mode, ${DISTRO_FILE_PREFIX}save_66.tar is renamed ${DISTRO_FILE_PREFIX}save_66_PARKED.tar,
so the 'init' script will not find it, and hence find the savefolder/savefile/savesfs.
e.g. s15pup64save_66ram.tar, s15pup64save_66.tar, and s15pup64save_66_PARKED.tar

In "layer" mode (pupmode=13):
The filenames are generted by extracting the base filename of the current save from the ${PUPSAVE} variable in /etc/rc.d/PUPSTATE.
This is so 'init' can match the files written on shutdown with the particular save in use at the time.
Whiteout files are written to ${PUPSAVE##*/}_13ram.tar.
Other saved files are written to ${PUPSAVE##*/}_13.tar.
A list of filenames to delete from ro1 is generated, named ${PUPSAVE##*/}_13remove.lst
e.g. s15pup64save.4fs_13ram.tar, s15pup64save.4fs_13.tar, and s15pup64save.4fs_13remove.lst

Except if a savesfs is being used:
Whiteout files are still written to ${PUPSAVE##*/}_13ram.tar.
But a new savesfs is written with the ".sfs" replaced with "_NEW.sfs"
e.g. s15pup64save.sfs_13ram.tar, and s15pup64save_NEW.sfs

What happens from here:
pm66plus is at a stage where it's good enough for me to use.
So, if I'm going to be the only user of pm66plus, then there is no point in further development.
(Although I'll probably replace the jammypup...zip with one including this version.)

[gyrog]

I have uploaded 'JammyPup32-22.04-230923-66plus.zip' and removed the previous one.

[Clarity]

...7) There could be an "archive location" concept introduced to Puppy.
This would be a partition dedicated to having save archive files written to it.
If it is on a different partition to the "save location" then the "save" partition could be remounted RO by 'init'.
The 'savessession-archive' process would mount and umount this partition.
This would enable a Puppy running with a "save" to approach the robustness of pupmode=5 in relation to sudden shutdowns.
...

The objectives shared here in this thread by the OP, are very reasonable.

Scenario
As many already know, KL employs a mechanism that I have used with WoofCE PUPs for years, OOTB. (I've mentioned KL because their boot stanzas support a partition arrangement for session management...even as I know that their INIT/SHUTDOWN operations are different.)

I keep ALL save-sessions on a dedicated Linux partition (namely "Persistence"), within it, it has a folder for the individual WoofCE PUP distro's sessions named "Sessions".

Over the years I have found that your SAVESPEC has worked in recent time for all new generated WoofCE session. Within the SAVESPEC identifies the 'location' for discovery & saving of session info for the running distro.

Question
Does this item 7 you reference suggest that the current arrangement can continue and could support Archives OR are you recommending a completely different partition from the one used that I name Persistence?

Thanks @gyrog, AGAIN, for all your efforts in maturing these 2 areas of WoofCE distros for session management.

[gyrog]

Does this item 7 you reference suggest that the current arrangement can continue and could support Archives OR are you recommending a completely different partition from the one used that I name Persistence?

Something different.

In the normal aufs pupmode=13, the savefolder gets written to every time the "save" button is clicked, and/or at shutdown, so the partition containing it remains mounted RW.
In pm66plus, the savefolder is only written to during 'int', never during the running system, even at shutdown.
When the "save" button is clicked, and/or at shutdown, an appropriate subset of the files in RAM are copied to a tar archive file.
During 'init' the savefolder is updated using the tar archive file.
So the possibility exists, if the "save location" is separated form the "archive location", then the partition containing the "save location" could be remounted RO in 'init' after the savefolder has been updated, (it already does this for savefiles in the current version).

The idea is for those who are paranoid about their data being lost in a power failure.
In the running system, your data in the savefolder would be "safe" on a partition mounted RO, very unlikely to be corrupted.
The tar archives would be written to a different partition mounted RW, which might become corrupted. But then only the currrent session is lost.

I can imagine haing a "never-backedup' partition that contained the save tar archives, and the downloads, and the browser caches etc...,
all the stuff I like to have, but I really don't care much, if it is lost.

Note: I have not implemented this idea.