Clarity wrote: ↑Fri Dec 30, 2022 7:42 am... in same BOOTISO folder and get w_changes=RAM2 ...
Assume you have
a linux partition names Persistence AND you have a folder Sessions where you want all of your KLV persistence to land
Should it be advised to save "w_changes=" to that disk label versus allowing it to default to the BOOTISOS folder? Thus a boot-time edit of the boot stanza's line to 'direct' the boot process of where to find its 'persistence'.
ON another note when a new PUPPY is booted and it finds old persistence for a prior version, the user will be offered the option to upgrade the old persistence for use with the new. Although I haven't tested this in KLV, can I assume it, too, offers similar upgrades when booting a new version and it find the old session? (THIS IS NOT a request to make KLV behave in Puppy fashion, merely a request of current behavior)
I haven't tried in SG2D as yet, but I think it is already possible to boot-time edit the grub config via w_changes to put save persistence anywhere on a system via LABEL or UUID and specified folder name.
You then need to also add a w_changes1=RAM2 to specify you want that RAM2 mode (i.e. w_changes itself being used to state location and w_changes1 to state the RAM mode).
For example:
Code: Select all
w_changes=LABEL=Persistence=/BOOTISOS w_changes1=RAM2There is no function in FirstRib initrd that automatically somehow detects an existing 'old persistence' when booting any new distro. You should remember that FR initrd, being on-purpose-generic-design can boot almost any distro root filesystem, no matter how that distro does things so there is no easy way of determining if an existing save persistence folder (upper_changes) was from other distro. I wouldn't want to complicate the efficient FR initrd code in an attempt to make and detect some kind of distro- version stamp. Puppy initrd is not a generic initrd meaning that it is designed purely to boot Puppy and has code in it that directly relates to config files held in its main root filesystem - some of these config files can store puppy name and version number of course so new versions can be checked. But FR initrd doesn't need or want any distro-root-filesystem-specific config information since that would destroy its great ability to boot almost any distro - one of its strengths is its generic ability to boot anything and, to a large extent, not care about the root distros internal config files.
In fact, as has been demonstrated many times, FR initrd can even boot Puppy's root filesystem sfs files (via removing their alphabetic nature and changing these to 2-digit numeric filenames like any First Rib based distro). But unlike with most mainstream distros, Puppy causes a problem in that it does has special config files that it expects the initrd to look after (since Puppy initrd is closely tied coding wise to its main root filesystem). In practice, First Rib initrd still succeeds booting Puppy distros, but requires a few 'tweaks' to workaround a couple of matters relating to Puppy's unique way of doing things (and of course a FR booted Puppy no longer behaves like Puppy since it uses overlayfs and not aufs and does not know or care about Pupmodes but instead uses w_changes and so on; In fact the FR initrd booted Pup has same big advantages of any FR initrd booted distro: if desired can use any of the sfs files in unsquashed normal directory form, and also arrange the topmost sfs to become a read/write uncompressed upper_changes layer (not quite a pseudo full install in Puppy case, but half way there, and also have up to 99 sfs and/or uncompressed addon layers since not limited to a few alphabetic named sfs addons - changing layer order simply a matter of changing what 2-digit number used in the filename...).
