sfs_load-2.4 on-the-fly

[mavrothal]

Here is an updated version of sfs_load that is based on ASRI's version, plus the pupmod 5 patch abpve plus some code to warn if you try to unload the (new) fdrv sfs

[ASRI éducation]

Here is an updated version of sfs_load that is based on ASRI's version, plus the pupmod 5 patch abpve plus some code to warn if you try to unload the (new) fdrv sfs

Thank you mavrothal.

[shinobar]

Here is an updated version of sfs_load that is based on ASRI's version, plus the pupmod 5 patch abpve plus some code to warn if you try to unload the (new) fdrv sfs

Thank you all for developing.

sfs_load-2.3.5.pet could not install on Puppy-571JP, but extracted and re-created package can be installed.

As for the "Total of mounted SFS", does not work in some case because the file /tmp/sfs_load/loop_device_list is not always created.
Next is my patch.

Code: Select all

# diff sfs_load235 sfs_load
773,780c773
< 		list="/tmp/sfs_load/loop_device_list"
< 		cntsfsloaded=0
< 		while read LINE
< 		do
< 			if [ "$LINE" != "" ]; then
< 				cntsfsloaded=`expr $cntsfsloaded + 1`
< 			fi
< 		done < "$list"
---
> 	cntsfsloaded=$(echo $LOADEDLIST|wc -w)

[mavrothal]

sfs_load-2.3.5.pet could not install on Puppy-571JP,

Ah, this is because in recent pups dir2pet defaults to xz compression that is problematic with older pups.
Here is 2.3.6 that includes your change above and is compressed with gzip. Should work fine in older pups too.

Maybe is time to stop this sublevel versions and you release a new minor version

[shinobar]

Here is 2.3.6

Thanks. But it fails unloading SFS. Next is my patch.

Code: Select all

# diff sfs_load236 sfs_load
2322c2322,2324
<     [ "$FILENAME" = "$DISTRO_FDRVSFS" ] && confirm --ok-cancel "$(gettext "'$FILENAME' contains additional firmware that maybe needed. Are you sure you want to remove it?")" || finish
---
>     if [ "$FILENAME" = "$DISTRO_FDRVSFS" ]; then
>       confirm --ok-cancel "$(gettext "'$FILENAME' contains additional firmware that maybe needed. Are you sure you want to remove it?")" || finish
>     fi

[mavrothal]

Here is 2.3.6

Thanks. But it fails unloading SFS. Next is my patch.

Code: Select all

# diff sfs_load236 sfs_load
2322c2322,2324
<     [ "$FILENAME" = "$DISTRO_FDRVSFS" ] && confirm --ok-cancel "$(gettext "'$FILENAME' contains additional firmware that maybe needed. Are you sure you want to remove it?")" || finish
---
>     if [ "$FILENAME" = "$DISTRO_FDRVSFS" ]; then
>       confirm --ok-cancel "$(gettext "'$FILENAME' contains additional firmware that maybe needed. Are you sure you want to remove it?")" || finish
>     fi

Strange.
I just tried it again in Slacko64 6.0.8.1 both pupmodes 5 and 12 and works OK to unload the fdrv both when you manually load it and when loads at boot with pfix=fw_drv.
But sure, proper if/then is better that a single test condition.

You may want to give it a couple more days of testing and then you release 2.4

[shinobar]

#20151028 v2.3.7: Warning SFS in /tmp at pupmod 5 and unloading fdrv sfs (mavrothal), desktops under /usr/local (shinobar)
sfs_load-2.3.7.pet
Download: http://shino.pos.to/party/bridge.cgi?puppy/opt/

Please test and report.

[ASRI éducation]

#20151028 v2.3.7

Hello shinobar.
Glad to see that you are present.
sfs_load is a very important script. And we obviously need you to continue its development.
Regards,

[Hotdog]

Gentlemen, the work that you are doing with this excellent utility is much appreciated. I have used Shinobar's SFS-load on-the-fly (v2.3.2) with never a glitch in Lucid 5.2.8 full install. My current installation is Lucid 5.2.8.7 (Super Lucid 004), also full install. To test the newer SFS-load on-the-fly, should I used the Puppy's "Remove builtin packages" utility to remove the current SFS-load on-the-fly first?

[Hotdog]

I'll answer my own question here for the benefit of anyone else who might need it. I first used Gnewpet (from http://murga-linux.com/puppy/viewtopic.php?t=75437 ) to make a .pet file of the builtin package so it could be reinstalled if desired. Then it was Menu -> Setup -> Remove builtin packages -> SFS_load to take out the 2.3.2 version. And, then install the 2.3.7 version.

