Keep your savefile slim and healthy

[mikeb]

do you use the app-dirs?

what errors do you get when you try and copy them?

Might be a union/rox quirk

mike

[rufwoof]

do you use the app-dirs?

Yes. Only today I created yet another for Libre 4.2.3 so that all the config and application files/libs are all within the app-dir (portable Libre that can be opened up with all changes preserved (persistence) even when booting using different versions of Puppy). I'm tending towards having a very small boot CD - that boots to a lean desktop, and have all the other extra's loadable via app-dirs.

However no longer a problem as I tried a reboot and all went well thereafter.

I guess with all the trying things out the messing around it probably caused some kind of lock that the reboot cleared. The test file (app) was a compress PET and maybe I kicked it off in the background and it might have been running waiting for a input, but not visible (I guess I should have had a look around with ps, but I didn't think to do that).

No matter what, the reboot fixed the problem.

Just playing around now. Setting up one desktop with nearly empty pup_rw (banking mode with brand new version of Puppy and Firefox each time), another for office - different desktop background and apps loaded, another for multimedia (yet another desktop background, icons and set of apps) and jumping between each 'savefile' version within seconds using the exit X, run script, xwin restart.

Really neat! Most impressed.

Compression is slower to create (make a snapshot) than to restore (switch to a snapshot). So either way (copying as-is or using compression) seems to work as equally as well as each other AFAICT. Getting late however so I'll look to firm up the scripts etc another day. Off to have a beer to celebrate. Thanks yet again.

[totolanio]

How to decrease savefile size plz ?

[mikeb]

How to decrease savefile size plz ?

you can use the resize2fs command on the unmounted save file specifying the new size...make sure its still big enough for what it contains. see the hlep/man page.

Mike

[totolanio]

How to decrease savefile size plz ?

you can use the resize2fs command on the unmounted save file specifying the new size...make sure its still big enough for what it contains. see the hlep/man page.

Mike

Ok I'll try, hope it's not hard

[mikeb]

ok say your save file is on /mnt/sda2 and called pupsave.2fs

run puppy with pfix=ram so the save is not used.
Open a terminal/console

type and enter

resize2fs /mnt/sda2/pupsave.2fs 512M

will resize to 512MB......

its a good idea to run
fsck /mnt/sda2/pupsave.2fs before and after to run a file system check.

Please do make a copy of the save file before doing this just in case....

mike

[nic007]

What's the point of having a big save file? Probably the worst option one can follow when using Puppy. It just does not make sense. No save file or very small (not bigger than 60Mb) is the way to go. I tend to not go bigger than 32Mb on the odd occasion I use one. Basically only use it for the odd alteration like swopping desktop images. Never use it to install applications or store data. Just a waste of space.

[rufwoof]

What's the point of having a big save file? Probably the worst option one can follow when using Puppy. It just does not make sense. No save file or very small (not bigger than 60Mb) is the way to go. I tend to not go bigger than 32Mb on the odd occasion I use one. Basically only use it for the odd alteration like swopping desktop images. Never use it to install applications or store data. Just a waste of space.

My remaster puppy script is two clicks, 30 seconds run time, forms puppy sfs, merges that into initrd and ouputs the new larger initrd directly to where grub4dos expects to find it.

Firefox and documents etc all stored outside of puppy, so any changes persist across reboots (portable firefox) and I don't change the core puppy that often. Additional programs - I load as sfs's. For each sfs I have a wrapper script that sym links the config directory/file(s) from /root (inside puppy) to outside of puppy (so program config changes preserved across reboots).

boot ram with no save file, and don't miss not having a savefile. Like the benefit of a read only puppy, pristine exact same each and every reboot, as that way I can try things out and when whatever I was trying results in a crashed puppy, reboot and back to normal again. With full installs I tend to find that a crashed system rarely coincides with having made a recent backup copy.

[mikeb]

Me save sfs vary from 10 - 60MB in use.... that's uncompressed.
I do no linking out to anywhere except thunderbird profile (not linked out but the profile location is changed as per the mozilla recommended way) which is shared with windows. I used to but it gets so messy.

I don't like software that likes to dump huge profiles and leftovers.
sfs use for any additional software...not just the big stuff.
Never use pets unless testing one for someone....then its as ac ase of not saving at shutdown...more convenient than pfix=ram since you dont have so set things up each time... great for compiling too with the no save at shutdown.

A 30mb save sfs takes a fraction of a second to backup ( or simply renamed when created)..everything else is read only ...well so is the save for that matter. Linux is simply more reliable that way since there are no mechanisms to check and fix the system files.

KISS

mike

ps I always miss at least one thing when I remaster Also sfs much easier to update/fix/tinker with individual applications...

[sheldonisaac]

My remaster puppy script is two clicks, 30 seconds run time, forms puppy sfs, merges that into initrd and ouputs the new larger initrd directly to where grub4dos expects to find it.

May I try that script? I've not sucessfully done a remaster; perhaps I'm timid or stupid.

Thanks,
Sheldon
(primarily LuPu Super2 frugal)

[totolanio]

ok say your save file is on /mnt/sda2 and called pupsave.2fs

run puppy with pfix=ram so the save is not used.
Open a terminal/console

type and enter

resize2fs /mnt/sda2/pupsave.2fs 512M

will resize to 512MB......

its a good idea to run
fsck /mnt/sda2/pupsave.2fs before and after to run a file system check.

Please do make a copy of the save file before doing this just in case....

mike

Ok thank you, simple as that ! I'll do it !

Well I chose a big savefile because I'm not used to use SFS etc, but I'll try to do it as soon as possible !

[rufwoof]

My remaster puppy script is two clicks, 30 seconds run time, forms puppy sfs, merges that into initrd and ouputs the new larger initrd directly to where grub4dos expects to find it.

May I try that script?

Sorry but its my own Puppy specific. Heavily edited remasterpup2 to strip most of the interactions and alot of the code, replacing with more or less just copying of etc and root. I also pull in the CD files from internal copies rather than having to prompt for a CD or CD image. One click to launch, another to select where to form the puppy sfs and it runs to completion, leaving a new initrd.lzo ready for the next reboot. Its quick because I don't use any puppy compression.

I've dropped in the Slacko 5.7 kernel into my Slacko 5.3.3 to further complicate matters. The later kernel detects newer hardware and my Puppy includes a PXE server for booting local Windows PC's over the net/lan.

The core of the scripts working to merge puppy sfs into initrd looks like

Code: Select all

mkdir $TARGETDIR/puppylivecdbuild/newdir
cd $TARGETDIR/puppylivecdbuild/newdir
rm $TARGETDIR/vmlinuz
cp -avr /usr/sbin/REMASTER/ISO-FILES/vmlinuz $TARGETDIR/vmlinuz &
zcat ../initrd.gz | cpio -id                               # Extract initrd content
mv ../puppy*.sfs .                                         # Copy in puppy sfs
find | cpio -o -H newc | lzo -c1 > $TARGETDIR/initrd.lzo   # Reform the initrd
mv puppy*.sfs ../.                                         # 2 moves quicker than copy
cd ..
sync
rm -rf $TARGETDIR/puppylivecdbuild/newdir

Which follow on from remasterpup having created puppylivecdbuild directory contents. You could run remasterpup2 (normal remaster) to create a puppylivecdbuild folder content and then use the above as a guide of how puppyxxx.sfs gets inserted into initrd and is then reformed.

I always include zdrv in with puppy by default when remastering, so that initrd holds everything. vmlinuz boots ... kicks of init inside initrd which sets the PC up and then loads puppy sfs. all drivers, firmware etc all contained in the one file, so only vmlinuz and initrd.lzo needed to boot. initrd is compressed (which includes the puppy sfs within it) using a fast compression method (lzop -1) which typically takes around 8 seconds to compress initrd with puppy sfs included inside that.

I'm happy with my puppy desktop so I don't change it that often and when I do want to mae a change I clean boot the desktop without loading any sfs's (otherwise they'd get incorporated into the new puppy), make the desired change and then remaster so that subsequent boots pick up those changes.

