Puppy Linux Discussion Forum

Laast night I decided to do a little experiment.

As Kennel Linux releases have various ways of accessing the root file system in a running an installation. One of the methods being Pseudo Full Install. In this type of installation the rootfs is copied the the upper changes layer, not requiring to have a rootfs layer(doesn't even require a dummy rootfs layer). The writing to the upper_changes directory can still be controlled and saved or not saved as desired.

As the dpupbw64save directory contains an upper directory for changes, I decided to make a new install, where the puppy_dpupbw64_10.0.9.sfs is extracted and the resultant directory being renamed to upper within the dpupbw64save. To accomplish this install, DPupBW64 still requires a puppy_dpupbw64_10.0.9.sfs. I did a bit of swapping, using a save folder containing only basic initial setup details, timezone, wifi network setup. I edited the save folder then ran mksquashfs. Basically reversing the normal process, this was just for expedience, I could have just created some sort of dummy puppy_dpupbw64_10.0.9.sfs.

The resultant install runs the same as my normal frugal install. As part of the experiment I updated the included Firefox ESR 128.5.2 to the new version 128.7.0. Saves and boot/reboot working well.

I don't see my self changing to use this method on a regular basis, just playing with Puppy.

TerryH wrote: Wed Feb 05, 2025 8:47 pm

Laast night I decided to do a little experiment.

As Kennel Linux releases have various ways of accessing the root file system in a running an installation. One of the methods being Pseudo Full Install. In this type of installation the rootfs is copied the the upper changes layer, not requiring to have a rootfs layer(doesn't even require a dummy rootfs layer). The writing to the upper_changes directory can still be controlled and saved or not saved as desired.

As the dpupbw64save directory contains an upper directory for changes, I decided to make a new install, where the puppy_dpupbw64_10.0.9.sfs is extracted and the resultant directory being renamed to upper within the dpupbw64save. To accomplish this install, DPupBW64 still requires a puppy_dpupbw64_10.0.9.sfs. I did a bit of swapping, using a save folder containing only basic initial setup details, timezone, wifi network setup. I edited the save folder then ran mksquashfs. Basically reversing the normal process, this was just for expedience, I could have just created some sort of dummy puppy_dpupbw64_10.0.9.sfs.

The resultant install runs the same as my normal frugal install. As part of the experiment I updated the included Firefox ESR 128.5.2 to the new version 128.7.0. Saves and boot/reboot working well.

I don't see my self changing to use this method on a regular basis, just playing with Puppy.

I could definitely see myself using this method, because one of the first things I do with a KL is build a new appication packed rootfs from a psuedo-full install. But I always keep puppies on hand for things like what happened yesterday. That is python eliminated a module that my favorite audio tag editor needs to run, and since I update my KL's frequently, the newer python broke this app of mine called puddletag.

So I fired up dpupbw64 and installed puddletag, which it of course ran because the module was there. I should do a psuedo full install of dpupbw64 and resquash a version of it for myself loaded with my audio packages.

geo_c wrote: Wed Feb 05, 2025 10:44 pm

I could definitely see myself using this method, because one of the first things I do with a KL is build a new appication

In the other discussion concerning the use of alternative savefolders (vs backups) you mention methods of using pupsaves to "build up" a working system.
Does this puedo method in a puppy with /upper have any plusses or minuses over building the puppy way with saves?

williwaw wrote: Thu Feb 06, 2025 8:50 pm

geo_c wrote: Wed Feb 05, 2025 10:44 pm

I could definitely see myself using this method, because one of the first things I do with a KL is build a new appication

In the other discussion concerning the use of alternative savefolders (vs backups) you mention methods of using pupsaves to "build up" a working system.
Does this puedo method in a puppy with /upper have any plusses or minuses over building the puppy way with saves?

I would say not especially more effective. Even in KL's, after a couple years of habitually updating my psuedo-full install and resquashing, I decided instead to simply periodically squash upper_changes layers, as the only real disadvantage is size. In other words, older packages are present in the rootfs, and newer packages in usr/lib in the squashed layers. So I do a psuedo full install to build a super packed audio/media rootfs, and then run it for about three months, adding a package here or there, new configs etc, and then just squash that upper_changes into a numbered layer which can be easily migrated to new machines and link to multi-instances.

But I do it that way to take advantage of the KL numbered layering structure, doing things like numbering the squashed upper_changes as 20_layer, 21_layer, but then having uncompressed local config layers tailored to each install/instance and machine, those being number 50_layer, etc. never being overwritten by the squashed upper_changes layers.

The way puppy works, this isn't really necessary, because the save is always the upper layer, and adding it to the read-only mix requires naming it one of the alphabet.drv layers.

So there a lot of ways to skin this cat, both in puppy and in KL's, though the methods are slightly different.

The choice for me has to do with what things to store in compressed read-only layers, and what things to maintain in the writeable save, and what things to store in uncompressed local layers.

What makes sense for me in say a dpupbw64 psuedo-full install would be creating a read-only audio packed system that wouldn't be easily corruptible, while using the pupsave for more temporary daily stuff. So rather than build this massive pupsave, and having to "roll-back" if something goes south, instead I simply try stuff out in the save, if I like it, then add it to the psuedo-full install and resquash, delete the pupsave and start a new one, try some more stuff out.

williwaw wrote: Thu Feb 06, 2025 8:50 pm

geo_c wrote: Wed Feb 05, 2025 10:44 pm

I could definitely see myself using this method, because one of the first things I do with a KL is build a new appication

In the other discussion concerning the use of alternative savefolders (vs backups) you mention methods of using pupsaves to "build up" a working system.
Does this puedo method in a puppy with /upper have any plusses or minuses over building the puppy way with saves?

Personally I don't see an advantage doing it this way with Puppy. It was actually the pupsave backup thread, prompted me to try doing this. It makes maintenance of backups more critical, as if you do something that corrupts, your whole system is gone. After I set it up and ran for a day, I ran pupsave backup and selected to compress the save folder using xz compression. I have reasonably fast NVME drive, the compression took ages to complete. I actually thought something may have been wrong. Conky was displaying activity, so I just waited for it to finish. I'd hate to be doing it on any slower drives.

TerryH wrote: Fri Feb 07, 2025 3:15 am

It makes maintenance of backups more critical, as if you do something that corrupts, your whole system is gone.

Thats a good point Terry. I guess learning how to make sfs's to load when needed would be more useful.

I'd hate to be doing it on any slower drives.

was your save extremely large?

TerryH wrote: Fri Feb 07, 2025 3:15 am

Personally I don't see an advantage doing it this way with Puppy. It was actually the pupsave backup thread, prompted me to try doing this. It makes maintenance of backups more critical, as if you do something that corrupts, your whole system is gone. After I set it up and ran for a day, I ran pupsave backup and selected to compress the save folder using xz compression. I have reasonably fast NVME drive, the compression took ages to complete. I actually thought something may have been wrong. Conky was displaying activity, so I just waited for it to finish. I'd hate to be doing it on any slower drives.

Yes, I don't use a psuedo-full install as a daily driver when it comes to KL's. I only use it to build a new rootfs. Then once it's sqashed I use another instance with the squashed rootfs. Actually I use the KL multi-instance approach. This way the system is never tanked, and backups of the upper_changes are only for the most recent changes using @fredx181's backup-restore-sys script. If I were to tank the psuedo-full install, then I could simply unsquash one of the daily driver rootfs layers.

williwaw wrote: Fri Feb 07, 2025 6:56 pm

TerryH wrote: Fri Feb 07, 2025 3:15 am

It makes maintenance of backups more critical, as if you do something that corrupts, your whole system is gone.

Thats a good point Terry. I guess learning how to make sfs's to load when needed would be more useful.

I'd hate to be doing it on any slower drives.

was your save extremely large?

No, I'm not on the laptop at present, but not much more than the extracted puppy_dpupbw64_10.0.9.sfs. It compressed down to 598 MiB, so probably would be less than 2GiB