Remove automatic pupsave for frugal installs

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

#46 Post by mikeb »

Hmm save folder might be up your street it seems...as using it everything contained is easily accessible as they are just files on a normal file system. It just becomes part of the union when running for convenience. As you realise...keeping the system core as a read only archive is a very robust approach. Just having a solid save method finishes the picture.

That was @rufwoof... funny how we end up with multiple conversations.

mike

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

#47 Post by nic007 »

mikeb wrote:Actually that answer was @ rufwoof ..sorry for thee confusion...you may batter me with whatever vegetable you have to hand...

mike
I know, was just chipping in. No confusion at all. Can we change the subject - how do you boot a "savefile" in the form of an SFS file as top layer? :D

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

#48 Post by mikeb »

Ok ... boot resembles PUPMODE=5

tmpfs made for pup_rw as is for mode 5

save sfs is mounted and contents copied to /pup_rw

unmount and carry on in normal fashion

thats it..so runs like mode 5 but top layer is populated from last session so effectively a save.

I did use .tar but tar in initrd ..embutils version..was flaky..probably improved or build a tiny libc version. uncompressed sfs does the same job apart from whiteout files need specifically handling when copying.

Shutdown just makes sfs of /tmpfs minus unneeded folders...easy to not make so giving a 'no save' option ..also easy to keep a backup of the previous session by renaming before creation.

Only caveats really is a suitable amount of ram + swap and saving during session could be done as otherwise say a power loss makes for an error free boot but only from the previous session. Never seems to need that as anything i want to keep in that way i save to a hard drive, memory stick or internet anyway...

mike

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

#49 Post by nic007 »

mikeb wrote:Ok ... boot resembles PUPMODE=5

tmpfs made for pup_rw as is for mode 5

save sfs is mounted and contents copied to /pup_rw

unmount and carry on in normal fashion

thats it..so runs like mode 5 but top layer is populated from last session so effectively a save.

I did use .tar but tar in initrd ..embutils version..was flaky..probably improved or build a tiny libc version. uncompressed sfs does the same job apart from whiteout files need specifically handling when copying.

Shutdown just makes sfs of /tmpfs minus unneeded folders...easy to not make so giving a 'no save' option ..also easy to keep a backup of the previous session by renaming before creation.

Only caveats really is a suitable amount of ram + swap and saving during session could be done as otherwise say a power loss makes for an error free boot but only from the previous session. Never seems to need that as anything i want to keep in that way i save to a hard drive, memory stick or internet anyway...

mike
I tried this at some stage but it didn't work for me. Can recall that the sfs created from the previous "saved session" didn't change icons (I changed the icons set during the previous session as a test) when the contents were copied to pup_rw ... Also, it was difficult to get rid of something that was saved somewhere in / instead of in root....but I'll play with it again.

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

#50 Post by mikeb »

was it done during the initrd phase? The pinboard is rewitten around the time x it launched.

whiteout handling is needed for sfs....would affect deletion of existing files but not added ones.

mike

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

#51 Post by greengeek »

mikeb wrote:Not having some form of save option would be a pain in the neck for general use...
1) I tell the family to save their data externally or else it will be lost. Howls of protest initially, then they started to understand that taking responsibility for their data makes much more sense than trusting your operating system to do it. (of course it would also be great to have an auto backup script capturing and archiving the session activity as a backup mechanism for forgetful users...)

2) System file changes should be quarantined and not automatically included at shutdown. Shutdown procedures always need to offer the following choices:
- save current session totally.
- discard current session totally
- archive current session and let me choose at next boot whether i want to continue from previous session or use pristine boot.

I would like to see the initrd.gz changed in a way that places the main puppy sfs at a priority that can be higher than some sfs and lower than other sfs (such as a 'personal save' sfs).

Add to that a variety of mechanisms that allow sessions to be saved/archived/recovered and there will be greater flexibility than is currently the case.

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

#52 Post by rufwoof »

greengeek wrote:Shutdown procedures always need to offer the following choices:
- save current session totally.
- discard current session totally
- archive current session and let me choose at next boot whether i want to continue from previous session or use pristine boot.
Pupmode 5 - that I use all the time, provides all of those