[mikeslr]

I'm not certain if a prior post mentioned jpeg's instructions, so I am. You'll find them here: http://murga-linux.com/puppy/viewtopic.php?t=81911.

Pups operate entirely in RAM. That is, they decompress and then merge into RAM the compressed files which were included in your Pup's ISO, your SaveFile, and any SFS you've loaded. When you shutdown/reboot whatever had been in RAM is gone unless it's been written to "storage".

There's no reason for you to ever unintentionally save anything, which is what automatic Pupsave does. You can always intentionally save data to your home-partition and to any other intentionally mounted partition.

Without Pupsave working automatically, you can safely "extinquish" newly installed pets which haven't worked, or have generated conflicts. Just shutdown/reboot without saving. Until you save, the pet only exists in RAM; it hasn't yet been written to storage such as your SaveFile. Uninstalling a pet which has been written to your SaveFile runs the risk of unintentionally uninstalling some library or other file existing in your SaveFile needed by some other application you installed. E.g. Application XYZ you installed requires library xyz. XYZ worked well. Then you installed application ABC which also contains library xyz. ABC's xyz overwrites XYZ's library xyz. When you uninstall ABC is removes library xyz, leaving ABC broken.

And removing Automatic Pupsave increases the security of your operating system. Malware you may have picked up while surfing the net also only exists in RAM until written to storage.

