Slacko32/64 700 BETA 2

[battleshooter]

While I am struggling away trying to build a 64-bit puduan debian pup, I gave up for awhile on it and came back to try Micko's dependable Slacko builds. Sure enough, a fresh, up-to-date Slacko64 with the latest kernel built first time thru, everything went great, and she booted straight to desktop. I cannot find (yet) a thing wrong with it, as I've been through nearly everything in the menu so far testing stuff.

I have some pets for Slacko64 6.9.6.4 here if they could be of use to you, or anyone really.

There's GTK3 somewhere in that mix too so the latest Firefox can be used but I noticed the Firefox binary now requires PulseAudio for sound which I haven't compiled yet.

Gimp as well for whoever was asking but it's for the 64-bit version as are all the pets.

[mavrothal]

By the way, sfs_load v3 in the Slacko-6.9.6.4 fails to load extra sfs's in the sub folder(psubdir) at boot.

<snip>

Code: Select all

<snip>
@@ -1791,7 +1795,6 @@
   fi
 fi
 [ "$SAVEFILE" != "" ] && PSUBDIR=$(dirname "$SAVEFILE"| cut -b2-)  # remove '/' at head
-[ "$DESTDIR" -a "$PSUBDIR" -a ! -d "$DESTDIR/$PSUBDIR" ] && PSUBDIR=""  # may not yet be created
 # 13 Nov 2011: except PUPMODE=7 #2.0.12: PUPMODE=7 optional
 case "$PUPMODE" in
 5) if [ "$SAVEFILE" != "" ]; then SFSMODE="y"

I'm not sure I understand correctly the problem but using the latest puppy builds in a frugal install (in a subdir) SFS_load 3.0 detects the SFSs in the subdir, loads them fine and they load again correctly on reboot.
Is that what you are describing?
Is the change quoted above the one that fixes the problem in your case?
If it does, it is strange that actually the condition is in effect. What is the pupmode/setup that you see this problem at?

[shinobar]

using the latest puppy builds in a frugal install (in a subdir) SFS_load 3.0 detects the SFSs in the subdir, loads them fine and they load again correctly on reboot.

I tried on the Slacko-6.9.6.4 and also on the LxPupSc-17.02.1T frugal install in a subdir.
The SFS in the same subdir loads fine, yes. But it does not load again on reboot.

Code: Select all

-[ "$DESTDIR" -a "$PSUBDIR" -a ! -d "$DESTDIR/$PSUBDIR" ] && PSUBDIR=""  # may not yet be created

This line intended for precaution, but it is useless because the file will be checked next step.
The sfs_load uses /mnt/home here, but sfs-load is called from rc.sysinit in the recent woof, before making the link /mnt/home which points /initrd/mnt/dev_save.

[mavrothal]

using the latest puppy builds in a frugal install (in a subdir) SFS_load 3.0 detects the SFSs in the subdir, loads them fine and they load again correctly on reboot.

I tried on the Slacko-6.9.6.4 and also on the LxPupSc-17.02.1T frugal install in a subdir.
The SFS in the same subdir loads fine, yes. But it does not load again on reboot.

That IS strange As i said I do not see that (anybody else?)
It may be the setup. I use an ext4 formated internal disk. What is yours? USB/HD/CD? Filysystem?
Is it with a specific SFSs or any?

[peebee]

That IS strange As i said I do not see that (anybody else?)

No problems here - all sfs load perfectly after a reboot......I have 5 in a subdir frugal install

[shinobar]

That IS strange As i said I do not see that (anybody else?)

Yes strange. But i got it
You can reproduce the issue:
(1) Furugal install in a subdir and some extra SFS in the same subdir.
(2) Boot without pupsave.
(3) Load the extra SFS in the subdir.
(4) Save the session making a new pupsave.
(5) reboot with the pupsave. The extra SFS in the subdir does not load.

The problem is, sfs_load assumes /mnt/home is a link to /initrd/mnt/dev_save at PUPMODDE=12 or 13, but it is not sure.
The first pupsave is saved without the link /mnt/home.
The link /mnt/home is made by the rc.sysinit AFTER calling sfs_load.

So, dropping the SFS in the subdir occurs only once, if the SFS is loaded under RAM mode(PUPMODE=5) and reboot with PUPMODE=12.

Under PUPMODE=13 is another case. The link /mnt/home is not saved in the pupsave under this mode. (Look in the pupsave.) So, the SFS in the subdir always drops at next boot in this case.

