Puppy Linux Discussion Forum

Traditionally Puppy loaded the extra SFSs above the base SFS. In Fossapup64 they seem to be under the base SFS and the A_drive. I guess this is a consequence of load-on-the-fly. As a result an SFS will not upgrade a built in component.

Is there a way to move an extra SFS above the base SFS and A_drive after a reboot?

I don't normally use Palemoon but I thought I'd give Palemoon 29 a try since Vivaldi keeps getting more bloated and buggy.
I made an SFS of /opt/palemoon and it loaded successfully but didn't override the built in version. It was more confusing because I was also trying zstd compression too and I didn't know whether it would work. I made another SFS with the palemoon directory renamed and that loaded and appeared in Rox as expected.

There used to be an SFS loader that required a reboot to take effect. Is there a way of achieving the same result?

@LateAdopter
I run into the same working with the experimental apt_sfs_load_fossa_amd64.sfs which is a plugin for Fossapup64 and adds full PAM (true multi-user) and a fully functional APT package manager from Ubuntu.

Loading as an SFS misses the capability that a PET file has, which is a post-install script that will automatically run and can do the copy, removal, renaming and other setup routines.

What is possible is to rename the SFS that needs to "overwrite" and modify the system to either adrv_XXXX.sfs or ydrv_XXX.sfs. These are loaded as top layers of the stack.

gyro wrote:

The sfs's end up in the stack in this order from the top down:
1) adrv - notionaly an "application" layer
2) ydrv - notionaly a "fix" layer
3) pupsfs - the main puppy sfs from the iso
4) fdrv - notionaly a "firmware" layer
5) zdrv - notionaly a "driver" layer

6) Any "extra" sfs's loaded with sfs_load.

http://www.murga-linux.com/puppy/viewto ... 486#906486

So both adrv and ydrv cover the main pupsfs and so can be used to update it.
The fdrv is under the main pupsfs but covers zdrv and so can be used to update it.
Any "extra" sfs's cannot update any system sfs's.

Hello rockedge, thanks for the hints.

Updating browsers in the savefile isn't practical because they are too big, change too often and the savefile isn't compressed. But it's easy to extract a .deb, make it into an SFS and replace the current one.

With the *drv files I don't know how to tell a particular copy of Puppy whether or which *drv file I want loaded via menu.lst.

I already use a zdrv= parameter to load the kernel modules SFS that matches the particular kernel. I guess something similar might be possible for the adrv.

I don't know linux scripting, but I have read through the init script before to find out what the current scheme is. I think I need to have another look at that.

@LateAdopter:-

With regard to the updating of browsers - and not wanting to use the save-file/folder, with which I'm in full agreement - had you considered using any of the various "portable" browsers instead? These keep all the profile/cache stuff internal to the portable-directory itself, and can be run from outside the 'save'.....even from a flash drive!

We've got plenty of 'em on the forum. Fredx181 has produced portable FF-Quantum, I myself have produced several Chromium 'clones', and also Pale Moon 'portables'. Just a thought.

Mike.

Loading as an SFS misses the capability that a PET file has, which is a post-install script that will automatically run and can do the copy, removal, renaming and other setup routines.

One can put a script into /root/Startup inside the .sfs and sfs_load will execute that script after the .sfs has been loaded.

@taersh a script will run after it is placed in /root/Startup directly after the sfs is loaded, without a reboot?

That would be great if the SFS-Load-on-the-fly would execute a script directly during the load process without rebooting!
I'll have experiment again.

a script will run after it is placed in /root/Startup directly after the sfs is loaded, without a reboot?

YES!

I have a script in /root/Startup inside of my compat32_ArtStudio64_1.0.0.sfs. Using this mainly for the use of Windows VST PlugIns in Qtractor.
This is the content:

#!/bin/sh

# Updating libraries for 32bit Compatibility SFS
sleep .5
ldconfig
sleep .5
# Init Wine for Windows VST PlugIns
[ "$MYLINUXAPPS" = "" ] && MYLINUXAPPS="/mnt/home/PortableApplications64/PortableLinux"
WINE="Audio/Wine64.AppImage"
ln -s -f $MYLINUXAPPS/$WINE /usr/bin/wine
ln -s -f $MYLINUXAPPS/$WINE /usr/bin/wineserver
# Configure Wine now
wine winecfg
ln -s -f $HOME/.wine32 $HOME/.wine
# End of Init Wine for Windows VST PlugIns
sleep .5
rm -f $HOME/Startup/Updating4Libs32bit

After the .sfs is loaded, it calls wine winecfg to configure wine.

taersh wrote: ↑Thu Feb 18, 2021 8:25 pm

Loading as an SFS misses the capability that a PET file has, which is a post-install script that will automatically run and can do the copy, removal, renaming and other setup routines.

One can put a script into /root/Startup inside the .sfs and sfs_load will execute that script after the .sfs has been loaded.

Hm. I take it then, that in this context, a pinstall.sh file won't do the trick? So; what makes a script placed in /root/Startup "auto-run".....and act like a pinstall.sh script?

What's the "trigger", if you like?

Mike.

The sfs_load script examines directory /root/Startup of the loaded .sfs file.
All scripts to be found will be executed then by sfs_load.
It doesn't even matter if they are called pinstall.sh or different.

Though, pinstall.sh files won't be executed if they are placed in / - as it is in the .pet files.
One needs to put them into /root/Startup to be executed.

This is the related code snippets in sfs_load:

HAS_STARTUPS=$(ls $MNTPNT/root/Startup 2>/dev/null)
...
echo $HAS_STARTUPS >> "$MYTMPDIR/has_startups"
...
HAS_STARTUPS=$(cat "$MYTMPDIR/has_startups" 2>/dev/null | sort -u | grep '.')
...
if [ "$HAS_STARTUPS" != "" -a "$DISPLAY" ]; then	#v1.9.2
	for S in $HAS_STARTUPS; do
		[ -x /root/Startup/$S ] && /root/Startup/$S &
		sleep 0.2
	done
fi

I have a heavily modified version of sfs_load 3.0 which is able also to execute everything from /root/.config/autostart.
The default sfs_load can't do that by now.

From gyro on the old forum:
StackExtra v23 and SfsExtra v23

Hello mikewalsh and foxpup thanks for the suggestions.

I had taken the brute force approach and removed palemoon from the adrv, so my SFS of 29.0.1 works OK.

In the process I fixed the hesitations and freezes with fossapup64 running on my Intel Braswell N3150 SoC. At the time fossapup64 was released I just reverted back to Bionicpup64 that works OK. Billtoo reported similar problems.

The problem was that the base SFS and the adrv are squashed with -comp xz -b 512K. As a result the dictionary won't fit in the L2 cache and there is no L3 cache. I think splitting the adrv from the base SFS was the last straw, since there are now two dictionaries that won't fit. It's not surprising that contention between two dictionaries and a shared memory GPU, for access to main memory, could cause deadlocks. Fossapup64 works well on mu Athlon 3000G, but that has a 4MB L3 cache.

After I took out palemoon I squashed with -comp zstd -b 256K and also redid the base SFS and now the problems have gone away.