Save-pup-lock

Miscellaneous tools
Message
Author
nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#16 Post by nooby »

Nope not exactly. One lose either the icons one putthere oneself or lose the icons that should be there. So would be cool to get them back. :) 23.15 PM now so I go to bed now and I have much to do traveling away for some 6 hours so can not test much until much later.
I use Google Search on Puppy Forum
not an ideal solution though

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#17 Post by seaside »

nooby wrote:Nope not exactly. One lose either the icons one putthere oneself or lose the icons that should be there. So would be cool to get them back. :) 23.15 PM now so I go to bed now and I have much to do traveling away for some 6 hours so can not test much until much later.
Nooby,

When you're ready to test, check in a terminal type "cat /root/.config/rox.sourceforge.net/ROX-Filer/globicons". The last line should be this "</special-files>".

Regards,
s

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#18 Post by nooby »

Edit, I guess we have to look at this more carefully. No criticism at all.

I got curious on all the error messages so I started all over with a totally new install and never installed your Save-pup-lock and tried out the save that comes from ideflash being there instead.

That is where the errors start. We have to find other solutions and not use ideflash

That produced same errors and even worse error so I trust that it is not really what you changed. One most likely can not do as we do it now. One need to get what it going on better because there are too many bugs as it is set up now. I think yous should edit out all the save things from the first post to not let others go through all the wild tests :)

and you should feel good about the sfs-exec thing accomplished and put the save thing on backburner until you know more about the differences between pup431 and quirky 142 and snowpup 15 and soo on.
Now me back to bed. I hope

my older text.


Almost there. I got adventures and saved the icons from puppy 5 and then looked in the globicons and they lacked almost all of them so I copied in the rules from the older puppy and got almost all of them back.

So something goes wrong but it can be repaired if one know how to which I don't but I have to test more. I guess they disappear next time I do a save. I test that and then go back to bed. :)
I use Google Search on Puppy Forum
not an ideal solution though

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#19 Post by seaside »

Nooby,

I've tried save-pup-lock "ideflash" and "usbflash' on pup431, lupu510,511 on "usbflash" and have not experienced any of this.

I set up a new save file for each one, rebooted and then installed save-pup-lock and rebooted. All icons ok.

I'm at a loss to explain what you're experiencing.

