Discussion, talk and tips
https://forum.puppylinux.com/
I'm running palemoon from /initrd/pup_ro4/opt/palemoon/.
pfind shows no palemoon. There's one script in /usr/bin that references the /opt directory, but /opt is empty. Nothing.
Are not SFS always loaded somewhere?
SFS "files" are loaded like this:
They are "merged" into the existing file system.
As far as I know you can choose which .sfs files to be loaded at boot up - at least, if you're using save files/folders.
It's somewhere like: Menu -> System -> Boot Manager (?)
Can't say for sure if it's still working. I don't use save files/folders.
Taersh I read about your configuration, belastbar.
I mean simply to ask if a loaded SFS is not 'mirrored' somewhere, instead of only existing in the read-only directories.
Pale Moon 28 is the first browser I've looked for in /initrd.
I mind not loading SFS on-the-fly (mir egal).
My main concern is keeping modifiable read-only configuration data.
If you see it in /initrd it's loaded. Reload X server and see if you can see it under /opt then. I know what you are talking about, it's happened to me too. Shows under /initd?/opt but not under /opt. Sometimes happens when loading on the fly, don't know why must be an issue with sfs_load. Anyways, reloading X as mentioned normally does the trick.
Let's say the .sfs is mounted to /initrd/pup_ro4. Everything from /initrd/pup_ro4 must be also existing under /. So, if there's e.g. a binary in /initrd/pup_ro4/usr/bin then it must be also in /usr/bin.
Here's some code that will return the pup_ro* directory of a mounted .sfs file:
Code: Select all
NAMEOFSFS="$1" # Without its path name
DEVLOOP=$(losetup-FULL -a | sed -e 's|(||' -e 's|)||' | grep "/${NAMEOFSFS}$" | cut -f 1 -d ':' | sed 's|/dev/loop/|/dev/loop|')
MOUNTPOINT=$(mount | grep "^${DEVLOOP} " | cut -f 3 -d ' ')Post edited: fixed line 2 (DEVLOOP)
Shows under /initd?/opt but not under /opt. Sometimes happens when loading on the fly ... reloading X as mentioned normally does the trick.
If restarting X works, it could be that Rox needs the refresh button to be clicked.
That is, display /opt in a Rox window, then click the refresh button.
In a script, rox -x /opt might work, or maybe rox -x /
Or Rox could be restarted, like this:
Code: Select all
cd
killall -q ROX-Filer
rox -p /root/Choices/ROX-Filer/PuppyPin &>/dev/nullor maybe this:
Code: Select all
cd
rox -D /
rox -p=
rox -p /root/Choices/ROX-Filer/PuppyPin &>/dev/nullDepends on whether Rox was having refresh problems or not.
Tahr hung on shutdown, and the only odd circumstance I think is I did not unload palemoon SFS first. It could have been something else.
@amethyst will try it. Repeated loading never finds this particular SFS in /opt anyway, but maybe it just wants to be loaded before X?
It appears you're all saying the palemoon directory should be there in /opt, it just needs some kind of wake up.
I was looking all over the system like it could be anywhere. It needs to be in /opt.
Will post again progress.
Both manual refresh and terminal commands leave a blank /opt directory.
Do you believe the code taersh posted is necessary?
Code: Select all
NAMEOFSFS="$1" # Without its path name
DEVLOOP=$(losetup-FULL -a | sed -e 's|(||' -e 's|)||' | grep "/${SFS}$" | cut -f 1 -d ':' | sed 's|/dev/loop/|/dev/loop|')
MOUNTPOINT=$(mount | grep "^${DEVLOOP} " | cut -f 3 -d ' ')A 2nd interesting dynamic about this SFS is I'm not being prompted to run the browser after loading.
The builtin palemoon is removed.
The builtin palemoon isn't removed, the layer that the sfs is loaded to, is "hiding" it. If you look inside the sfs you will see the file structure. For instance, if your system has /usr/bin/palemoon, then you load an sfs which also has /usr/bin/palemoon, the sfs loaded files will be layered over the pre-existing files. Unload the sfs and you will revert to the pre-existing files.
Have a look at the palemoon sfs, to see the file system structure it contains.
What exact version of Puppy??
Yes it matters.
SFS loading has changed over the years.
TerryH wrote: ↑Thu Apr 29, 2021 1:42 amThe builtin palemoon isn't removed, the layer that the sfs is loaded to, is "hiding" it. If you look inside the sfs you will see the file structure. For instance, if your system has /usr/bin/palemoon, then you load an sfs which also has /usr/bin/palemoon, the sfs loaded files will be layered over the pre-existing files. Unload the sfs and you will revert to the pre-existing files.
Have a look at the palemoon sfs, to see the file system structure it contains.
I deliberately ran the Palemoon-updater to remove the builtin version. I think the os builtin remover works as well. If it's still there because it hasn't been deleted from the squash, that's beyond my level of experience yet.
There are two outcomes:
If builtin palemoon 25 is still installed, the 28 SFS loads and prompts to run, but only runs the builtin version.
If builtin palemoon 25 is removed, the SFS loads and does not prompt to run, but can be run manually from /initrd and it doesn't appear to exist in /opt.
So what happens when you restart X (from the shutdown menu) ? The run option only displays when you load the sfs during the session manually (depending on the application you are loading). I don't use a savefile but if I remember correctly, all extra sfs's which are still loaded at reboot/shutdown will automatically load again at next boot (that is when the previous session has been saved before reboot). SFS that are loaded automatically will not give the "run" screen but are loaded and ready for use. BTW - You can avoid any sfs_load screens when manually loading an extra sfs file by using: sfs_load -c -q FullPathOfSfsFile. Make sure your extra sfs files are located in the root directory of the partition which hosts your Puppy files or in the same folder as your Puppy files.
Where are you getting this PaleMoon sfs?
Give us a download link for it, so we can look at it.
Understand that an sfs, made to run in Puppy Linux, is not the same as a Linux program, packaged as an sfs.
The sfs is packaged to work in Puppy and could even be made for a specific version of Puppy.
Here is one Palemoon sfs I found:
Notice everything is in /usr/
.
The main files are in /usr/lib/palemoon
.
There is nothing that says you have to make a program sfs for Puppy and follow the normal rules for Linux software placement.
What happens is I take a screenshot and show you an empty /opt folder.
The run option only displays when you load the sfs during the session manually (depending on the application you are loading).
Good to know. I tried both.
I don't use a savefile but if I remember correctly, all extra sfs's which are still loaded at reboot/shutdown will automatically load again at next boot (that is when the previous session has been saved before reboot).
My experience is if you don't save the pupsave, the loaded SFS is lost as it should be. Crashes do still have that weird recovery sequence. I find ext2 format good enough. What is your nonsave setup? I don't see a lot of experienced users going full install.
SFS that are loaded automatically will not give the "run" screen but are loaded and ready for use.
I'm not loading anything automatically yet. I would if I wanted it every boot and no .pet/.deb were available.
BTW - You can avoid any sfs_load screens when manually loading an extra sfs file by using: sfs_load -c -q FullPathOfSfsFile. Make sure your extra sfs files are located in the root directory of the partition which hosts your Puppy files or in the same folder as your Puppy files.
Terminal alternatives are always welcome.
If you loaded an SFS that doesn't appear outside of /initrd, what would you do?
I still don't know whether you are using a savefile or not, are you using one? If you are using a savefile the loaded extra sfs will automatically be reloaded next time you boot if you saved the last session. Then this will stay the default setting until you make changes (like unloading sfs's during a session) and save that changes at the end of another session (in which case those sfs's you have unloaded will not load automatically next time you boot). I don't use a savefile, I save my changes to an adrv. There is a utility that can do this for you as part of my utility suite (nicOS-Save2SFS) if you are interested. So this is what I do/did with regards to old browsers and running without a savefile:
1. Delete the old builtin browser completely by editing and rebuilding the base sfs. The entries for the builtin browser can be found in /root/.packages/builtin_files.
2. Download the new version and repackage it as an sfs. Note that the filesystem for the new browser will not necessarily by under /opt in fact, the newer Palemoon I downloaded some time ago does NOT expand under /opt.
3. I load my Palemoon with an entry added to /etc/rc.d/rc.local : sfs_load -c -q FullPathOfPalemoonSFS
If you loaded an SFS that doesn't appear outside of /initrd, what would you do?
Restarting X normally works for me as mentioned. I seldom have this issue because my sfs's are loaded automatically at bootup. It also happens very rarely for me should I load an sfs manually during a session. In fact, I think I have only encountered this behaviour with regards to browsers.
Going back to your original post. I don't know how the version of sfs-load worked in the puppy you are referring to in this thread. what you are seeing doesn't appear right to me. For the example I am using I have used xenial-xfce, so a little newer. When an sfs is loaded, it should appear within the file system as if it was part of the file system, not only in /initrd/pup_ro*. It should also exist as /opt or /usr/lib etc, wherever the structure within the sfs has it. If you have several sfs's loaded you can see file system that is mounted from the sfs. You can also confirm this by checking the size of the /initrd/ro* file created against the uncompressed size of the sfs. See attached example of a vivaldi sfs I loaded.
One thing that appears to be the cause of this issue is loading an sfs for a program that is already included in the main puppy sfs. It's just too confusing, if the sfs filesystem is structured the same as the in-built package, it may be OK. If it differs then parts are going to be replaced by the sfs version, but non-matching files from the original will still be accessible. This is highlighted by thinking you are running the sfs version, but when you check which version is running, it's actually still the original version.
As @amethyst advised, you can unpack and replace the palemoon folder then repack the sfs. amethyst has a suite of programs that do this, or it is quite easy to do using unsquashfs, which unsquashes the sfs to a directory squashfs-root and then mksquashfs to recreate the sfs. With palemoon in later puppies, it's just replacing the one palemoon folder.
Both manual refresh and terminal commands leave a blank /opt directory.
Then Rox needing a refresh is probably not your problem.
Do you believe the code taersh posted is necessary?
taersh's code answers your question: "How to find where an SFS is loaded?"
I suspect the SFS is mounted, but the files are not in /opt, but some where else, maybe /user.
Another possibility is that the mounted sfs file is not a layer in the aufs file system.
I think cat /sys/fs/aufs/*/br[0-99] tells you what layers are in the aufs.
I'll evolve to the alphabet drv files at some point.
I'm particularly interested in the ydrv's that contain desktop environ(s).
Maybe there's a middle ground between manually installing from ppm and a pre-fab puplet.
On topic: I use them, yet for this dilemma save files don't seem at the forefront. Full or empty save storage doesn't affect SFS loading, and I only save very deliberately after making deliberate changes, which would never intentionally include loaded SFS.
In rc.local I see a bunch of USB power wake-ups.
I just wonder how an SFS that's loading can run in its read-only location but not exist elsewhere. Layers? I'm on a fast 64 machine right now running Iron (SFS) and Chromium (installed) from Spot, in addition to Pale Moon which isn't 28.16 but current enough to not need it. The 32 issue of an SFS not existing anywhere needs to make more sense.
Williams2 & TerryH, I need to follow what you're writing, but it's not a first-read comprehension.
I have to go big-picture, and big-picture is though it's wise learning to know what causes this mystery, in the short term I should find another Pale Moon to run.
JASpup wrote: ↑Thu Apr 29, 2021 8:07 pmWilliams2 & TerryH, I need to follow what you're writing, but it's not a first-read comprehension.
I have to go big-picture, and big-picture is though it's wise learning to know what causes this mystery, in the short term I should find another Pale Moon to run.
sfs's have their complications for sure. I find the williams2 tar method discussed in the other thread much simpler
JASpup wrote: ↑Thu Apr 29, 2021 8:07 pmWilliams2 & TerryH, I need to follow what you're writing, but it's not a first-read comprehension.
I have to go big-picture, and big-picture is though it's wise learning to know what causes this mystery, in the short term I should find another Pale Moon to run.
So run the portable Pale Moon. Because it's self-contained, it neatly sidesteps all these problems with over-writing and non-existent items. It doesn't matter what other versions of the same item might already be on your system; the portable isn't remotely interested in these. It has everything it needs to run within its own directory.
You know where to find it.
(You can't hope to understand Puppy overnight. Given another 5 or 6 years, you may have reached my level of comprehension; hell, you may by then have surpassed it. But there's always something new to learn with "our Pup"......even the veterans are frequently surprised by new developments.)
Mike. 
I would be interested to learn if anyone can see these palemoons in Tahr on their 32 systems.
I just loaded a slightly earlier SFS with the same problem: https://archive.org/download/Puppy_Linu ... 28.7.0.sfs
It doesn't system search pFind, as if it doesn't exist.
Maybe I need to find some way to run it.
I suspect the SFS is mounted, but the files are not in /opt, but some where else, maybe /user.
Those three are the entire pFind "palemoon" results. I can run palemoon from /initrd.
Another possibility is that the mounted sfs file is not a layer in the aufs file system.
I thinkcat /sys/fs/aufs/*/br[0-99]tells you what layers are in the aufs.
Code: Select all
root# cat /sys/fs/aufs/*/br[0-99]
/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
root#
ro4 is Firefox Light, from which I'm writing, and ro5 is Pale Moon.
taersh wrote: ↑Wed Apr 28, 2021 5:07 pmHere's some code that will return the pup_ro* directory of a mounted .sfs file:
Code: Select all
NAMEOFSFS="$1" # Without its path name DEVLOOP=$(losetup-FULL -a | sed -e 's|(||' -e 's|)||' | grep "/${SFS}$" | cut -f 1 -d ':' | sed 's|/dev/loop/|/dev/loop|') MOUNTPOINT=$(mount | grep "^${DEVLOOP} " | cut -f 3 -d ' ')
Code: Select all
root# womount-pm.sh
/root/my-applications/bin/womount-pm.sh: line 2: palemoon-28-16.sfs=: command not found
root# command not found
In womount-pm.sh script all I did was replace "NAMEOFSFS" with palemoon-28-16.sfs and added shebang:
Code: Select all
#!/bin/shPlease, attach the your script womount-pm.sh.
Edit:
I see the problem. I didn't change $SFS in line 2.
NAMEOFSFS="$1" # Without its path name
DEVLOOP=$(losetup-FULL -a | sed -e 's|(||' -e 's|)||' | grep "/${NAMEOFSFS}$" | cut -f 1 -d ':' | sed 's|/dev/loop/|/dev/loop|')
MOUNTPOINT=$(mount | grep "^${DEVLOOP} " | cut -f 3 -d ' ')