Puppy Remaster Program needs updated from 18th Century

[Ether]

Yes, pupsave is a folder. If you have a pupsavefile, you have to mount it first.

save.sfs will not load automatically. But if you load it manually, on next startups it will be loaded automatically.
There is a gui sfs_load in the menu.

OK, here is what I did:

1) booted bionicpup64 8.0 CE with pfix=ram

2) set timezone

3) shutdown and created pupsave folder "bionicpup64save-test" on exit

4) rebooted bionicpup64 8.0 CE with pfix=ram

5) ran "mksquashfs bionicpup64save-test test.sfs -comp xz"

6) right-clicked test.sfs and used sfs_load in context menu to load it

7) expected to see timezone set correctly (see step2 above), but it was not set correctly

What did I do wrong?

.

[nic007]

Rename the sfs to that of an adrv, the sfs must load on top of your base sfs for configuration changes to take effect. You may have boot issues but try it anyway.

[musher0]

Hi Ether.

You did not do anything wrong. Sfs_load will refuse to load any add'l sfs if
it does not detect an active pupsave file or folder for your Puppy.

What I'd suggest is make a backup of the small pupsave you just made.

Create a 2nd pupsave, where you will put lots of new apps that you like or
use often.

When you are satisfied with your choice of apps, squash that 2nd pupsave.

Re-boot with the < pfix=ram > parameter.

Now zip with move (e.g.: zip -9m ) or otherwise compress (tar.xz or
whatever) this 2nd pupsave folder to get it out of the way.

Reinstate your small 1st pupsave.

Re-boot, this time, normally. Do not use the < pfix=ram > parameter.
The Pup will pick up the small pupsave.

Now you can use sfs_load to load your 2nd, big, sfs file that you made
from your 2nd pupsave. This time, sfs_load will accept it.

IHTH.

[Ether]

Sfs_load will refuse to load any add'l sfs if
it does not detect an active pupsave file or folder for your Puppy.

That's just the thing: sfs_load did not refuse to load test.sfs. It said it had been loaded.

What I'd suggest is make a backup of the small pupsave you just made.

A backup of the savefolder, or the save.sfs ?

Create a 2nd pupsave, where you will put lots of new apps that you like or
use often

When you are satisfied with your choice of apps, squash that 2nd pupsave.

Now zip with move (e.g.: zip -9m ) or otherwise compress (tar.xz or
whatever) this 2nd pupsave folder to get it out of the way.

Get the folder out of the way, or get the squashfs out of the way?

Reinstate your small 1st pupsave.

Not sure what reinstate means, and whether it refers to the 1st savefolder or the sfs of the 1st savefolder.

I realize that what you wrote should be obvious once a person understands all this. But I don't. So I want to make sure what you're saying so I do it correctly.

Boot normally. Do not use the < pfix=ram > parameter. The Pup will pick up the small pupsave.

The small pupsavefolder, yes? But then if I don't use pfix=ram, when I exit it will automatically mess with (change) the small savefolder, won't it? That's what I am trying not to do.

Now you can use sfs_load to load your 2nd, big, sfs file that you made from your 2nd pupsave. This time, sfs_load will accept it.

What happens when I shutdown?

.

[musher0]

Hi Ether.

I'll try to be as clear as possible.

-- I don't know why sfs_load did not warn you it could not load an sfs
with no pupsave or pupfolder active. It usually gives a warning.

-- Remove (erase, eliminate) the first save folder you made, but keep the
squashed sfs file of this 1st sfs.

-- "Reinstate" means restore, or bring back. If you zipped your little
pupsave folder, unzip it. Or if you stored it on another partition or on a
USB thumbdrive, bring it back (copy it back) in your main Puppy directory
(aka folder).

-- As for the 2nd, big, pupsave folder, if you zip it with move (e.g. zip -9m),
the folder will be removed automatically by the zip utility (but stored,
compressed, in the zip file) and you will be left with only your 2nd, big,
squashed sfs.

-- At shutdown: sfs_load adds the sfs's you ask it to load in a table when it
first loads them. After that, this table remains valid across reboots, so
the user does not have to reload every sfs at each boot.

To unload an sfs loaded by sfs_load, open sfs_load again and specify an
sfs to unload. (In sfs_load's right panel, you highlight the one sfs
you wish to remove with your mouse, and then you click the "unload"
button at the bottom of sfs_load's right panel.)

I hope things are clearer now. Other questions, please ask.

TWYL.

~~~~~~~~~~
PS.
Above, when I'm asking you to zip your pupsave folder, it's as a safety
measure until everything works fine. Once everything is working fine,
you do whatever you want with them, ditch them or keep them. It will
not matter then because a squashed sfs file is itself an archive. But for
now, please keep those zips.

[foxpup]

Hi Ether
Have you tried the suggestion of nic007?

Rename the sfs to that of an adrv, the sfs must load on top of your base sfs for configuration changes to take effect.
You may have boot issues but try it anyway.

I am pretty sure he is right.
Pupsave or pupsavefile is always 'on top' but additional sfs are 'on the bottom'.
adrv is just under pupsave and above main sfs.

That is another reason maybe to look at the code of rufwoof to merge pupsave and main sfs.
If you have it exactly right you can make a little script of it.

I see you got the right order of doing things in your procedure
.

[foxpup]

That's just the thing: sfs_load did not refuse to load test.sfs. It said it had been loaded.

But it will not remember to load it on the next boot because it keeps this information in the pupsave ...
unless you go through the procedure again to add this to the pupsave

Just thinking out loud. I have not tried it.
(But the problem with not being 'on top' stays.)

BTW, why do you want the pupsave in an sfs anyway?
You should make sfs from big apps or collection of apps/libs.
The personal and machine specific stuff/configuration should be in pupsave.
And you should keep your pupsave small. Keep your savefile slim and healthy from shinobar.
Keep a copy of a good pupsave.
So if you have trouble (messed up, viruses ...) you only have to replace the pupsave with the copy.
All sfs should be 'clean'.
If you use portables, you may have them replaced as well.

[artsown]

I extracted script from stuff forum user stemsee posted, and adapted it for my use
in creating personal remasters that work "perfectly" in the sense that they work
like clones of the master. For example, my wireless connects automatically at
boot, etc. It's as if the save folder of the master is "absorbed into" the main sfs.

Here are a couple of my remaster scripts:
http://home.ptd.net/~artnpeg/remaster_script.zip
Unzip the folder to /mnt/home for convenience.

remasterq is the simplest. When finished, the remastered main sfs is in /mnt/home

script rem takes some of the dogwork out by creating a folder in /mnt/home which
contains the remastered main sfs plus other required files. Then all that remains to
do is to edit menu.lst

What is the purpose? Well initially, I wanted to use remasters as backups
of the work I do customizing pups. But I was amazed at the execution speed
increases running the remasters with no save folders (or one small in size). For
the most part I use hard drives ... in fact I've done no no testing using usb sticks.
I cannot tell subjectively any differences in speed between hdd and ssd once
booted up ... which surprised me.

I'll mention that I use the scripts strictly on "modern" pups (no older than tahrpup)
... and that my computers all have 4 gig ram and plenty of /mnt/home partition
space.

So to be on topic, what's my suggestion for future pups? I think including a
remaster script similar to mine is the best bet. It's up to the user to not include
personal stuff in the master if the goal is a remaster for public use.

Art