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

#81 Post by mikeb »

nah...I want a slim core for on a stick recovery times or maybe compiling or just to have less to upload...and don't want to declog old versions and remaster again every time one program changes.

Modular is fun to be, it stops you sinking when you are at sea.

Anyway whenever I remaster there is always one daft thing left undone..... doing the whole system at once means mire chance of dismal failure.

Notice how I turn frustration into rhyme.

michel

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#82 Post by nic007 »

mikeb wrote:nah...I want a slim core for on a stick recovery times or maybe compiling or just to have less to upload...and don't want to declog old versions and remaster again every time one program changes.

Modular is fun to be, it stops you sinking when you are at sea.

Anyway whenever I remaster there is always one daft thing left undone..... doing the whole system at once means mire chance of dismal failure.

Notice how I turn frustration into rhyme.

michel
I only use JRE, wine and opera. Installed it and remastered. Not bothered to install anything else or run other SFS's. So, with that installed the base SFS is still only 120MB. I can live with that
Last edited by nic007 on Thu 30 Jan 2014, 15:59, edited 1 time in total.

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

#83 Post by mikeb »

Thats doesn't sound much fun :D.... i like me machines doing the can can while juggling plates.

les miserables.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#84 Post by nic007 »

mikeb wrote:Thats doesn't sound much fun :D.... i like me machines doing the can can while juggling plates.

les miserables.
I prefer to have my very few eggs in one basket. Easy to carry around and none ever gets lost :wink:

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

#85 Post by mikeb »

There's a world of eggs out there...

you do know the moral behind the saying!!??

I think tonight I would like to sleep in one continuous session

mike

fobq
Posts: 101
Joined: Mon 19 Aug 2013, 11:41
Location: Hungary

#86 Post by fobq »

hi,
how is it that my browser's cache is limited to 30 MB, but the pup_rw/root/.cache folder continuously grows? Right now it is 67.2MB. What is that amount of data over the 30 MB?
Last edited by fobq on Mon 24 Mar 2014, 04:53, edited 1 time in total.

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#87 Post by Flash »

How are you running Puppy (full install; frugal install; live CD with Save file; etc..)

fobq
Posts: 101
Joined: Mon 19 Aug 2013, 11:41
Location: Hungary

#88 Post by fobq »

Puppy Precise 5.7.1 frugal install

User avatar
Moat
Posts: 955
Joined: Tue 16 Jul 2013, 06:04
Location: Mid-mitten

#89 Post by Moat »

Didn't want to allow this very useful, simple tidbit from SFR to get lost in the shuffle - IMO, it sucessfully addresses one of a frugal Puppy's biggest shortcomings (a growing savefile), for those having difficulty with certain directories "sticking" between reboots, after being moved. From this thread - http://www.murga-linux.com/puppy/viewtopic.php?t=86187 -
SFR wrote:The problem is that after moving the directory outside of the savefile and symlinking it back, we have a situation where the directory is still in the savefile (/initrd/pup_ro1/), but in tmpfs is symlink.
So, during saving the session, cp (used in snapmergepuppy) will refuse to overwrite a directory with a symlink.
BTW, perhaps it's possible, but I haven't found a way to force cp to overwrite a dir with a symlink...

A simple workaround could be:
1. Move the directory outside of the savefile.
2. Save the session (this will delete the dir from the savefile).
3. Then create the symlink in place of moved directory.
4. And save the session again.

Greetings!
p.s. - Maybe this should be added to the first post...??

Bob

slavvo67
Posts: 1610
Joined: Sat 13 Oct 2012, 02:07
Location: The other Mr. 305

#90 Post by slavvo67 »

Is my save file smart enough to know it's getting full or does it just corrupt everytime? Judging by my results, I believe the latter. Nothing worse than having a bunch of yield triangles appear at startup!

I personally like to keep a large cache in case I need to scrape anything out later. :roll:

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 ?

Post Reply