Remove automatic pupsave for frugal installs

[mikeb]

Laughing No...

nothing like an honest answer

I keep a users point of view as otherwise they would batter me with a sharp cucumber.....

[nic007]

So you have a system that is akin to a save folder then but outside of the union...well that at least avoids dirty shutdowns though not something the family would be setting up.

mike

Just avoid the shutdown process by renaming rc.shutdown...or switch off the computer's power-button.

[nic007]

So you have a system that is akin to a save folder then but outside of the union...well that at least avoids dirty shutdowns though not something the family would be setting up.

mike

[mikeb]

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

mike

[rufwoof]

So you have a system that is akin to a save folder then but outside of the union

Outside of Puppy space. I wouldn't want one part of a web of spreadsheets to be contained within the savefile of one Puppy, but rather accessible by other systems/Pup's according to whatever might be being used at the time.

For me Pup is a small kernel (vmlinuz) that boots a larger Linux (initrd) that comprises markup language based system to provide a desktop/menu that enables programs to be activated/run. Those programs enable you to do stuff. I'm happy for the enabler to be compartmentalised, whilst I want the stuff to be openly accessible. Once the enabler is enabling as desired then it can be cast in stone - a fixed tool.

[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

[nic007]

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?

[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

[nic007]

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.

[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

[greengeek]

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.

[rufwoof]

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.

[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

[greengeek]

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).

[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

[nic007]

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?

[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

[nic007]

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?

[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

[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