Factory Reset
Factory Reset
Instead of a user having to create and configure his own savefile, why not create one for him, and then provide a simple utility to erase it?
That's the idea behind Factory Reset.
This script is for people who are running off a usb drive and have an existing save file in use. The save file is wiped clean without deleting it.
That's the idea behind Factory Reset.
This script is for people who are running off a usb drive and have an existing save file in use. The save file is wiped clean without deleting it.
- Attachments
-
- Factory_Reset.pet
- (2.64 KiB) Downloaded 788 times
Last edited by Announcer on Fri 23 Aug 2013, 09:35, edited 10 times in total.
I am not a fan of USB Pendrives . They are risky in a way that they could easily disconnect .
I don't understand this USB-Hype .
But that Hype apparently exists .
I wish you good luck with your approach !
I don't understand this USB-Hype .
But that Hype apparently exists .
I wish you good luck with your approach !
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
I think it would be worthwhile to offer the user a choice of "backup existing savefile then erase"
I would not want to erase a savefile unless I was sure I had a backup of the previous one (but then I do sometimes drink a little too much wine and make unintended mistakes...)
Also - your script suggests that it will reset the usb "stick" yet leave the data untouched - however the stick might contain 2 partitions. (I usually keep my data on the 2nd usb partition). Maybe it should say that it will reset the usb "boot partition" and leave any other data partitions untouched...
I would not want to erase a savefile unless I was sure I had a backup of the previous one (but then I do sometimes drink a little too much wine and make unintended mistakes...)
Also - your script suggests that it will reset the usb "stick" yet leave the data untouched - however the stick might contain 2 partitions. (I usually keep my data on the 2nd usb partition). Maybe it should say that it will reset the usb "boot partition" and leave any other data partitions untouched...
greengeek has the right idea, don`t keep anything in the Save file.
Announcer; Its a compressed backup Save file either way.
If the Save file`s saved right after it`s created, then it`s "factory", right?
It`s fairly common for Puppy to scramble the Save file and become unbootable.
So then boot to ram, erase the Save file, reboot and shutdown creating a new one.
If a Save file`s backed up after it`s "configured", then a "nuke & restore" isn`t needed.
Unless you run Puppy like Flash does, from a CD in ram with no Save file.
.
Announcer; Its a compressed backup Save file either way.
If the Save file`s saved right after it`s created, then it`s "factory", right?
It`s fairly common for Puppy to scramble the Save file and become unbootable.
So then boot to ram, erase the Save file, reboot and shutdown creating a new one.
If a Save file`s backed up after it`s "configured", then a "nuke & restore" isn`t needed.
Unless you run Puppy like Flash does, from a CD in ram with no Save file.
.
@ greengeek: Sorry, I've made a couple of changes to the script. It no longer mentions that it leaves the data partition untouched. But it doesn't delete anything except for files inside the .4fs savefile.
As for backing up the savefile first, all you have to do is copy it somewhere and rename it. So that's pretty easy.
I used the changes to /etc/rc.d/rc.shutdown you and 01micko made, so that it reboots without saving after using Factory Reset. So, thanks! It's not included in the pet package though, because it needs to be in the main system sfs. So that's another thing to keep in mind:
*If you are asked after if you want to save, choose "No" for the wipe to take effect.*
@sunburnt: The whole idea of this is to keep things as simple as possible. An option to back up the sfs defeats the purpose, because I don't want the user to have to know anything about savefiles or saving or boot options etc. It just does it and doesn't ask questions, and if things go wrong there is a simple solution.
Look at smartphones. Changes are persistent, and good phones have a factory reset option. Same sort of idea.
As for backing up the savefile first, all you have to do is copy it somewhere and rename it. So that's pretty easy.
I used the changes to /etc/rc.d/rc.shutdown you and 01micko made, so that it reboots without saving after using Factory Reset. So, thanks! It's not included in the pet package though, because it needs to be in the main system sfs. So that's another thing to keep in mind:
*If you are asked after if you want to save, choose "No" for the wipe to take effect.*
@sunburnt: The whole idea of this is to keep things as simple as possible. An option to back up the sfs defeats the purpose, because I don't want the user to have to know anything about savefiles or saving or boot options etc. It just does it and doesn't ask questions, and if things go wrong there is a simple solution.
Look at smartphones. Changes are persistent, and good phones have a factory reset option. Same sort of idea.
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Factory Reset
What is so difficult with
boot pfix=ram
which is Puppy's (factory ) reset
boot pfix=ram
which is Puppy's (factory ) reset
Re: Factory Reset
Nothing. But Factory Reset:L18L wrote:What is so difficult with
boot pfix=ram
which is Puppy's (factory ) reset
*is instant. You don't have to reboot three times using a special cheat code. It's done in about two seconds.
*is simple. You just click the entry in the menu.
*is an actual factory reset, because the only thing on the drive that is changed during use is the save file, so formatting returns it to its original state.
Last edited by Announcer on Fri 23 Aug 2013, 09:55, edited 1 time in total.
mikeb; I forget who ( SeaSide.? ), but someone here replaced the Save file with an SFS file.
As I said, just takes someone who knows the Puppy boot code.
Announcer; Why would anyone want to backup an SFS file?
What`s so hard about making a copy of the Save file ( ext2 or ext3 ) and gzip it?
I`m not sure what all the effort you`re going to is doing. A first boot Save file`s still needed.
After that both methods accomplish the same thing ( I believe...). Just copy and gzip is easier.
Make a script, call it "pup-save":
Easily added to Puppy`s menu or a GUI dialog.
.
As I said, just takes someone who knows the Puppy boot code.
Announcer; Why would anyone want to backup an SFS file?
What`s so hard about making a copy of the Save file ( ext2 or ext3 ) and gzip it?
I`m not sure what all the effort you`re going to is doing. A first boot Save file`s still needed.
After that both methods accomplish the same thing ( I believe...). Just copy and gzip is easier.
Make a script, call it "pup-save":
Code: Select all
#!/bin/sh
######### Puppy Save file backup and restore.
savePF=`losetup /dev/loop1 |cut -d' ' -f3`
### Backup Save file.
if [ "$1" = 'backup' ];then
cp $savePF $savePF'_BU'
gzip -9 $savePF'_BU'
### Restore Save file.
elif [ "$1" = 'restore' ];then
rm $savePF
gunzip $savePF'_BU'
fi
.
well I have added this option to puppy for over 2 years... its solid and especially good for say a netbook using flash as the stick can be removed once booted and saves are optional. It also means the resident filesystem is not left with the dirty flag set which can be a nuisanse. Think in terms of multisession cd but from flash/harddrive.mikeb; I forget who ( SeaSide.? ), but someone here replaced the Save file with an SFS file.
mike
I would be very keen to see a tutorial about doing this if anyone feels like making one. For some reason I have mostly stayed away from using an sfs but it sounds like your method creates a personalised sfs instead of a savefile. Is that how you use it?mikeb wrote:well I have added this option to puppy for over 2 years... its solid and especially good for say a netbook using flash as the stick can be removed once booted and saves are optional.
Yes.it sounds like your method creates a personalised sfs instead of a savefile. Is that how you use it?
I did use tar for a while but the tinylibc version was too buggy. With machines with a decent amount of ram and sensible save usage its a tidy option. I also use sfs for applications so no pets loaded in there.
As for the op I would think an option to boot pfix=ram and load the sfs contents to the pup_rw layer as a boot menu option would be something that could be made user friendly. A bit like safe mode for firefox.
mike
The problem with these other ideas is that you still can't delete a save file while it is in use - you have to reboot with pfix=ram, then boot again, and create a new save file. With this script you do not.
You just click the app in the menu, and it wipes the existing save file clean in two seconds, and reboots "new".
I'm not going to replace the script with some other one that does something entirely different. I know what I am trying to do, and how I am trying to do it.
So please stop hijacking the thread.
You just click the app in the menu, and it wipes the existing save file clean in two seconds, and reboots "new".
I'm not going to replace the script with some other one that does something entirely different. I know what I am trying to do, and how I am trying to do it.
So please stop hijacking the thread.
I did sneak back onto your topic but whatever...
mike
If the intention is simple I did not see where this is done by the 'user'... an easy script though.I also added a link to an FR.sfs file, which will have to be created for different versions of Puppy. To do so, boot and then save right away, creating a save file. Then reboot using "puppy pfix=ram", click the savefile, and copy the files inside into a directory called FR. Delete the contents of the /root folder inside FR, then do:
Code:
dir2sfs FR FR.sfs
inside whatever folder you created the FR folder in. Put it into /mnt/home and you're done.
mike
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.