[peebee]

(3) Load the extra SFS in the subdir.
(4) Save the session making a new pupsave.

Ah yes - I do see that - you have to do it in the opposite order:

Make pupsave then
Install sfs

Then all is ok after reboot.

[shinobar]

you have to do it in the opposite order:

Make pupsave then
Install sfs

Then all is ok after reboot.

Right, for atahdd(PUPMODE=12).
But it doesn't solve the issue for usbflash/ataflash(PUPMODE=13).

[mavrothal]

you have to do it in the opposite order:

Make pupsave then
Install sfs

Then all is ok after reboot.

Right, for atahdd(PUPMODE=12).
But it doesn't solve the issue for usbflash/ataflash(PUPMODE=13).

Indeed it fails in PUPMODE=13

This because sfs_load is called from the rc.sysinit before the /mnt/home link is set. Thus the "-d "$DESTDIR/$PSUBDIR" condition fails in pupmode 13 and PSUBDIR is set to blank.
Moving the sfs_load call after the /mnt/home link set up (or vice versa) allows SFS loading from a subdir also in pupmode 13.

So it would appear that is not an sfs_load problem but rather a timing issue.

Not sure which is the best solution. Move sfs_load call latter or the /mnt/home linking earlier? (both work fine in my brief testing)
Of course there is also the init loading possibility (through LASTUNIONRECORD) but as gyro indicated the current thinking is to move as many things away from the init as possible.

Latter: Here is a patch for rc.sysinit to test
I'm particularly interested in booting from USB2/3 sticks in pupmode 13 to see if moving the call before the (extra) module loading call will give any issues with strange devices.

Code: Select all

--- a/etc/rc.d/rc.sysinit
+++ b/etc/rc.d/rc.sysinit
@@ -258,6 +258,29 @@
  mount -t tmpfs -o remount,size=${ALLOCK}k tmpfs /initrd/mnt/tmpfs
 fi
 
+# set up /mnt/home link befor sfs_load
+rm -f /mnt/home 2>/dev/null
+if [ ! -d /initrd ];then
+ PUP_HOME='/'
+ echo "PUP_HOME='/'" >> /etc/rc.d/PUPSTATE
+ ln -sv / /mnt/home
+else
+ if [ "$PUP_HOME" ];then #see /etc/rc.d/PUPSTATE
+  if [ "$PUP_HOME" = "/pup_ro1" -o "$PUP_HOME" = "/pup_rw" ];then
+   [ ! -d "$PUP_HOME" ] && echo "ERROR: $PUP_HOME does not exist"
+   #note, PUPMODE=6 will have PUP_HOME=/pup_rw.
+   #in the case of the persistent storage being the partition itself, this will be mounted
+   #on /initrd/pup_ro1 (tmpfs on pup_rw for restricted writes) or directly on /initrd/pup_rw
+   #and we do not really want users to access it as it is an aufs layer. Instead, they are
+   #already accessing it as "/".
+   ln -sv / /mnt/home
+  else
+   [ ! -d "/initrd${PUP_HOME}" ] && echo "ERROR: $PUP_HOME does not exist"
+   ln -sv /initrd${PUP_HOME} /mnt/home
+  fi
+ fi
+fi
+
 #------ load extra sfs's if any ------
 [ -d /initrd ] && sfs_load --cli start
 #-------------------------------------
@@ -466,28 +489,6 @@
 
 hostname -F /etc/hostname
 
-rm -f /mnt/home 2>/dev/null
-if [ ! -d /initrd ];then
- PUP_HOME='/'
- echo "PUP_HOME='/'" >> /etc/rc.d/PUPSTATE
- ln -sv / /mnt/home
-else
- if [ "$PUP_HOME" ];then #see /etc/rc.d/PUPSTATE
-  if [ "$PUP_HOME" = "/pup_ro1" -o "$PUP_HOME" = "/pup_rw" ];then
-   [ ! -d "$PUP_HOME" ] && echo "ERROR: $PUP_HOME does not exist"
-   #note, PUPMODE=6 will have PUP_HOME=/pup_rw.
-   #in the case of the persistent storage being the partition itself, this will be mounted
-   #on /initrd/pup_ro1 (tmpfs on pup_rw for restricted writes) or directly on /initrd/pup_rw
-   #and we do not really want users to access it as it is an aufs layer. Instead, they are
-   #already accessing it as "/".
-   ln -sv / /mnt/home
-  else
-   [ ! -d "/initrd${PUP_HOME}" ] && echo "ERROR: $PUP_HOME does not exist"
-   ln -sv /initrd${PUP_HOME} /mnt/home
-  fi
- fi
-fi
-
 ################WAIT MODULES LOADED##################
 echo "WAIT MODULES LOADED"
 #previous module loading may not have completed...

