Keep your savefile slim and healthy

How to do things, solutions, recipes, tutorials
Message
Author
User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#91 Post by mikeb »

IMO, it sucessfully addresses one of a frugal Puppy's biggest shortcomings (
well specifically its working around the shortcomings of snapmergepuppy used for usb installs ONLY to copy the tmpfs pup_rw to the save file. PUPMODE=13 relies on code that does not really do its job properly and this is one example. Not sure if its that related to the thread ,either rewrite snapmergepuppy or scrap mode 13 altogether and replacing it with something better would be a more appropriate topic.

And well yes no real protection against a full save file and no real attempt in the default releases to reduce save file usage either. Here is a system with a shortcoming, here is a set of apps to make sure it fails at some point by over using it (ie not doing some of th ethings mentioned here) , and lets not have any protection is not a good design strategy really.

mike

timothyli
Posts: 65
Joined: Sun 22 Jun 2008, 07:44
Location: Toronto, Canada

#92 Post by timothyli »

A strategy that works for me is to avoid having a savefile all together because I have enough RAM (4G) and I use the cloud (Google Drive/Dropbox) and seldom save stuff locally.

I edit puppy_precise_5.7.1.sfs using editsfs.pet to....

1. bypass firstrun screens/2-barks:
> create symlink /etc/localtime to my specific timezone /usr/share/zoneinfo/America/Toronto
> create blank file /etc/personal_settings_popup_disabled
> comment out the 2-barks and welcome statements in /usr/sbin/delayedrun script
> edit /etc/xdg/template/jwmrc menu to execute "busybox reboot" and "busybox poweroff" during shutdown.

2. Add software (google-chrome and firefox in my case) and app settings/files (e.g. additional fonts, /root/.mozilla, /root/.config/google-chrome) to puppy_precise_5.7.1. sfs

3. If you've made changes to your desktop icons you will need to write the changes to puppy_precise_5.7.1.sfs also. Desktop settings are in /root/choices/ and /root/.config/

4. Configure bootloader to boot puppy with "pfix=ram"

This way, puppy will boot up entirely in RAM without firstrun popup & 2 barks, already setup for use.

It runs lightning fast because everything is in RAM.

When you reboot/shutdown, it will do it right away without prompting for a savefile.

You get a pristine copy of puppy everytime you reboot.

For me, I found it is the most efficient and cleanest way of using puppy.

timothyli
Posts: 65
Joined: Sun 22 Jun 2008, 07:44
Location: Toronto, Canada

slim savefile

#93 Post by timothyli »

A strategy that works for me is to avoid having a savefile all together because I have enough RAM (4G) and I use the cloud (Google Drive/Dropbox) and seldom save stuff locally.

I edit puppy_precise_5.7.1.sfs using editsfs.pet to....

1. bypass firstrun screens/2-barks:
> create symlink /etc/localtime to my specific timezone /usr/share/zoneinfo/America/Toronto
> create blank file /etc/personal_settings_popup_disabled
> comment out the 2-barks and welcome statements in /usr/sbin/delayedrun script
> edit /etc/xdg/template/jwmrc menu to execute "busybox reboot" and "busybox poweroff" during shutdown.

2. Add software (google-chrome and firefox in my case) and app settings/files (e.g. additional fonts, /root/.mozilla, /root/.config/google-chrome) to puppy_precise_5.7.1. sfs

3. If you've made changes to your desktop icons you will need to write the changes to puppy_precise_5.7.1.sfs also. Desktop settings are in /root/choices/ and /root/.config/

4. Configure bootloader to boot puppy with "pfix=ram"

This way, puppy will boot up entirely in RAM without firstrun popup & 2 barks, already setup for use.

It runs lightning fast because everything is in RAM.

When you reboot/shutdown, it will do it right away without prompting for a savefile.

You get a pristine copy of puppy everytime you reboot.

For me, I found it is the most efficient and cleanest way of using puppy.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#94 Post by mikeb »

Fully agree timothyli ..have not used a save file for years ( a save sfs for persistent changes loaded to ram) but regardless of yer methods its still worth taking steps to reduce the system space usage since that still has to work withing the limitations of save file/RAM/cloud so the information in this thread is useful generally.

mike

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#95 Post by greengeek »

mikeb wrote: ( a save sfs for persistent changes loaded to ram)
Do you mean that you have an sfs which contains specific personal and/or configuration information, and that you just overlay that over the main sfs? Could that contain things like wifi password and connection scripts?

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#96 Post by mikeb »

Well pup_rw is saved at shutdown as an sfs and its loaded back into pup_rw at boot... so works like any other save.

One option would be to create such an sfs of initial settings and use it like and sfs but standard puppies are not friendly towards doing this

mike

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#97 Post by rufwoof »

pup_rw is saved at shutdown as an sfs and its loaded back into pup_rw at boot... so works like any other save.
But selectively copied - as I understand it.