'First time' create savefile yes/no at shutdown
Boot with pfix=ram boot parameter or not = whether you want to reload the savefile or not
Remaster at a opportune time to merge in any savefile (make permanent) and delete the savefile.

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

#53 Post by mikeb »

Got all those options greengeek effectively already in a neat user friendly way. Archive save means mv savefile.sfs ...done... no time taken at all.

Actually what about when the family make a bookmark of a website ..... or choose another default font for libreoffice, etc etc... my saves usually keep hardware, app configs and thumbnails (sorry its faster that way...just delete old thumbs at shutdown)... range from a few MB to 50 odd. In other words system stuff not data. /root gets used as a convenient temporary store sometimes. Data is something for long term storage elsewhere...and backed up of course.
Using sfs for extra apps helps too.


mike

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

#54 Post by greengeek »

rufwoof wrote:Remaster at a opportune time to merge in any savefile (make permanent) and delete the savefile.
But what if there was an option to merge various sfs instead of remastering? Remastering is such a final and permanent way of moving forwards without the ability to go backwards if you find a problem.

A savefile sits higher up the tree than the main puppy sfs does - so it allows you to 'override' the characteristics of the main puppy sfs. However - its strength (writability) also becomes its ongoing weakness (acceptance of malware or corruption).

It would be good for that savefile to have the ability to be reformed as a readonly sfs and still sit higher up the tree than the main sfs (it currently can't do this - it will fall to a lower priority than the main puppy sfs).

Remastering is good in the sense that it makes our changes permanent, and that they are retained in read-only mode. Personal changes (currently reflected in the writable savefile) should also be able to be made 'read-only' (for safety's sake) without full remastering, and be handled as an on-the-fly sfs.

That would also open the door to new methods of multiuser environments - same base puppy but with different readonly personal environments (or 'skins') gratfed over the top - and then with the ability to capture sessions and retain as extra savefiles (writable) or sfs (fixed readonly).

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

#55 Post by mikeb »

got all this...just thought others might benefit... and a read only save sfs is pretty robust indeed...

As for multiuser why not do the job properly?
True, choice of save to load does a cludgy version of it and sfs save would be no problem to do this. Actually it was requested to have a way of swapping on the fly.... not quite as simple as it sounds as those altered files may be in use and would block any aufs changes...or even a simple overwrite.

Layering order has needed sorting for years..don't hold your breath..easy to fix though and makes life much easier.

mike

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

#56 Post by nic007 »

mikeb wrote:was it done during the initrd phase? The pinboard is rewitten around the time x it launched.

whiteout handling is needed for sfs....would affect deletion of existing files but not added ones.

mike
Okay, tried again. Same problem booting the edited base file (desktop icons not changing). This what I did: made an SFS of the contents of initrd/pup_rw (just as is) at the end of the session. Put the copy script in /etc/rc.d/init.d (editing the base sfs). Did I miss something?

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

#57 Post by mikeb »

well unless its loaded by the initrd the behaviour will be unpredictable as it will conflict with main system boot processes. eg it loads the pinboard while its being checked for icon position so you end up with the original rather than the new version. You have to load pup_rw before the main system starts like other save methods.

init.d is for system daemon and startup scripts.. Scripts in there might still be being processed when X is loading since from what I have seen its loaded by delayedrun which does its stuff after X has started...bad bad system design but thats another matter.

You might , but only might fare better using /etc/rc.d/rc.local .. again you could still conflict with an altered system file in say /etc .

mike

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

#58 Post by nic007 »

mikeb wrote:well unless its loaded by the initrd the behaviour will be unpredictable as it will conflict with main system boot processes. eg it loads the pinboard while its being checked for icon position so you end up with the original rather than the new version. You have to load pup_rw before the main system starts like other save methods.

init.d is for system daemon and startup scripts.. Scripts in there might still be being processed when X is loading since from what I have seen its loaded by delayedrun which does its stuff after X has started...bad bad system design but thats another matter.

You might , but only might fare better using /etc/rc.d/rc.local .. again you could still conflict with an altered system file in say /etc .

mike
rc.local I have as a text file. Do I just copy the contents of my script there and keep it as a text file or should it be an executable script file? Also checked rc.sysinit which calls rc.local and the rc.local section is at the end of that script so I don't think this is going to work. The part with regards to the pinboard is the second last section maybe I should try to change them around?
Last edited by nic007 on Sun 22 Feb 2015, 11:28, edited 1 time in total.

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

#59 Post by mikeb »

well early in sysinit would be better.... after the 'file system is made useable' stuff. Local ok too.... much better than init.d . None of these options are the real solution but at least its better.
Either add the script or make a separate script of it and call that.

mike

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

#60 Post by rufwoof »

What would happen if - near the bottom of init - you changed the make pup_rw folder to instead create a symbolic link to an existing pup_rw 'copy' that was stored/preserved on HDD

i.e. in mine its init script line 1803 - and change

mkdir -p /pup_new/initrd/pup_rw

to

ln -s /mnt/sda3/pup_rw /pup_new/initrd/pup_rw

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

#61 Post by mikeb »

well you are then sort of doing the save folder boogie.... basically a folder on a hard drive is mounted onto pup_rw .... a bind mount is what I used (since the partition is mounted already you cannot mount within a mount) though moat has made a symlink work...either way slotting it in with existing arrangements is the tricky part.
But it works..I have had it on puppy for several years and slax uses this method as its recommended save option ..circa 2006...so a tried and tested method.

Only caveat is that it must be from a posix partition..eg ext2/3/4 and so on.

mike

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

#62 Post by nic007 »

Pinboard problems, doesn't work for me. BTW, I have a FAT partition. Just another thing about loading extra SFS's in RAM mode - you can specify any directory on the partition you have booted from (eg. /initrd/mnt/dev_ro2/ExtraSFS) however if you have a save file loaded the extra SFS's files must be in the parent directory (/mnt/home) otherwise it won't load.

Pelo

faire croire que l'installation frugale est sur USB ! merci

#63 Post by Pelo »

Vous n'aimez pas automatic saving, Moi non plus. Trafiquez le système pourlui faire croire que vous êtes sur clé USB. (i.e, switch sur pupmode 13), en modifiant rc.shutdown pour lancer la sauvegarde ou pas. et mettre à zéro les intervalles events manager "0" (ne pas sauver).

1. set the Utilities/PupShutdownManger/Manage System Events/Save Session dialogue to "0" (no save).
et mettre à zéro les intervalles events manager "0" (ne pas sauver).

2. change in menu.lst: change pmedia=atahd en ataflash.

3. changez dans /etc/rc.shutdown

13) #PDEV1 and PUPSFS and PUPSAVE
#/initrd/pup_rw has tmpfs, pup_ro1 has ${DISTRO_FILE_PREFIX}save.2fs file (PUPSAVE), pup_ro2 has PUPSFS file.
#the above are in unionfs at /.
dialog --yesno "Save session?" 0 0 >/dev/console
if [ $? -eq 0 ]; then
echo "Saving session to $SAVEFILE (${SAVEPART})..." >/dev/console
/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
fi f
:) merci pour cette info. I was seaching a solution, nice.

login123
Posts: 13
Joined: Tue 22 Jun 2010, 18:45

unknown original poster and where on this site

#64 Post by login123 »

The method in the 5th post in this thread, (by bill 01 Dec 2012) still works OK in Puppy 5.2.8.005 as of 05 may 2015. Using it now. You still get the warning during restart, and it is still harmless.

The original post from 20 Feb 2011 is here: http://www.murga-linux.com/puppy/viewtopic.php?t=65016

backi
Posts: 1922
Joined: Sun 27 Feb 2011, 22:00
Location: GERMANY

Tahr frugal on Usbstick can not avoid saves to flash

#65 Post by backi »

Hi you !
Need some help .
I want to avoid saving automatically to Usb-Stick during session ...(for example if i am testing new pets or debs or installing something for testing .)

I have an Tahrpup 6.0.5 frugally installed on Usb stick .
Although Puppy Eventmanager the Save-session is set to 0 , when installing pets or debs they are saved immediately to flash device .
Need support .

Thanks

Post Reply