For added security, where possible, apply MochiMoppel's instructions for modifying Puppy Package Manager to download pets without automatically installing them. http://murga-linux.com/puppy/viewtopic.php?t=96589. Pets are compressed files unlikely to be contaminated. If you have any question regarding malware you may have pickup while surfing, download the desired pet but don't install it. Reboot without saving "RAM to SaveFile". On bootup up, install the pet(s) and execute a manual Save.

The foregoing is not a complete solution. Just an easily applied added precaution.

mikesLr

[mikeb]

Pups operate entirely in RAM.

This is only partially true...indeed addition sfs are not necessarily loaded to ram at all.

For usb the current session is in ram but the save file is not... the ram session is saved at shutdown and periodically... seems like this is what you are talking about and in this case you can opt to not save iff you add an addon script.

For hard drives and other fast media there is no ram for changes...the save file is used exclusively so any changes are instantly added.

Multisession is the only official load to ram and not save option...there is no save file.

Just wanted to clarify this so hard driver users are not looking for the dont save options.

mike

[Jasper]

Multisession is the only official load to ram and not save option...there is no save file

Multisession [Multi-session live-CD/DVD] can save to dated save folders. That's why it's called "multisession".

Multi-session live-CD/DVD seems to lack Forum popularity, yet:

* it is unique to Puppy and Linux (though not every pup has it) and with a working optical drive it is easy to setup and run

* it is the only boot option which can provide a full audit trail of changes incorporating all session-to-session additions, amendments and deletions over an extended period of time (if continuation disks are used as needed)

* it is notedly secure and it also has unrivalled recovery from errors, viruses or unwanted amendments.

It is obviously not for everybody and I have read it's best suited to desktop computers. However, with sufficient RAM and especially if using a rewritable DVD/CD, it is cheap and easy to try many Pups.

[mikeb]

Multisession [Multi-session live-CD/DVD] can save to dated save folders. That's why it's called "multisession".

perhaps my wording was not clear enough..'and have a not save option' might be more clear.

In other words it truly loads all to ram including saves (sfs part only if enough ram) ..... and there is no persistent save file on a hard drive/usb. It inherently, and as part of the system has a no save option. My point was usb DOES have a save file which is mounted in use...just has the extra tmpfs for session changes which then gets merged. Hence the inability to remove the usb flash stick. The impression was given that puppy loads to ram saves and all regardless of mode...which is not the case EXCEPT for multisession. PUPMODE=13 was designed reduce save file writes rather than be independent of one.

Another thing mentioned was decompressing of sfs.... not so...only the required data read is decompressed on the fly when needed but the sfs remains the same size sat in another tmpfs.

Thing is if talking about the system and optimising then it needs to be clear what the system is including my wording of it
Its important to know what goes where....

There is a nice set of diagrams of the various modes somewhere.... a picture definitely paints a thousand words.


As an aside the sfs save method I made is based on multisession's total ram approach but usable on flash and hard drives. In other words achieve what all these hacks with PUPMODE=13 are trying to do...ie be free of ANY drives once booted and discard all at the end if desired.

mike

[rufwoof]

Doesn't pupmode 5 also have a 'not save' option?

[mikeb]

well I suppose so.... thats meant to be the first run mode before choosing a save option so I suppose its intended as a one off..... some use it as a ram only no save option.

sfs save basically runs in pupmode=5....

I feel hairs getting split

I was just referring to 'official' puppy usage rather than the wild and wonderful methods many here use

mike

[rufwoof]

Just mentioned it because I run pupmode 5 all of the time and modified the shutdown code to skip asking whether to create a savefile or not (defaults to not) i.e. I run with no savefile and just remaster any changes I want preserved across reboots (increasingly infrequently). I now have all of the sfs's that I use regularly saved inside the puppy sfs (and I drop puppy sfs into initrd), so initrd holds everything and is loaded into ram at bootup. I've dropped using a swap partition as well, so nothing touches the disk at all - except a remaster if I use the HDD as a temp storage area (or if I intentionally mount a drive).

Can't recall the exact detail without looking, but seem to remember seeing/reading a suggestion of switching from pupmode 5 to pupmode 12 I think it was - as part of shutdown to equally not save. (I think it was because that would be assumed to already have been saved - or something like that ??? Or could have been pupmode 13 ???).

[mikeb]

wouldn't it be nice to have saved configs and data and changes all in ram with option to not save whenever you want and all done automatically and with no need for a symlinks or other such methods ...

oh it is....

yes mode 12 would do nothing at shutdown.

PUPMODE=13 should have been dropped / replaced many moons ago.

You have to break away from puppies ways... its essential.

Mike