Factory Reset
Hmmm.. the delete the save at boot and start over seems less hairy to me.... recent puppies pretty much set themselves up.
Actually my original 'persue the sfs approach' suggestion still stands.
In my case i could rename the first boot save so its loaded every time underneath the rw layer... Bad save...delete it and the first save takes over. The save is not mounted so easy to do.
But since the save is created every shutdown it does not 'break' overtime and choosing to not save avoids any messed up sessions so keeping a factory reset would be a little over cautious.
In other words look at the system you are dealing with...adding another pack to a playing card tower system may not be the best way to go. Ask yourself WHY you are making a recovery system and look at ways of making it less fragile.
The aim was not to hyjack but to provide hopefully beneficial discussion
regards
mike
Actually my original 'persue the sfs approach' suggestion still stands.
In my case i could rename the first boot save so its loaded every time underneath the rw layer... Bad save...delete it and the first save takes over. The save is not mounted so easy to do.
But since the save is created every shutdown it does not 'break' overtime and choosing to not save avoids any messed up sessions so keeping a factory reset would be a little over cautious.
In other words look at the system you are dealing with...adding another pack to a playing card tower system may not be the best way to go. Ask yourself WHY you are making a recovery system and look at ways of making it less fragile.
The aim was not to hyjack but to provide hopefully beneficial discussion
regards
mike
Test gzipping a 512 MB Save file took several minutes to do.
And it took about a half a minute to ungzip it. WAY too long.
I don`t remember it being that long, but it`d been awhile.
"Wipe and restore" has some merit it seems.
Not to hijack your thread Announcer, but a Save dir. is still a better idea.
But... Your "wipe and restore" setup still applies to it as well...
.
And it took about a half a minute to ungzip it. WAY too long.
I don`t remember it being that long, but it`d been awhile.
"Wipe and restore" has some merit it seems.
Not to hijack your thread Announcer, but a Save dir. is still a better idea.
But... Your "wipe and restore" setup still applies to it as well...
.
But would that improve the upgrade experience?greengeek wrote:This would be an interesting way to add a "service pack" to a puppy - apply the contents of a new FR.sfs file, click factory reset, and the new puppy is fresh and ready to go...
Have fun. The other 99.99% of us will continue to use savefiles while you save to your sfs. But it's a free country. (Used to be, anyway.)mikeb wrote:Actually my original 'persue the sfs approach' suggestion still stands...
The aim was not to hyjack but to provide hopefully beneficial discussion
Thanks.sunburnt wrote:"Wipe and restore" has some merit it seems.
I will thanks since is solid and reliable and I don't have to think of ways of fixing it. Works on Slax too. Being in a minority does not necessarily mean suffering in some wayHave fun. The other 99.99% of us will continue to use savefiles while you save to your sfs.
Thanks for the friendly banter
mike
ps I promise not to mention my save folder option......
In my case, I use a utility called HotBackup.
After the backup of the pupsave file, I rename those backups adding "first,Second,Third,etc in the appropriate place.
And since HotBackup includes the backup date as part of the name, I know which is which.
After, I use a utility I wrote that restores the backup to the original directory.
On a reboot, I then have two pupsave files to choose from and just choose the restored backup and delete the other pupsave.
Of course, one could also just add a ".2fs, 3fs, or 4fs extension renaming the backup and use it unaltered with the backup date as part of the filename.
It would be easy to see just when the backup being used had been made.
After the backup of the pupsave file, I rename those backups adding "first,Second,Third,etc in the appropriate place.
And since HotBackup includes the backup date as part of the name, I know which is which.
After, I use a utility I wrote that restores the backup to the original directory.
On a reboot, I then have two pupsave files to choose from and just choose the restored backup and delete the other pupsave.
Of course, one could also just add a ".2fs, 3fs, or 4fs extension renaming the backup and use it unaltered with the backup date as part of the filename.
It would be easy to see just when the backup being used had been made.
8-bit; But doesn`t it take a few minutes to make each backup?
mikeb; You have a "save folder option", instead of a "Save file". You cretin! That`s my idea!
It doesn`t take long to realize a folder`s better than an image file, more reliable.
But as image files go, a Squash file being R-O can`t be corrupted like a R-W ext3 file.
mikeb; You have a "save folder option", instead of a "Save file". You cretin! That`s my idea!
It doesn`t take long to realize a folder`s better than an image file, more reliable.
But as image files go, a Squash file being R-O can`t be corrupted like a R-W ext3 file.
If one created an SFS file from their pupsave file and mounted it after booting with "pfix=ram" any changes to existing files would not be done.
Puppy loads the linux kernel, the pupsave file then gets loaded as per instructions in the initrd.gz file. And then the Puppy SFS file is loaded.
This order of loading to me means that if a file exists, it is not overwritten by a later load of the same file.
Of course with a rewrite of the initrd.gz file, one could modify the way puppy loads so that a converted to SFS pupsave file loaded first and then the main Puppy SFS file loaded.
One thing that bothers me about a Factory reset file or folder is that in recovering from a corrupted pupsave load, the files causing the corruption would still be there as part of the user data and saved on shutdown or reboot with the result of the pupsave still being corrupted.
Puppy loads the linux kernel, the pupsave file then gets loaded as per instructions in the initrd.gz file. And then the Puppy SFS file is loaded.
This order of loading to me means that if a file exists, it is not overwritten by a later load of the same file.
Of course with a rewrite of the initrd.gz file, one could modify the way puppy loads so that a converted to SFS pupsave file loaded first and then the main Puppy SFS file loaded.
One thing that bothers me about a Factory reset file or folder is that in recovering from a corrupted pupsave load, the files causing the corruption would still be there as part of the user data and saved on shutdown or reboot with the result of the pupsave still being corrupted.
8-bit; You can "append to a Squash file. So... You can write to it.
The folks who have used this have a button or control over "save" or "don`t save".
Where as my frugal live Save file is always available ( corruptible ).
And a USB boot, auto. saves at shutdown, and has timed saves too.
From my work on LanPuppy I found the Save file must load first.
If the Save file is wiped clean and restored to a "first boot condition", what corruption would there be left?
The folks who have used this have a button or control over "save" or "don`t save".
Where as my frugal live Save file is always available ( corruptible ).
And a USB boot, auto. saves at shutdown, and has timed saves too.
From my work on LanPuppy I found the Save file must load first.
If the Save file is wiped clean and restored to a "first boot condition", what corruption would there be left?
@Announcer
Actually your proposed system willl probably work fine assuming someone techie makes the initial files. I was questioning that instead of using your obvious abilities to provide a fix for a common (check the forum) problem of save file corruption perhaps you should divert your attention towards looking at better ways of saving on puppy...one idea does involve sfs since an archive is very robust ( who has ever has to replace the pup_xxx.sfs file?) but there are others. Dive into the core of puppy...remove the spaghetti and you never know what you might come up with. This forum is about the exchange of ideas.
@sunburnt...
Well actually slax gave me the idea as it does more or less that. By using a save folder you get the save partition idea but in a neater way. Advantage is you have oodles of room without those precarious 2GB save files I see in use. I use it for all our regular systems apart from on the netbook as it has plenty of ram and I can turn off the hard drive once booted using sfs. (with tidiness and sfs for apps saves run in at 30-60mb uncompressed) As for copyright I did this 3 years ago ...ha! Ooo and for fun have an pupsave like file used like a full install...ie no union...think of emulators...so low ram etc but can run from ntfs/fat. I left multisession alone as thats quite neat a it is. Oh yes I scrapped the usbflash mode 13... seemed silly to me and sfs suits it well.
On a general note remember puppy loads sfs files backwards normally (yeah sorted that too) so any additional sfs are 'underneath' the main one ...a pain in the neck at times so that's why I changed it... but it may affect any proposed 'recovery' system using the standard sfs loaders.
don't let the bedbugs bite
Mike
Actually your proposed system willl probably work fine assuming someone techie makes the initial files. I was questioning that instead of using your obvious abilities to provide a fix for a common (check the forum) problem of save file corruption perhaps you should divert your attention towards looking at better ways of saving on puppy...one idea does involve sfs since an archive is very robust ( who has ever has to replace the pup_xxx.sfs file?) but there are others. Dive into the core of puppy...remove the spaghetti and you never know what you might come up with. This forum is about the exchange of ideas.
@sunburnt...
Hmm name calling lol.. funky bunny is the expression you are looking for.You have a "save folder option", instead of a "Save file". You cretin! That`s my idea!
Well actually slax gave me the idea as it does more or less that. By using a save folder you get the save partition idea but in a neater way. Advantage is you have oodles of room without those precarious 2GB save files I see in use. I use it for all our regular systems apart from on the netbook as it has plenty of ram and I can turn off the hard drive once booted using sfs. (with tidiness and sfs for apps saves run in at 30-60mb uncompressed) As for copyright I did this 3 years ago ...ha! Ooo and for fun have an pupsave like file used like a full install...ie no union...think of emulators...so low ram etc but can run from ntfs/fat. I left multisession alone as thats quite neat a it is. Oh yes I scrapped the usbflash mode 13... seemed silly to me and sfs suits it well.
On a general note remember puppy loads sfs files backwards normally (yeah sorted that too
) so any additional sfs are 'underneath' the main one ...a pain in the neck at times so that's why I changed it... but it may affect any proposed 'recovery' system using the standard sfs loaders.don't let the bedbugs bite
Mike
mikeb; Back atcha funky bunny. 
announcer; Suggestion, perhaps your app. could bring the dir. idea to Puppy.
Have an option in it to setup a Save dir. instead of a Save file.
And an option to transfer the contents of an existing Save file to a new Save dir.
A check if there`s a Linux partition to use would be needed of course.
Then your "Factory Restore" could do it`s work on either type of Save setup.
Wacha think? Am I being to optimistic, or have I got your interest?
Many I`ve talked to think the dir. idea would be an advancement for Puppy.
.
announcer; Suggestion, perhaps your app. could bring the dir. idea to Puppy.
Have an option in it to setup a Save dir. instead of a Save file.
And an option to transfer the contents of an existing Save file to a new Save dir.
A check if there`s a Linux partition to use would be needed of course.
Then your "Factory Restore" could do it`s work on either type of Save setup.
Wacha think? Am I being to optimistic, or have I got your interest?
Many I`ve talked to think the dir. idea would be an advancement for Puppy.
.
Nice little app.
For those who are talking about backing up your save file first... Use the pet that was posted here a while ago (I'll reupload it).
Works like a charm.
probably would be able to simply edit Announcers script to automate a backup before wiping if you really wanted a backup before his script erases the save file.
All the save file does is compress that down into a single file for simple handling/encrypting/etc. You can simply back up your 'save dir' to wherever you want by just copying that folder elsewhere.
Or have I TOTALLY misunderstood what you were trying to explain?
For those who are talking about backing up your save file first... Use the pet that was posted here a while ago (I'll reupload it).
Works like a charm.
probably would be able to simply edit Announcers script to automate a backup before wiping if you really wanted a backup before his script erases the save file.
But Puppy already has a save dir when its running. It's /initrd/pup_rwsunburnt wrote:Suggestion, perhaps your app. could bring the dir. idea to Puppy.
Have an option in it to setup a Save dir. instead of a Save file.
And an option to transfer the contents of an existing Save file to a new Save dir.
Many I`ve talked to think the dir. idea would be an advancement for Puppy.
.
All the save file does is compress that down into a single file for simple handling/encrypting/etc. You can simply back up your 'save dir' to wherever you want by just copying that folder elsewhere.
Or have I TOTALLY misunderstood what you were trying to explain?
- Attachments
-
- PupsaveHotBackup-1.3.pet
- (4.3 KiB) Downloaded 248 times
