Slacko32/64 700 BETA 2
@shinobar,
I admit that I have not checked the code for the implications of your suggested change.
But, one of the changes with the new "init" script, is that it knows nothing about extra-sfs's. It only deals with the puppy system sfs's.
All extra-sfs processing is left to "sfs_load".
Mostly this was done because, with the existence a mature "sfs_load" there is no need for "init" to include code to handle some of them.
But it also sets "sfs_load" free to store it's data somewhere other than "BOOTCONFIG". Leaving that to be only a communication between "init" and "rc.sysinit".
"sfs_load" is run by "rc.sysinit" to load all extra-sfs's, during that processing it probably needs to do "after" processing only if there was a failed "unload" during the last session, or a failed "load" during the current processing.
It would be good to complete the separation of "init" and "sfs_load"
over the procesing of sfs's.
gyro
I admit that I have not checked the code for the implications of your suggested change.
But, one of the changes with the new "init" script, is that it knows nothing about extra-sfs's. It only deals with the puppy system sfs's.
All extra-sfs processing is left to "sfs_load".
Mostly this was done because, with the existence a mature "sfs_load" there is no need for "init" to include code to handle some of them.
But it also sets "sfs_load" free to store it's data somewhere other than "BOOTCONFIG". Leaving that to be only a communication between "init" and "rc.sysinit".
"sfs_load" is run by "rc.sysinit" to load all extra-sfs's, during that processing it probably needs to do "after" processing only if there was a failed "unload" during the last session, or a failed "load" during the current processing.
It would be good to complete the separation of "init" and "sfs_load"
over the procesing of sfs's.
gyro
LASTUNIONRECORD
Thanks mavrothal and gyro for your discussion.
My lang_pack_ja-2.0.sfs uses the LASTUNIONRECORD record. Japanese forum members found it fails as for the recent puppies. My proposal above is one solution for this problem.
I think I need to read threw the init and rc.sysinit script so that I can make my thought to resolve these problem totally.
My lang_pack_ja-2.0.sfs uses the LASTUNIONRECORD record. Japanese forum members found it fails as for the recent puppies. My proposal above is one solution for this problem.
I think I need to read threw the init and rc.sysinit script so that I can make my thought to resolve these problem totally.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
extra sfs in sub folder doesn't load at boot
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.
Fixed.
http://shinobar.server-on.net/puppy/opt ... -3.0.2.pet
Fixed.
http://shinobar.server-on.net/puppy/opt ... -3.0.2.pet
Code: Select all
--- sfs_load-300 2016-09-11 07:30:18.000000000 +0900
+++ sfs_load 2017-02-23 21:38:16.000000000 +0900
@@ -62,7 +62,7 @@
MYPATH=$0
MYNAME=$(basename "$0")
-VERSION=3.0
+VERSION=3.0.2
ORGOPT="$@"
#some options the puplet builder can choose
WIPEWHITEONINIT="true" # true/false
@@ -1355,10 +1355,12 @@
$SFSBASE|$ZDRBASE|$ADRBASE|$YDRBASE|$FDRBASE) :;;
*) echo $EXTRASFSLIST | grep -qw "$FILENAME" || EXTRASFSLIST="$EXTRASFSLIST $FILENAME";;
esac
+ LASTUNIONRECORD="$LASTUNIONRECORD $FILENAME"
save_bootconfig
}
save_bootconfig() {
EXTRASFSLIST=$(echo $EXTRASFSLIST) # trim blanks
+ LASTUNIONRECORD=$(echo $LASTUNIONRECORD) # trim blanks
echo "EXTRASFSLIST='$EXTRASFSLIST'" > $BOOTCONFIG
echo "PREVUNIONRECORD='$PREVUNIONRECORD'" >> $BOOTCONFIG
echo "LASTUNIONRECORD='$LASTUNIONRECORD'" >> $BOOTCONFIG
@@ -1510,6 +1512,7 @@
fi
LOOPDEV=$(echo "$LOOP"| cut -d':' -f1)
if [ "$LOOPDEV" = "" ]; then
+ remove_item LASTUNIONRECORD "$FILENAME" && REGISTERED="y" || log "'$FILENAME' seems not registered."
save_bootconfig
error --info "$(gettext "Could not find the loaded point.")$(gettext "Maybe already unloaded.")"
return 1 #finish
@@ -1566,6 +1569,7 @@
mv -f "$LOOPLIST.new" "$LOOPLIST"
fi
#true # unless fatal error
+ remove_item LASTUNIONRECORD "$FILENAME" && REGISTERED="y" || log "'$FILENAME' seems not registered."
save_bootconfig
# delete file
RMLOG=""
@@ -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"
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Re:extra sfs in sub folder doesn't load at boot
Thank you very much shinobar.
Now those who suffered from that problem will be saved.
Now those who suffered from that problem will be saved.
Hi all,
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.
Below are two pics, first with info, and second is of the same desktop just with a different theme/icons setup than I normally use (the themes come with the build). If anybody wants to download this and play with it, let me know and I'll see if Smokey will let me upload it along with the devx that was also built by the woof-CE scripts. The final build size of the ISO is 258mb. It includes the latest openssl, glibc, etc, etc are in it. For a 64-bit ISO, with the latest Firefox 45.7.0 and more included, this is not too bad.
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.
Below are two pics, first with info, and second is of the same desktop just with a different theme/icons setup than I normally use (the themes come with the build). If anybody wants to download this and play with it, let me know and I'll see if Smokey will let me upload it along with the devx that was also built by the woof-CE scripts. The final build size of the ISO is 258mb. It includes the latest openssl, glibc, etc, etc are in it. For a 64-bit ISO, with the latest Firefox 45.7.0 and more included, this is not too bad.
- Attachments
-
- Slacko64-6.9.6.4-kernel-4.2.5-info.png
- (190.16 KiB) Downloaded 894 times
-
- Slacko64-6.9.6.4-kernel-4.3.5.png
- (98.66 KiB) Downloaded 976 times
- battleshooter
- Posts: 1378
- Joined: Wed 14 May 2008, 05:10
- Location: Australia
I have some pets for Slacko64 6.9.6.4 here if they could be of use to you, or anyone really.belham2 wrote: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.
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.
[url=http://www.murga-linux.com/puppy/viewtopic.php?t=94580]LMMS 1.0.2[/url], [url=http://www.murga-linux.com/puppy/viewtopic.php?t=94593]Ardour 3.5.389[/url], [url=http://www.murga-linux.com/puppy/viewtopic.php?t=94629]Kdenlive 0.9.8[/url]
Re: extra sfs in sub folder doesn't load at boot
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.shinobar wrote: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"
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?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Re: extra sfs in sub folder doesn't load at boot
I tried on the Slacko-6.9.6.4 and also on the LxPupSc-17.02.1T frugal install in a subdir.mavrothal wrote: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.
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
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.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Re: extra sfs in sub folder doesn't load at boot
That IS strange As i said I do not see that (anybody else?)shinobar wrote:I tried on the Slacko-6.9.6.4 and also on the LxPupSc-17.02.1T frugal install in a subdir.mavrothal wrote: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.
The SFS in the same subdir loads fine, yes. But it does not load again on reboot.
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?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Re: extra sfs in sub folder doesn't load at boot
No problems here - all sfs load perfectly after a reboot......I have 5 in a subdir frugal installmavrothal wrote:That IS strange As i said I do not see that (anybody else?)
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Re: extra sfs in sub folder doesn't load at boot
Yes strange. But i got itmavrothal wrote:That IS strange As i said I do not see that (anybody else?)
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.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Re: extra sfs in sub folder doesn't load at boot
Ah yes - I do see that - you have to do it in the opposite order:shinobar wrote:(3) Load the extra SFS in the subdir.
(4) Save the session making a new pupsave.
Make pupsave then
Install sfs
Then all is ok after reboot.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Re: extra sfs in sub folder doesn't load at boot
Right, for atahdd(PUPMODE=12).peebee wrote:you have to do it in the opposite order:
Make pupsave then
Install sfs
Then all is ok after reboot.
But it doesn't solve the issue for usbflash/ataflash(PUPMODE=13).
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Re: extra sfs in sub folder doesn't load at boot
Indeed it fails in PUPMODE=13shinobar wrote:Right, for atahdd(PUPMODE=12).peebee wrote:you have to do it in the opposite order:
Make pupsave then
Install sfs
Then all is ok after reboot.
But it doesn't solve the issue for usbflash/ataflash(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...
LATER: The above patch also solves the problem of remembering SFSs loaded at pumode=5 reported by
shinobar wrote: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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Re: extra sfs in sub folder doesn't load at boot
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'.
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"
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
sfs_load-3.0.3
Uploaded sfs_load-3.0.3.pet, fixed subdir issue and LASTUNIONRECORD issue.
http://shinobar.server-on.net/puppy/opt ... -3.0.3.pet
http://shinobar.server-on.net/puppy/opt ... -3.0.3.pet
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Re: extra sfs in sub folder doesn't load at boot
No.shinobar wrote:Using '/mnt/home' is just for human interface. Internally, it can be treated as '/initrd/mnt/dev/save'.
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
Re: extra sfs in sub folder doesn't load at boot
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.
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.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
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
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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
dead link, perhaps another one will come soon
Last edited by Sailor Enceladus on Sat 08 Apr 2017, 00:11, edited 1 time in total.