If I open a ROX looking at /initrd/pup_rw/root and another looking at /root, and I create a new file in /root, it also shows in /initrd/pup_rw/root. Delete it from root and it deletes from the initrd version also. i.e. /initrd/pup_rw reflects all changes made to the 'fixed' original boot image version.

But when I tried copying all of /initrd/pup_rw prior to shutdown and copied it all back again upon restarting, it didn't work out well - as that would be all temp files etc.

I like the idea - but stumble with knowing which bits to copy/preserve and what not to. My guess is that it might be ok to copy/restore initrd/pup_rw/

bin
etc
lib
mnt
opt
root
sbin
usr
var

and leave out the rest (initrd, proc, sys, tmp). But I suspect there's probably bits within the above that also shouldn't be preserved/restored ?

I'm not too bothered with preserving the /initrd/pup_rw/xxx saved copy as a sfs and I'm happy to have it saved as a simple straight copy (plenty of disk space so I've no need to use/store in compressed format). So I can see how it could all be just a single script containing a series of copy commands (i.e. at shutdown cp /initrd/pup_rw/root sda4:/savearea/root ...etc, at start up cp /sda4/savearea/root /initrd/pup_rw/root ...etc). But the bottom line is I don't know what to copy or not.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#98 Post by mikeb »

Well as mentioned I dont compress it...its faster that way. I did use tar but the initrd tar I used was too flaky.

Which folders... well i do the same as pup does elsewhere....
I exclude /proc /initrd /var /tmp /mnt /dev /sys

note this is done during rc.shutdown so X is not running...if you did it when X is running then .xloaded and perhaps one or 2 others need deleting...see the save file backup utility.

mike

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#99 Post by rufwoof »

It would be really useful for me if I got that working. Currently I always liveCD boot and reboot to CD only mode (pfix=ram) when online banking, so just the fixed (pristine) read only CD puppy version and a fresh/new browser, go just to bank web site, shutdown and reboot afterwards back into 'normal' mode.

I can see however that with the copy approach you could have two copies, one for the 'bank' mode and another for 'normal' mode and switch between the two in the time it takes to copy those images into /initrd/pup_rw (i.e. a lot faster). The only issue then is that memory isn't being fully cleared before going into bank mode - but that is perhaps excessive anyway.

I've just run another quick test with the ones I mentioned earlier, but it failed to copy a couple of App-Dir files/directories for some reason unknow to me. I tried a manual copy of the same and it just threw out a failed error.

Thanks for the do it outside of X pointer. I'll keep at it. Thanks Mike. Much appreciated.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#100 Post by rufwoof »

There are some .wh.... (hidden) files in /initrd/pup_rw. I suspect/believe they're something to do with keeping tabs on deleted (multi-layered) versions (seem to recall reading something about that somewhere). I'm guessing they should also be included/copied and not excluded ?

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#101 Post by mikeb »

Ah ..perhaps you need cp -r to recursively copy sub folders... there are other cp options but dont think they apply for what you intend.

Mike

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#102 Post by mikeb »

You post too fast...yes the whiteout files signify when files need to be hidden (deleted) so normally would be included.

mike

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#103 Post by rufwoof »

Thanks again Mike.

I have been using ROX to just copy for testing purposes, so that was in effect cp -r

My current thinking is to have two copies of tar files, a safe (bank) and a normal (pet's/sfs's loaded etc (different to CD image)) copies of /initrd/pup_rw relevant directories, and drop out of X, copy (tar extract) in either the safe or normal tar file, and restart X again. I'm hoping that tar -p (preserve permissions) will overcome the app-dir copying problem.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#104 Post by mikeb »

Rox might baulk at the app directopries as its a rox thing...other methods should work.

Must admit its the first thing I remove from a puppy.

Not sure if you need to drop out of X to LOAD it unless you are changing icons/menues....you are mainly looking at having 2 sets of configs and avoiding a full reboot.

-p I used to preserve ownership...i think it should keep permissions anyway.

All good fun

mike

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#105 Post by rufwoof »

Saving different versions of desktop (/initrd/pup_rw relevant directories) to /mnt/sda4/1 and /mnt/sda4/2 and then exiting X and running something like

#!/bin/bash
cd /initrd/pup_rw
rm -r -f etc;rm -r -f lib;rm -r -f root;rm -r -f usr;rm -r -f var
cp -r /mnt/sda4/1/* .

to copy in the desired desktop worked a charm - excepting for the app-dir's :roll:

So real close to a final version thank Mike.

Being able to switch from one version of 'savefile' to another in seconds is really great. You'd also get a feel for how much is being copied and could judge when it might be time to remaster a fresh CD once the amount of changes away from the existing basic CD had accumulated to a sizeable amount of difference.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#106 Post by 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

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#107 Post by 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. :P

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
Posts: 202
Joined: Sun 04 Jan 2015, 02:19

#108 Post by totolanio »

How to decrease savefile size plz ?

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#109 Post by 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
Posts: 202
Joined: Sun 04 Jan 2015, 02:19

#110 Post by totolanio »

mikeb wrote:
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

Post Reply