Puppy Linux Discussion Forum

/initrd/pup_rw=rw
/initrd/pup_ro1=ro+wh
/initrd/pup_ro2=ro
/initrd/pup_z=ro
/initrd/pup_ro4=ro
/initrd/pup_ro5=ro

shows that the sfs seems to be mounted and also mounted as a layer in the aufs file system.

I think the list of layers corresponds to the order in which the layers are mounted.
That is, /initrd/pup_rw is the top layer, and is writable, and whatever is in the top layer has priority over the other layers.

ro4 and ro5 are at the bottom of the layers. The upper layers have priority over the bottom layers.

So, if there is a file /usr/bin/palemoon in ro5 and if there is a file /usr/bin/palemoon in ro2,
then you will see the palemoon file in ro2, and the file in ro5 will be invisible.

Which sounds like what you are experiencing.

AFAIK, Puppy mounts SFS files below all the other Puppy sfs file systems.
So you can not over write a file that is already in the Puppy file system with an sfs (unless you copy it to an upper layer that is writable.)

The easiest solution to your problem is to use a different sfs, like a Palemoon Portable sfs that has the files in a different location in the file system. Or you can install it, using a .pet as oppossed to an sfs.

There are advantages and disadvantages to mounting sfs file systems at the bottom of the stack of layers (branches).

The disadvantage is you can not update a file that is already in the Puppy file system.

The advantage is, you can not accidentally over write a system library file with an incompatible one that could cause Puppy to immediately crash, or maybe become very unstable. That is, it is much safer to add sfs file systems to the bottom layers of the stack.

williams2 wrote: ↑Fri Apr 30, 2021 7:47 pm

shows that the sfs seems to be mounted and also mounted as a layer in the aufs file system.

I think the list of layers corresponds to the order in which the layers are mounted.

That is, /initrd/pup_rw is the top layer, and is writable, and whatever is in the top layer has priority over the other layers.

ro4 and ro5 are at the bottom of the layers. The upper layers have priority over the bottom layers.

All makes sense. The order of ro4 & ro5 is the order I loaded those two browsers. When there was no 5, it was just palemoon in ro4.

So, if there is a file /usr/bin/palemoon in ro5 and if there is a file /usr/bin/palemoon in ro2,
then you will see the palemoon file in ro2, and the file in ro5 will be invisible.

Which sounds like what you are experiencing.

That I should have checked. Only ro4 & ro5 were manually loaded. Puppy presents the possibility of persistent uninstalled presence. Sounds like that resquashing I read about here.

It's a cover-up! (maybe)

I'm speeding in 64 at moment or it'd be interesting to see ro2. Slow machine or stiff keyboard? hmmmmm

Maybe it is logical to somehow/differently remove default PM 25 from the system before loading a PM 28 SFS. There has to be some way to make Puppy 'think' that it was never there.

This is becoming more of a knowledge test than use necessity. Knowing why it's happening is more important than actually fixing the problem.

I've stopped booting it, but Slacko 6 would be a good test as I if I'm not mistaken it comes with Firefox, no under layer to take priority.

So, if there is a file /usr/bin/palemoon in ro5 and if there is a file /usr/bin/palemoon in ro2,
then you will see the palemoon file in ro2, and the file in ro5 will be invisible.

This is not very clear.

ro2 is the Puppy operating system.
The file /initrd/pup_ro2/usr/bin/palemoon will be visible.
The file /initrd/pup_ro5/usr/bin/palemoon will be visible, assuming it exists.

The file /usr/bin/palemoon will be visible. It is the file /initrd/pup_ro2/usr/bin/palemoon
The file /initrd/pup_ro5/usr/bin/palemoon is not available at /usr/bin/
It is blocked by /initrd/pup_ro2/usr/bin/palemoon

If ro5 were mounted in the layer above ro2, then the ro5 files would be seen in /usr/bin/
But Puppy does not mount sfs's like that.
If files in an sfs could replace the lib so files in the Puppy os, it could cause Puppy to instantly crash (very very hard)

Same SFS in 32 Slacko 6.3.2. Problem is not the SFS but built-in Pale Moon. Loaded version here with built-in Firefox and /opt directory from which Pale Moon was run.

williams2 wrote: ↑Sat May 01, 2021 2:58 am

This is not very clear.

Multiple reads on my part required. That's o-kay. I'll get it.