If the patch fails for you, remember that the forum tends to add spaces at the end of the lines...

LATER: The above patch also solves the problem of remembering SFSs loaded at pumode=5 reported by

You can reproduce the issue:
(1) Furugal install in a subdir and some extra SFS in the same subdir.
(2) Boot without pupsave.
(3) Load the extra SFS in the subdir.
(4) Save the session making a new pupsave.
(5) reboot with the pupsave. The extra SFS in the subdir does not load.

[shinobar]

Thanks mavrothal. It solves the problem.

Besides, I think sfs_load is better to reform on the /mnt/home handling.
Using '/mnt/home' is just for human interface. Internally, it can be treated as '/initrd/mnt/dev/save'.

Code: Select all

--- sfs_load-300	2016-09-11 07:30:18.000000000 +0900
+++ sfs_load	2017-02-26 12:14:39.000000000 +0900
@@ -1370,7 +1370,7 @@
   # already at the destination?
   SUB=""
   [ "$PSUBDIR" != "" ]  && SUB="$DESTDIR/$PSUBDIR" || SUB=""
-  for D in $DESTDIR $SUB; do
+  for D in $SUB $DESTDIR; do
     [ -s "$D/$F" ] && FOUND="$D/$F" && break
   done
   echo "$FOUND"
@@ -1767,7 +1767,7 @@
   *) SAVEFILE="";;
   esac
   [ "$PUP_HOME" != "" ] && PUPHOME=$INITRDHOME #20151004
-  [ "$PUPHOME" = "$INITRDHOME" ] && PUPHOME=$MNTHOME && DESTDIR=$PUPHOME
+  [ "$PUPHOME" = "$INITRDHOME" ] && DESTDIR=$PUPHOME
 else
   # PUPMODE=2 or 5
   if [ "$PUPMODE" = "2" ]; then
@@ -1791,7 +1791,6 @@
   fi
 fi
 [ "$SAVEFILE" != "" ] && PSUBDIR=$(dirname "$SAVEFILE"| cut -b2-)  # remove '/' at head
-[ "$DESTDIR" -a "$PSUBDIR" -a ! -d "$DESTDIR/$PSUBDIR" ] && PSUBDIR=""  # may not yet be created
 # 13 Nov 2011: except PUPMODE=7 #2.0.12: PUPMODE=7 optional
 case "$PUPMODE" in
 5) if [ "$SAVEFILE" != "" ]; then SFSMODE="y"

[shinobar]

Uploaded sfs_load-3.0.3.pet, fixed subdir issue and LASTUNIONRECORD issue.
http://shinobar.server-on.net/puppy/opt ... -3.0.3.pet

[gyro]

Using '/mnt/home' is just for human interface. Internally, it can be treated as '/initrd/mnt/dev/save'.

No.
Actually it should be using the mount point of the partition in PUPSFS from PUPSTATE.
Usually the puppy...sfs and the savefolder are in the same directory, so it's all the same.
But if they are different then the extra-sfs's should be with the puppy...sfs, not the savefolder.
Consider the situation of the frugal install being on an SSD, but the savefolder is on a HD (using a "psave=" boot parameter), then I want the extra-sfs's to be on the fast read device with the puppy...sfs i.e. the SSD, not the slower HD.
In this situation, the current sfs_load will not load the devx...sfs at the next boot, if it is on the SSD with the puppy...sfs, because /initrd/mnt/dev_save is a partition on the HD.

gyro

[shinobar]

gyro, thanks for your discussion, but I do not understand it.

You are talking which place the extra sfs'es to be searched.
I am just talking that '/mnt/home' is always a symlink points 'initrd/mnt/dev_save' under PUPMODE=12 or 13.

[mavrothal]

