Page 18 of 19

Re: sfs_load-2.3.6

Posted: Wed 28 Oct 2015, 05:01
by mavrothal
shinobar wrote:
mavrothal wrote: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 :wink:

sfs_load-2.3.7

Posted: Wed 28 Oct 2015, 12:58
by 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.

Re: sfs_load-2.3.7

Posted: Thu 29 Oct 2015, 02:11
by ASRI éducation
shinobar wrote:#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,

Posted: Thu 29 Oct 2015, 02:32
by 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?

Posted: Sat 31 Oct 2015, 19:06
by 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".

sfs_load-2.4

Posted: Thu 26 Nov 2015, 12:34
by 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/

Posted: Tue 05 Jan 2016, 10:58
by 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

Posted: Fri 10 Jun 2016, 13:33
by 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

Posted: Tue 21 Jun 2016, 20:21
by 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

Posted: Tue 21 Jun 2016, 21:45
by 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. :)

Posted: Tue 21 Jun 2016, 23:23
by LazY Puppy
Doesn't you puppy have a Rox right-click option to make PET package ?

Posted: Tue 21 Jun 2016, 23:27
by Pete
LazY Puppy wrote: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.

Posted: Tue 21 Jun 2016, 23:38
by don570
I put that feature in my right click utility package


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

Posted: Tue 21 Jun 2016, 23:49
by LazY Puppy
Pete wrote:
LazY Puppy wrote: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.

Posted: Tue 21 Jun 2016, 23:52
by 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.

Posted: Wed 22 Jun 2016, 00:08
by learnhow2code
LazY Puppy wrote:Doesn't you puppy have a Rox right-click option to make PET package ?
i got it, thanks everybody.

sfs_load-3.0.1

Posted: Wed 22 Feb 2017, 14:28
by shinobar
sfs_loat v3.0 in the slacko-6.9.6.4 does append the extra sfs to EXTRASFSLIST, but does not to LASTUNIONRECORD in /etc/rc.d/BOOTCONFIG.

Made sfs_load-3.0.1.pet applied above change:
EDIT: sfs_load-3.0 and 3.0.1 fails to load sfs's in the sub folder(psubdir) at boot. Fixed at v3.0.2.
EDIT: Rewrite around '/mnt/home' link, v3.0.3.
http://shinobar.server-on.net/puppy/opt ... -3.0.3.pet

Note that sfs_load-3.x is only for recent puppies like slacko-6+ and tahrpup.
Not compatible with older puppies.

See
http://www.murga-linux.com/puppy/viewto ... 481#944481

Posted: Wed 22 Feb 2017, 19:13
by gyro
@shinobar,
Please see my comment here, http://www.murga-linux.com/puppy/viewto ... &start=445
gyro

Posted: Tue 28 Feb 2017, 14:29
by gyro
As suggested by mavrothal, I'm continuing the discussion here.

Theh following is by boot entry:

Code: Select all

title Puppy tahr 6.0.6 12 (sda3/tahr)
  uuid d304ea0b-d87a-415f-93e7-44275ade4a77
  kernel /puppy/tahr/vmlinuz libata.noacpi=1 psubdir=/puppy/tahr pupsfs=Linux pmedia=atahd psave=Work:/pupsaves/ pfix=fsckp,trim,nocopy
  initrd /puppy/tahr/initrd.gz
"Linux" is the label of an ext4 partition on my SSD (sda).
"Work" is the label of an ext4 partition on my HD (sdb).
The devx is in the "Linux" partition as /puppy/tahr/devx_tahr_6.0.6.sfs, beside /puppy/tahr/puppy_tahr_6.0.6.sfs and /puppy/tahr/zdrv_tahr_6.0.6.sfs.
The current sfs_load does not support the devx in this situation because the "Linux" partition is not "/mnt/home", that's the "Work" partition.

The new "init" script handles this scenario correctly.
"sfs_load" will load the devx, with a warning, but it's not loaded on reboot, it can't find the devx when called from "rc.sysinit".

Now that there is no "Boot Manager" or "init" code handling, touching or even looking at, extra=sfs's; it's time to think outside the box about how sfs_load stores it's data. Why not in "/root/.packages/loaded_sfs/" as symbolic links to the sfs files?

gyro

Posted: Tue 28 Feb 2017, 18:49
by mavrothal
gyro wrote:Now that there is no "Boot Manager" or "init" code handling, touching or even looking at, extra=sfs's; it's time to think outside the box about how sfs_load stores it's data. Why not in "/root/.packages/loaded_sfs/" as symbolic links to the sfs files?
Symlinks will be broken if the partition they target resides on is not mounted. The only certainly mounted partition is /mnt/home (if $PUPMODE != 5).
Saving "partition,filesystem,/path/to/sfs " in BOOTCONFIG for each SFS may not be out of the box but has a known implementation and should work if the aim is to be able to have the target SFS anywhere in the running system.
As usually however there are many possible "solutions" to the "problem" and at the end of the day is up to the person that will do the coding.