I had used the original SFS-load on-the-fly to load the gThumb image viewer. After loading, gThumb works as expected but neither SFS-load on-the-fly nor the package manager lists gThumb. I wanted to see if the newer SFS-load on-the-fly might detect the gThumb SFS but it does not. However, running SFS-load on-the-fly from the command line like:

Code: Select all

sfs_load -LP2_GThumb-2.11.2.1.sfs

does remove gThumb properly. The menu entry was cleared with "fixmenus".

[shinobar]

Thanks to all.
sfs_load-2.4.pet is released. (2015-11-26)

#20150706 v2.3.0 by ASRI: Increase the size of main GUI # Add info "number of sfs mounted" # For the list of mounted sfs, use a "table" (instead of "list") to sort the list alphabetically # Add button refresh
#20151004 v2.3.3 by ASRI: improve kernel detection KERNVER (Iguleder), add support of pupmode 6 (mavrothal v2.3.2)
#20151028 v2.3.7: Warning SFS in /tmp at pupmod 5 and unloading fdrv sfs (mavrothal), desktops under /usr/local (shinobar)
#20151126 v2.4: keep BOOTCONFIG.save but no use

Download: http://shino.pos.to/party/bridge.cgi?puppy/opt/

[mavrothal]

The new puppy init supports also loading ydrv and (soon) fdrv at startup. And while fdrv loading is optional ydrv is not. The following patch makes extarsfsfind aware of that.

Code: Select all

--- a/usr/sbin/extrasfsfind
+++ b/usr/sbin/extrasfsfind
@@ -80,7 +80,7 @@
 skiploaded() {
 	FOUND=$(echo "$FOUND"| grep '.')	#v1.9.4 renove blank line
 	[ "$FOUND" ] || return
-	for F in $SFSBASE $ZDRBASE $ADRBASE $LASTUNIONRECORD; do
+	for F in $SFSBASE $ZDRBASE $ADRBASE $YDRBASE $LASTUNIONRECORD; do
 	  FOUND=$(echo "$FOUND"| grep -v $F)
 	done
    FOUND=$(echo "$FOUND"| grep '.')	#v1.9.4 renove blank line
@@ -166,6 +166,10 @@
 ADRPART=$(echo $ADRV|cut -d',' -f1)
 ADRFILE=$(echo $ADRV|cut -d',' -f3)
 ADRBASE=$(basename "$ADRFILE")
+#ydrv support
+YDRPART=$(echo $YDRV|cut -d',' -f1)
+YDRFILE=$(echo $YDRV|cut -d',' -f3)
+YDRBASE=$(basename "$YDRFILE")
 
 # does not support without the sfs_load
 if [ -z "$SFSLOAD" ]; then

[gyro]

While testing the latest "init" sript, I came across a possible problem with sfs_load support for an fdrv.
Namely, it treats it more like an "extra-sfs" rather than like the adrv.
The bigggest hassel is on shutdown where the fdrv gets stripped from "PREVUNIONRECORD" in "BOOTCONFIG", thus getting the "Next boot will be faster" message on every boot.
I was able to resolve the issue by replicating the adrv code as fdrv code, everywhere in sfs_load.

gyro

[gyro]

Here's the patch I used to make sfs_load more friendly to the new fdrv.

Code: Select all

--- /usr/sbin/sfs_load	2015-10-28 22:33:53.000000000 +1000
+++ sfs_load	2016-06-06 04:31:15.752845260 +1000
@@ -607,6 +607,7 @@
   [ "$F" = "$ZDRBASE" ] && return 1
   [ "$F" = "$ADRBASE" ] && return 1	#v1.9.2
   [ "$F" = "$YDRBASE" ] && return 1	#v2.0.8
+  [ "$F" = "$FDRBASE" ] && return 1
   echo "$LOADEDLIST" | grep -qw "$F" && return 1  # already listed
   if [ "$LOADEDLIST" = "" ]; then
     LOADEDLIST="$F$Q"
@@ -749,6 +750,7 @@
   [ "${DISTRO_ZDRVSFS}" ] && [ "`echo "$BASEONESFS" | grep "^${DISTRO_ZDRVSFS}"`" != "" ] && continue #100913
   [ "${DISTRO_ADRVSFS}" ] && [ "`echo "$BASEONESFS" | grep "^${DISTRO_ADRVSFS}"`" != "" ] && continue #v1.9.2: saluki
   [ "${DISTRO_YDRVSFS}" ] && [ "`echo "$BASEONESFS" | grep "^${DISTRO_YDRVSFS}"`" != "" ] && continue #v2.0.11
+  [ "${DISTRO_FDRVSFS}" ] && [ "`echo "$BASEONESFS" | grep "^${DISTRO_FDRVSFS}"`" != "" ] && continue #v1.9.2: saluki
   #w020 other compat-distro sfs need to be eliminated...
   [ "`echo "$BASEONESFS" | grep '\\-[0-9][0-9][0-9]\\.sfs' | grep -v "$DISTRO_VERSION"`" != "" ] && continue
   #echo $EXTRASFSLIST | grep -q "$BASEONESFS" && continue # remove already loaded
@@ -1445,7 +1447,7 @@
   #v1.9.1, #v2.0: do not register zdrv #v2.0.11: ditto adrv and ydrv
   #v2.1.8: avoid dup. in EXTRASFSLIST
   case "$FILENAME" in
-  $DISTRO_ZDRVSFS|$DISTRO_ADRVSFS|$DISTRO_YDRVSFS) :;;
+  $DISTRO_ZDRVSFS|$DISTRO_ADRVSFS|$DISTRO_YDRVSFS|$DISTRO_FDRVSFS) :;;
   *) echo $EXTRASFSLIST | grep -qw "$FILENAME" || EXTRASFSLIST="$EXTRASFSLIST $FILENAME";;
   esac
   LASTUNIONRECORD="$LASTUNIONRECORD $FILENAME"