When it comes to paths and locations I do not think that there is a "best solution" (I quite often boot from a CD or USB but may keep savefiles in the HD).
If we want sfs_load to be able to auto load SFSs at boot time from all over the place, all we need is to save the full PATH and device/partition in EXTRASFSLIST for each sfs, (as we do for PUPSFS and PUPSAVE - we'll also need to mount these devices if not mounted) and modify the sfs_load code to consider those. Keep the current defaults (root of partition and pupsfs folder) if no device/partition/folder specified.
Not sure how many people are actually using the "all over the place" setup but if we can, why not
Regarding the use of /initrd/mnt/dev_save instead of /mnt/home, I'm not sure if this is indeed the PATH for ALL layered puppy modes (in the past pupmode 6 and 7 pointed to "/", not sure nowdays), but if it is would make a lot of sense.
Though I have the feeling that this discussion should be done in the sfs_load thread or in woof-CE issue or better yet, pull request

[Sailor Enceladus]

dead link, perhaps another one will come soon

[watchdog]

I'm using it. All basics are working. Ready for release?

[shinobar]

puppyapps(Default Applications Chooser) fails hen you select category ALL button.
Tow lines to be fixed:

Code: Select all

# diff -u puppyapps.old puppyapps
--- puppyapps.old	2016-09-18 16:40:26.000000000 +0900
+++ puppyapps	2017-02-25 16:35:37.000000000 +0900
@@ -232,7 +232,7 @@
 update_defaults () {
 	LANG=C
 	# change the default*** files, using the 'change_default' util
-	for I in $DEFAULTAPPS ; do
+	for I in $appz ; do
 	  case ${I#default} in
 		archiver)      change_default 'archiver' "$ARCHIVER" ;;
 		audioeditor)   change_default 'audioeditor' "$AUDIOEDITOR" ;;
@@ -679,7 +679,7 @@
   
 supported TYPEs:
 ----------------'
-default_apps | tr ' ' '\n'
+echo ${default_apps} | tr ' ' '\n'
 
 			exit
 			;;

The first chunk is to fix this. The second is to avoid command line error(puppyapps --help).

[boolean]

How to hibernate??

i am recompiling the kernel to add hibernate function

my problem is in init script

in previous puppies ( the last one i used was slacko 5.3 32bit), i would add

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

Code: Select all

##############END MODULE LOADING TO ACCESS DRIVES####################

# piratesmack: Resume after hibernation
#
# Note: boot parameter 'resume' must be set
# e.g. resume=sda3, where sda3 is the swap partition you hibernated to
#
RESUME="$(tr ' ' '\n' < /proc/cmdline | grep '^resume=' | cut -d= -f2 | sed -e 's:^/dev/::')"
if [ -n "$RESUME" -a -e "/sys/power/resume" ]; then
  PTRN="$RESUME$"
  # get major and minor number of resume partition
  MAJMIN="$(grep "$PTRN" /proc/partitions | tr -s ' ' | cut -d' ' -f2,3 | tr ' ' :)"
  echo -n $MAJMIN > /sys/power/resume
fi
########################################

#######################FINDING PUPPY FILES########################### 

but this puppy( slacko 6,9) have an unusual init script

does any body know where exactly to add the above script?

[sszindian]

@mick01

How about some insite as to the future of slacko64-6.9.6.4-uefi.iso?

Any updates coming... Is a new version in progress... or is what we have the final version?

It certainly appears the 'testing' on this is at its end! For sure, so far what we have is the making of a beautiful distro, would like to see it go just a tad-bit further.

>>>---Indian------>

[norgo]

Slacko32 - 700 Beta

checked yesterday some applications in Slacko 700 Beta and noticed a localization bug.
Launching of a GUI application via terminal shows always an error message like this:

Code: Select all

#geany
(process:20759): Gtk-WARNING **: Locale not supported by C library.
		Using the fallback 'C' locale.

So I checked the locales and got following output:

Code: Select all

#locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
C
POSIX

The next step I did was to check the folder where the locales should be stored.
but /usr/lib/locale did not exist !!!

So I launched /usr/sbin/quicksetup to create new locales ( so I thought )
But creating failed with error message:
cannot write output files to 'de_DE.utf8': No such file or directory

It seems that the /usr/lib/locale folder has to exist mandatory because quicksetup doesn't check presence

So I created manually the missing locale folder and launched quicksetup once again.
Now quicksetup created under /usr/lib/locale a folder de_DE.utf8 and the belonging LC_*** files

After that the error messages during launching of an application are not present anymore.

@Sailor Enceladus
most probably you've already again the newest version running
Could you check this bug for confirmation please
Thanks in advance