Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 25 Nov 2017, 05:06
All times are UTC - 4
 Forum index » House Training » HOWTO ( Solutions )
Remove automatic pupsave for frugal installs
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 4 of 6 [77 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Author Message
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sat 21 Feb 2015, 11:55    Post subject:  

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
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 2187
Location: Cradle of Humankind

PostPosted: Sat 21 Feb 2015, 12:59    Post subject:  

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? Very Happy
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sat 21 Feb 2015, 13:24    Post subject:  

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
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 2187
Location: Cradle of Humankind

PostPosted: Sat 21 Feb 2015, 13:53    Post subject:  

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.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sat 21 Feb 2015, 14:23    Post subject:  

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
Back to top
View user's profile Send private message 
greengeek


Joined: 20 Jul 2010
Posts: 4721
Location: Republic of Novo Zelande

PostPosted: Sat 21 Feb 2015, 15:06    Post subject:  

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.
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2164

PostPosted: Sat 21 Feb 2015, 15:21    Post subject:  

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.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sat 21 Feb 2015, 15:30    Post subject:  

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
Back to top
View user's profile Send private message 
greengeek


Joined: 20 Jul 2010
Posts: 4721
Location: Republic of Novo Zelande

PostPosted: Sat 21 Feb 2015, 15:39    Post subject:  

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).
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sat 21 Feb 2015, 16:13    Post subject:  

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
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 2187
Location: Cradle of Humankind

PostPosted: Sun 22 Feb 2015, 06:39    Post subject:  

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?
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sun 22 Feb 2015, 06:51    Post subject:  

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
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 2187
Location: Cradle of Humankind

PostPosted: Sun 22 Feb 2015, 07:24    Post subject:  

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, 07:28; edited 1 time in total
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11071

PostPosted: Sun 22 Feb 2015, 07:27    Post subject:  

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
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2164

PostPosted: Sun 22 Feb 2015, 08:52    Post subject:  

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
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 4 of 6 [77 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » HOWTO ( Solutions )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0649s ][ Queries: 13 (0.0120s) ][ GZIP on ]