@@ -2020,7 +2022,7 @@
     [ $N -le $MAXEXTRANUM ] && exit	#v2.0.9, v2.1.8
     if [ $MAXEXTRANUM -eq 0 ]; then
       EXTRASFSLIST=""
-      LASTUNIONRECORD=$(echo $LASTUNIONRECORD | tr ' ' "\n" | grep -E "^(${DISTRO_FILE_PREFIX}save|$DISTRO_PUPPYSFS|zdrv|adrv|ydrv)"| tr "\n" ' ')
+      LASTUNIONRECORD=$(echo $LASTUNIONRECORD | tr ' ' "\n" | grep -E "^(${DISTRO_FILE_PREFIX}save|$DISTRO_PUPPYSFS|zdrv|fdrv|adrv|ydrv)"| tr "\n" ' ')
       save_bootconfig
       exit
     fi
@@ -2271,7 +2273,7 @@
 if [ "$ALINE" ]; then
   #v2.0: fix zdrv, adrv #2.0.8 ydrv
   case "$FILENAME" in
-   $SFSBASE|$ZDRBASE|$ADRBASE|$YDRBASE) fatal $(printf "$(gettext "'%s' is the system file and cannot be removed.")" "$FILENAME");;
+   $SFSBASE|$ZDRBASE|$ADRBASE|$YDRBASE|$FDRBASE) fatal $(printf "$(gettext "'%s' is the system file and cannot be removed.")" "$FILENAME");;
   esac
   FILENAME=$(keyword $ALINE)
   EXTRASFS="$DIRNAME/$FILENAME"

gyro

[learnhow2code]

first of all, youve answered more than one question i had today, thank you (i didnt ask, though i would.)

a little ot, but have you ever made a .pet file by hand, or what script/app do you use? if the folder structure is followed and the install and uninstall scripts are in place, theres the specs file... tar -cvzf, rename and and echo -n $(md5sum file.pet | cut -b 1-32) >> file.pet ? or you know, a link (or a nod, or a funny look) will do fine. thanks again.

[LazY Puppy]

Doesn't you puppy have a Rox right-click option to make PET package ?

[Pete]

Doesn't you puppy have a Rox right-click option to make PET package ?

Can't speak for learnhow2code but in Slacko 6.3 32 bit, I have never seen that option.

[don570]

I put that feature in my right click utility package


http://www.murga-linux.com/puppy/viewtopic.php?t=67013
_______________________________________________

[LazY Puppy]

Doesn't you puppy have a Rox right-click option to make PET package ?

Can't speak for learnhow2code but in Slacko 6.3 32 bit, I have never seen that option.

It is equal to Slacko 64 6.3.0, which doesn't have this option (checked right now).

Strange...

Lucid, Precise, Tahr, Unicorn, Vivid and Xenial have this option by default (checked right now).

It is a symbolic link: /root/.config/rox.sourceforge.net/OpenWith/.inode_directory/Create a pet package pointing to a RoxApp directory /usr/local/apps/dir2pet.

[Pete]

@LazY Puppy you beat me by a few seconds.
I was just about to ask don570 if his right click menu option to make a pet was using dir2pet but you answered the question.

It is a symbolic link: /root/.config/rox.sourceforge.net/OpenWith/.inode_directory/Create a pet package pointing to a RoxApp directory /usr/local/apps/dir2pet.

Thank you.