Regards,
s
(Maybe we'll just use the regular direct save and life will be easier :) )

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#20 Post by nooby »

Could be something odd with my set up here.

Or one would need a very detailed step for step description to exclude that one do something in odd order.

What about the original scenario you found out you could do totally without a pupsavefile using a dir2sfs and making a zp431xxx zl525332 whatever file that loaded at boot and that way you could keep your preferred setup and still have no pupsavefile this way.

I remember vaguely that it never "took" when I booted.
Have you tested this now in Lupu525?

I prefer Snowpup5 and that one already have a zl513357? file so could that one be opened and I add my personal prefs in that one and that way need no save file?

Maybe too involved thng to deal with for newbies.

How else to do it? One could replace the challenged "corrupt" pupsavefile with a known preferred version that one copy over from a safe place and replace the corrupt one that one don't want to keep?
I use Google Search on Puppy Forum
not an ideal solution though

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#21 Post by seaside »

nooby wrote:Could be something odd with my set up here.

Or one would need a very detailed step for step description to exclude that one do something in odd order.

What about the original scenario you found out you could do totally without a pupsavefile using a dir2sfs and making a zp431xxx zl525332 whatever file that loaded at boot and that way you could keep your preferred setup and still have no pupsavefile this way.

I remember vaguely that it never "took" when I booted.
Have you tested this now in Lupu525?

I prefer Snowpup5 and that one already have a zl513357? file so could that one be opened and I add my personal prefs in that one and that way need no save file?

Maybe too involved thng to deal with for newbies.
Nooby,

Yes, the zdrive method has a limitation. If you make changes in the zdrive that have the same file names as in the main pup-xxx.sfs file, because of the layering system, the main pup-xxx.sfs takes priority. So any changes involving the desktop will be overcome in the layering system.

There is a way to overcome this by copying over these files at startup, but this gets rather complicated and probably not for most people.

Regards,
s

qafe0331
Posts: 3
Joined: Mon 12 Mar 2012, 13:07

#22 Post by qafe0331 »

this is really helpful, but i thing i noticed though, settings outside /root are saved in my lucid 5.2.8,

so when i install pets, the settings placed in /root are not saved but those outside /root still remains after restart.

any help? newbie here..

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#23 Post by seaside »

qafe0331 wrote:this is really helpful, but i thing i noticed though, settings outside /root are saved in my lucid 5.2.8,

so when i install pets, the settings placed in /root are not saved but those outside /root still remains after restart.

any help? newbie here..
qafe0331,

Would you open a terminal and type the following:

Code: Select all

cat /etc/rc.d/PUPSTATE
and then post the result here.

Thanks,
s

qafe0331
Posts: 3
Joined: Mon 12 Mar 2012, 13:07

#24 Post by qafe0331 »

Code: Select all

sh-4.1# cat /etc/rc.d/PUPSTATE
PUPMODE=13
PDEV1='sda1'
DEV1FS='vfat'
PUPSFS='sda1,vfat,/lupu_528.sfs'
PUPSAVE='sda1,vfat,/lupusave-qafe2.2fs'
PMEDIA='usbflash'
#ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
ATADRIVES=''
#ATAOPTICALDRIVES is list of non-usb optical drives...
ATAOPTICALDRIVES='sr0 '
#these directories are unionfs/aufs layers in /initrd...
SAVE_LAYER='/pup_ro1'
PUP_LAYER='/pup_ro2'
#The partition that has the lupusave file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='no'
#Partition no. override on boot drive to which session is (or will be) saved...
PSAVEMARK=''
This is the result, thanks for the reply.

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#25 Post by seaside »

qafe0331,

Hmmm. it looks like things have changed a bit since Save-pup-lock was made.

For some reason pets are installing directly to the save filesystem in later puppies - I've found the same problem with Racy-5.22 as well.

At the moment, I don't see how to prevent this, so I don't recommend using this on newer pups.

Thanks for running the test.

Cheers,
s

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#26 Post by seaside »

qafe0331,

Well, I've found a way to get around writing directly to the save file in recent puppies.

I've tested it out mostly in Racy-5.2.2, but it should work in all others as well.

Attached to the first post is "Save-pup-lock-02.pet" for newer puppies. Please test and let me know if this avoids the problem.

Cheers,
s

Les Kerf
Posts: 317
Joined: Sun 24 Jun 2012, 13:30

#27 Post by Les Kerf »

seaside wrote:qafe0331,

Well, I've found a way to get around writing directly to the save file in recent puppies.

I've tested it out mostly in Racy-5.2.2, but it should work in all others as well.

Attached to the first post is "Save-pup-lock-02.pet" for newer puppies. Please test and let me know if this avoids the problem.

Cheers,
s
I just stumbled onto this thread while searching for ways to keep from auto-saving. It seems to be working on Lucid 528 with a USB thumb drive.
Thanks for making this PET.
Les

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#28 Post by SFR »

Hey Seaside!

First of all thanks for this little gem, which is priceless for people like me - constantly messing up with the system's internals. :wink:

Everything would be fine, but I've discovered two problems today.
System: Slacko 5.3.3, frugal, pmedia=usbflash (USB) as well as pmedia=ataflash (HDD).

1. There's incompatibility between Save-pup-lock-02 and petget version in Slacko.
After installing Save-pup-lock-02 and rebooting, there's no way to install any new .pet.
In short: files aren't copied to their destinations.
Fortunately, upgrading to the latest petget-20120418.pet solves the problem, although I don't know why..?
(I haven't noticed that before, because I had petget upgraded already; just found out today, when setting up new Slacko USB install, from scratch).

2. This one is worse: one can use Save-pup-lock only once during a session.
After

Code: Select all

mv /usr/sbin/snapmergepuppyHOLD /usr/sbin/snapmergepuppy

yaf-splash -font "8x16" -outline 0 -margin 4 -bg orange -placement top -text "Saving RAM to 'pup_save' file..." &
  
   mount -n -o remount,rw /dev/loop1

  sync
  nice -n 19 /usr/sbin/snapmergepuppy
  killall yaf-splash

mv /usr/sbin/snapmergepuppy /usr/sbin/snapmergepuppyHOLD
 mount -o remount,ro /dev/loop1
there's no way to make pup_ro1 writable again.
mount -n -o remount,rw /dev/loop1 returns:
mount: initrd/pup_ro1 not mounted already, or bad option
Apparently snapmergepuppy is doing something to /initrd/pup_ro1, but I have very limited knowledge regarding layered filesystems etc. and all my attempts to fix this have failed...

If you could check out is there any possibility to resolve at least no.2, it would be really great! :)

EDIT: Ok, I just figured out that problem no.2 occurs only (it's getting weird) if the savefile has ext3 filesystem. In ext2, suprisingly, everything is ok, so far...

Thanks again &
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#29 Post by seaside »

SFR,

Yes, much of the Petget coding is different, depending on which puppy or derivative, as well as the layering systems Aufs and Union.

For installing pets, I now use this script put into a right-click->open-with->Pet-install.

Code: Select all

 #/bin/sh
#pet-installer
#seaside - use as right-click item

tar -z -x --strip=2 --directory=/ -f  "$1"
if [ -f /pinstall.sh ];then #pet pkgs.
 chmod +x /pinstall.sh
 cd /
   /pinstall.sh
 rm -f /pinstall.sh
fi
fixmenus
exec jwm -restart 
That way, I'm sure exactly where the pet is being installed. (You could also change the mime type so that pet-install would run if a pet file is clicked)

As far as the filesystem not remounting, depending on ext3, I haven't been able to replicate that - (I have had some infrequent cases, but not based on the filesystem)

Since Puppies have a "mount" script, a "busybox" mount and a "mount-FULL" (actual mount command) there is a possibility that this error
mount: initrd/pup_ro1 not mounted already, or bad option
may be caused by this line-

Code: Select all

mount -n -o remount,rw /dev/loop1 
The "mount -n" option isn't in every mount implementation, so you could try it with just

Code: Select all

mount  -o remount,rw /dev/loop1 
Cheers,
s

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#30 Post by SFR »

I don't know why can't you replicate the problem, perhaps it's something specific to Slacko again..?
Just for the record, here's more detailed procedure which reveals this error for me:

0. Slacko 5.3.3, fresh boot with pfix=ram, pmedia=ataflash. Create a savefile (ext3) and reboot.
1. First boot since savefile was created:
1a. mount -o remount,ro /dev/loop1 [ok]
1b. mount -o remount,rw /dev/loop1 [ok]
1c. Repeating 1a-1b [ok]
1d. sync && snapmergepuppy [ok]
1e. Repeating 1a-1d [ok]
1f. /initrd/pup_ro1 is left mounted as ro or rw (doesn't matter) + reboot
2. Second and further boots since savefile was created:
2a. mount -o remount,ro /dev/loop1 [ok]
2b. mount -o remount,rw /dev/loop1 [ok]
2c. Repeating 2a-2b [ok]
2d. sync && snapmergepuppy [ok]
2e. mount -o remount,ro /dev/loop1 [ok]
2f. mount -o remount,rw /dev/loop1 [fail]
mount: /initrd/pup_ro1 not mounted already, or bad option

Note 1: The same happens with -n option.
Note 2: The same happens when I won't execute 1a-1f; the problem always begins with the second boot.

But after all it's not a big deal, since it works flawlessly with ext2 + the latest petget and/or your raw install script. :wink:

Thanks & Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#31 Post by seaside »

SFR,

Thanks for all that testing.

My tests are on a usb thumb drive formatted as ext3 with an ext3 savefile booted from Racy5.3.

Since, this does not happen with an ext2 formatted savefile, I'm wondering if there is some "timing" issue due to journalllng in your case.

Since this only happens after the second boot, and only after snapmergepuppy has been run once, suggests that snapmergepuppy might be involved. However, it would seem in that case that it would affect both filesystem formats.

So, I'm at a loss to suggest a solution. Perhaps ext2 is ok since the idea is to keep save activity under direct control. :D

Cheers,
s
(Found this somewhat related reference to ext3 remounts
http://serverfault.com/questions/124051 ... y-from-a-d )

Pelo

pupSaveconfig V.2.2.2 is perfect

#32 Post by Pelo »

pupSaveconfig V.2.2.2 is perfect
It does like if it was the first run. you can save or not the things you have done during the session. Each time. very good, very well, très bon.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#33 Post by SFR »

@Pelo:
I used to use PupSaveconfig 2.2.2 & 2.2.4, until I noticed that it behaves the same way as the first version of Save-pup-lock (qafe0331's posts on previous page) - if I install some .pet(s) and choose not to save session, only /root is not being saved.
But I've checked PupSaveconfig + latest Petget a while ago...and it seems to work ok in this case. :shock:

@Seaside:
I downloaded Racy 5.3 and fell into the same problem (in Lucid too), so there's a big chance that this is "it's just me" type of issue. But like I said - it's no big deal. :wink:
The good news is that I've done quick test in Slacko:
Upgraded Petget & installed Save-pup-lock (first version!).
Pets are being installed properly and if I don't save the session, files belonging to installed .pets don't remain in the savefile. :)

Looks like Petget is crucial factor in both cases and the easiest way to use Save-pup-lock or PupSaveconfig happily is to upgrade Petget before.
I need to do more tests...

Thanks guys & Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#34 Post by seaside »

SFR,

Apparently snapmergepuppy sends a flag file after it's first use. Perhaps this causes the problem. Try this script in a terminal and see what happens

Code: Select all

#/bin/sh
#test snapmergepuppy affect

for i in {1..4}; do 

mount -o remount,ro /dev/loop1
mount -o remount,rw /dev/loop1
 
 sync && snapmergepuppy
 
 [ -e  /initrd/pup_ro1/tmp/flagnextpassthru] && rm -f  /initrd/pup_ro1/tmp/flagnextpassthru
 
 mount -o remount,ro /dev/loop1 
 mount -o remount,rw /dev/loop1

done
Regards,
s

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#35 Post by SFR »

Hey Seaside

Unfortunately, the same situation: at the first boot - ok, next boots - fail...
I even commented the appropriate line in snapmergepuppy:

Code: Select all

# [ -e /tmp/flagnextpassthru ] && NEXTPASSTHRU="yes"
before saving for the first time - nothing changed...

Something tells me that the problem might be initrd (or wherever it is)..?
You know, the line:
Updating... layered-filesystem next boot will be faster!
right after the first reboot after creating savefile.
Maybe thanks to "that" everything works at the first reboot, and at the next - it doesn't..?
But it's just an unjustified guess...

Again, I can live with that, since I know workarounds. :)
I think there's no need to waste your time on the (apparently only mine) problem...unless someone else will report similar issue.

Thanks a lot for trying to help me out &
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

Post Reply