i got it, thanks everybody.LazY Puppy wrote:Doesn't you puppy have a Rox right-click option to make PET package ?
sfs_load-2.4 on-the-fly
sfs_load-3.0.1
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
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
Last edited by shinobar on Sun 26 Feb 2017, 11:19, edited 2 times in total.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
As suggested by mavrothal, I'm continuing the discussion here.
Theh following is by boot entry:"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
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
"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
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).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?
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.
== [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] ==
- OscarTalks
- Posts: 2196
- Joined: Mon 06 Feb 2012, 00:58
- Location: London, England
Because "Boot Manager" has never done any loading of .sfs files. It aways was just a GUI for the extra-sfs facilitiy of the "init" script.OscarTalks wrote:I am curious as to why the boot manager option for .sfs loading has been removed?
Now there is no extra-sfs facility in "init", so no GUI in "Boot Manager".
Why? Having 2 is just a waste of time and effort.
gyro
Last edited by gyro on Thu 02 Mar 2017, 04:24, edited 1 time in total.
@mavrothal,
BOOTCONFIG, is the communication mechanism between the "init" script and the extra-sfs GUI in "Boot Manager".
While there was an extra-sfs facility in "init", and a corresponding GUI in "Boot Manager", "sfs_load" had no choice but to piggy-back on this mechanism.
Now, it is just an anachronism.
Edit:
My apologies, BOOTCONFIG is still a communication mechanism between "init" and "rc.sysinit" for the puppy system sfs's.
But, it's an "init" file, and having "extra-sfs" stuff in it is no longer needed. It's puppose is simpler and more obvious, if it contains only puppy system sfs information.
gyro
BOOTCONFIG, is the communication mechanism between the "init" script and the extra-sfs GUI in "Boot Manager".
While there was an extra-sfs facility in "init", and a corresponding GUI in "Boot Manager", "sfs_load" had no choice but to piggy-back on this mechanism.
Now, it is just an anachronism.
Edit:
My apologies, BOOTCONFIG is still a communication mechanism between "init" and "rc.sysinit" for the puppy system sfs's.
But, it's an "init" file, and having "extra-sfs" stuff in it is no longer needed. It's puppose is simpler and more obvious, if it contains only puppy system sfs information.
gyro
To bring the conversation back to my original issue, here is the "PUPSTATE" file of my setup:For optimum use of my SSD versus my HD, my "devx_tahr_6.0.6.sfs" is in the same directory as my "puppy_tahr_6.0.6.sfs".
The current sfs_load can't properly cope with this.
(Oh, the old "Boot Manager" extra-sfs code would have coped even less than sfs_load does.)
gyro
Code: Select all
PUPMODE=12
PDEV1='sda4'
DEV1FS='ext4'
PUPSFS='sda4,ext4,/puppy/tahr/puppy_tahr_6.0.6.sfs'
PUPSAVE='sdb2,ext4,/pupsaves/tahrsave'
PMEDIA='atahd'
#ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
ATADRIVES='sda sdb '
#ATAOPTICALDRIVES is list of non-usb optical drives...
ATAOPTICALDRIVES='sr0 '
#these directories are unionfs/aufs layers in /initrd...
SAVE_LAYER='/pup_rw'
PUP_LAYER='/pup_ro2'
#The partition that has the tahrsave file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV='sda4,ext4,/puppy/tahr/zdrv_tahr_6.0.6.sfs'
FDRV=''
ADRV=''
YDRV='sda4,ext4,/puppy/tahr/ydrv_tahr_6.0.6.sfs'
#Partition no. override on boot drive to which session is (or will be) saved...
PSAVEMARK=''
PSAVEPART='sdb2'
PSAVEDIR='/pupsaves/'
PSUBDIR='/puppy/tahr'
The current sfs_load can't properly cope with this.
(Oh, the old "Boot Manager" extra-sfs code would have coped even less than sfs_load does.)
gyro
A couple of lessons about loading sfs's, from the woof-ce 'rationalise' project, that should not be overlooked:
1. Always use read-only loop devices.
My observations from always running "pfix=fsckp" show:
e2fsck does not indicate issues with the previous umount when read-only loop devices are used for sfs's.
e2fsck often reports issues with the previous umount when read-write loop devices are used for sfs's.
2. Add sfs's to aufs as "rr" layers.
According to the aufs documentation:
"ro" means that the actual directory could be "rw" and so aufs needs to be open to the possibility that it's contents might get changed by acesses outside aufs. e.g. pup_ro1 in pupmode=13.
"rr" means that the actual directory is also "ro" and so aufs can depend on it's contents remaining unchanged.
I have no emperical evidence to show that it makes a signicicant difference, but "rr" is supposed to be more efficient, and there seems to be no problem with specifying it.
gyro
1. Always use read-only loop devices.
My observations from always running "pfix=fsckp" show:
e2fsck does not indicate issues with the previous umount when read-only loop devices are used for sfs's.
e2fsck often reports issues with the previous umount when read-write loop devices are used for sfs's.
2. Add sfs's to aufs as "rr" layers.
According to the aufs documentation:
"ro" means that the actual directory could be "rw" and so aufs needs to be open to the possibility that it's contents might get changed by acesses outside aufs. e.g. pup_ro1 in pupmode=13.
"rr" means that the actual directory is also "ro" and so aufs can depend on it's contents remaining unchanged.
I have no emperical evidence to show that it makes a signicicant difference, but "rr" is supposed to be more efficient, and there seems to be no problem with specifying it.
gyro
Not that is important but if BOOTCONFIG is to have only puppy system sfs information we can just delete it. This info is in DISTRO_SPECS.gyro wrote:But, it's an "init" file, and having "extra-sfs" stuff in it is no longer needed. It's puppose is simpler and more obvious, if it contains only puppy system sfs information.
Again, many ways to do the same thing. The important part in the "everywhere" scenario is to include partition, fs and full path info.
Regarding where, my tendency is to keep as many files as possible so I do not need to worry for whatever other script may be digging info out of the target file, but is up to the person that may add this functionality to sfs_load to decide.
== [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] ==
subject could be one of my Puppy Linux exam, At school.
subject could be one of my Puppy Linux exam, At school.
Just information given first topic is important to remember.
Just information given first topic is important to remember.