Enhance boot params, pupsfs, zdrv, fdrv, adrv, ydrv, psave
peebee has requested that the fdrv behaves just like the other *drv files
right now it requires that fw_drv param, also fdrv= triggers something as far as I can tell
https://github.com/puppylinux-woof-CE/w ... issues/785
What do you think?... perhaps a new patch from you to fix this issue..
right now it requires that fw_drv param, also fdrv= triggers something as far as I can tell
https://github.com/puppylinux-woof-CE/w ... issues/785
What do you think?... perhaps a new patch from you to fix this issue..
Also... gyro... this needs to be documented in the puppy iso... help2.msg?...
Perhaps something like this:
psubdir=puppies/slacko Path in which Puppy is installed.
.
.
pupsfs=<partition>:/puppies/slacko/puppy.sfs Override auto search.
zdrv=<partition>:/puppies/slacko/zpuppy.sfs Override auto search.
fdrv=<partition>:/puppies/slacko/fpuppy.sfs Override auto search.
adrv=<partition>:/puppies/slacko/apuppy.sfs Override auto search.
ydrv=<partition>:/puppies/slacko/ypuppy.sfs Override auto search.
psave=<partition>:savefile.4fs Override auto search.
.
.
.
* <partition> can be a name (sda1), label (Work) or UUID (1ab736oqjGkdf)
* if file does not start with a "/", then PSUBDIR is prepended to it
Perhaps something like this:
psubdir=puppies/slacko Path in which Puppy is installed.
.
.
pupsfs=<partition>:/puppies/slacko/puppy.sfs Override auto search.
zdrv=<partition>:/puppies/slacko/zpuppy.sfs Override auto search.
fdrv=<partition>:/puppies/slacko/fpuppy.sfs Override auto search.
adrv=<partition>:/puppies/slacko/apuppy.sfs Override auto search.
ydrv=<partition>:/puppies/slacko/ypuppy.sfs Override auto search.
psave=<partition>:savefile.4fs Override auto search.
.
.
.
* <partition> can be a name (sda1), label (Work) or UUID (1ab736oqjGkdf)
* if file does not start with a "/", then PSUBDIR is prepended to it
I agree with peebee.jlst wrote:peebee has requested that the fdrv behaves just like the other *drv files
right now it requires that fw_drv param, also fdrv= triggers something as far as I can tell
https://github.com/puppylinux-woof-CE/w ... issues/785
What do you think?... perhaps a new patch from you to fix this issue..
I don't understand why the fdrv support was implemented that way.
But a fix is quite straight forward.
Remove all the "[ "$EXTRAFW" = "yes" ]" conditions around the fdrv code, and remove the "fw_drv" pfix parameter.
Yes, I could do it, but I think I should look at the doco issue first.
gyro
Well, here's a patch to get rid of EXTRAFW. (untested)
gyro
gyro
- Attachments
-
- noEXTRAFW.diff.gz
- gunzip to produce ".diff" file.
- (1.36 KiB) Downloaded 195 times
Here's a first attempt at a "help2.msg".
I understand that there's a limit of 25 lines for this file.
gyro
I understand that there's a limit of 25 lines for this file.
gyro
- Attachments
-
- help2.msg.gz
- gunzip to produce "help2.msg"
- (729 Bytes) Downloaded 272 times
Re: Enhance boot params, pupsfs, zdrv, fdrv, adrv, ydrv, psave
This is an interesting project that loooks as if it will enhance configurability of pups and allow end users to get more creative with pup structure. I struggle to understand the relationships between pupsfs, zdrv, adrv, and ydrv and now fdrv - and I find the naming a little confusing - but I hope to get a better understanding of them.gyro wrote:A project to enhance the facilites provided by the sfs boot parameters, pupsfs, zdrv, adrv, and ydrv. And to add a savefile/savefolder parameter psave.
It provides the facilities that might be expected from them, i.e. any of these sfs's can be specified to reside anywhere with any name.
I have some questions:
1) Can anyone point to a (recent) tutorial, post, or thread which provides a good understanding of how these individual "xdrv" sfs'es are stacked?
2) Do any of these sit above the main pup.sfs and override / overwrite it? (if so which?)
3) If significant changes are being made to the initrd.gz could there be consideration given to altering the naming convention (or adding something extra) so that layering was obvious from the name?
eg: layering labelled as follows:
Top_1.sfs
Top_2.sfs
Pup.sfs
Bottom_1.sfs
Bottom_2.sfs
or maybe:
+personal.sfs
+zdrv
+adrv
+fdrv
pup.sfs
-hdrv
-pdrv
-cdrv
-data.sfs
(with + or - prefix or something similar indicating its position in the layering)
or for greater clarity:
+1drv
+2drv
+3fdrv
+mainpup_update.sfs
mainpup.sfs
-1adrv
-2data.sfs
(where "mainpup_update.sfs" could be potentially provided by a developer to correct issues found with original main.sfs or to add enhancements selectively as a form of quick update rather than main remaster)
My questions reveal my level of ignorance around xdrv's but just thought I'd ask anyway - (I'm a believer in the motto that the only dumb question is one you don't ask...)
.
@greengeek,
The sfs's end up in the stack in this order from the top down:
1) adrv - notionaly an "application" layer
2) ydrv - notionaly a "fix" layer
3) pupsfs - the main puppy sfs from the iso
4) fdrv - notionaly a "firmware" layer
5) zdrv - notionaly a "driver" layer
6) Any "extra" sfs's loaded with sfs_load.
So both adrv and ydrv cover the main pupsfs and so can be used to update it.
The fdrv is under the main pupsfs but covers zdrv and so can be used to update it.
Any "extra" sfs's cannot update any system sfs's.
Note1: In woof-ce puppies the fdrv and zdrv contain files that do not exist in the main pupsfs, (so it doesn't matter that they are below it).
Note2: The save layer is always above any sfs's, so a ".pet" can update any sfs.
gyro
The sfs's end up in the stack in this order from the top down:
1) adrv - notionaly an "application" layer
2) ydrv - notionaly a "fix" layer
3) pupsfs - the main puppy sfs from the iso
4) fdrv - notionaly a "firmware" layer
5) zdrv - notionaly a "driver" layer
6) Any "extra" sfs's loaded with sfs_load.
So both adrv and ydrv cover the main pupsfs and so can be used to update it.
The fdrv is under the main pupsfs but covers zdrv and so can be used to update it.
Any "extra" sfs's cannot update any system sfs's.
Note1: In woof-ce puppies the fdrv and zdrv contain files that do not exist in the main pupsfs, (so it doesn't matter that they are below it).
Note2: The save layer is always above any sfs's, so a ".pet" can update any sfs.
gyro
Updated boot help msg files
Here is my second attempt at a "help2.msg".
And my first atempt at a "help.msg".
gyro
And my first atempt at a "help.msg".
gyro
- Attachments
-
- help2-2.msg.gz
- gunzip to produce "help2-2.msg", rename to "help2.msg"
- (722 Bytes) Downloaded 263 times
-
- help.msg.gz
- gunzip to produce "help.msg" file.
- (822 Bytes) Downloaded 266 times
I didnt quite grasp the link between pets and the "save layer". My puppy has no savefile (as a safety feature it never saves session specific information) but I do use pets to "graft" extra functionality into my pup when I need to do specific tasks (CAD drawing etc) - then these pets get discarded at shutdown.gyro wrote:Note2: The save layer is always above any sfs's, so a ".pet" can update any sfs.
(It is more or less as if my puppy was loaded from original CD and is running in "live session")
Would it be correct to say that I still have a "save layer" (where the pets go to) even though I have no savefile loaded to that save layer?
And are you saying that all extra sfs files get loaded in the lowest of the layers, and all pets are highest in the layers (even though I don't have a savefile loaded?)
If so that possibly explains why I have better outcomes using pets than I do using sfs files.
Thanks for the clarification!
Yes, it's a tmpfs mounted at "/initrd/pup_rw"greengeek wrote:Would it be correct to say that I still have a "save layer" (where the pets go to) even though I have no savefile loaded to that save layer?
Yes.greengeek wrote:And are you saying that all extra sfs files get loaded in the lowest of the layers, and all pets are highest in the layers (even though I don't have a savefile loaded?)
If the files in the sfs are unique, then an sfs has the same effect as a pet.greengeek wrote:If so that possibly explains why I have better outcomes using pets than I do using sfs files.
But if any of the files in the sfs correspond to files in any higher layer, then these files in the sfs will not be seen by puppy.
gyro
Here is my third attempt at a "help2.msg".
And my second attempt at a "help.msg".
I'm prepared to go with these.
gyro
And my second attempt at a "help.msg".
I'm prepared to go with these.
gyro
- Attachments
-
- help-2.msg.gz
- gunzip to produce "help-2.msg", rename to "help.msg"
- (825 Bytes) Downloaded 285 times
-
- help2-3.msg.gz
- gunzip to produce "help2-3.msg", rename to "help2.msg"
- (784 Bytes) Downloaded 255 times
Here is my last attempt at a "help2.msg".
It's a bit more "agressive" in deleting stuff.
It takes a completely different approach.
So, should it be version 3 or 4?
gyro
It's a bit more "agressive" in deleting stuff.
It takes a completely different approach.
So, should it be version 3 or 4?
gyro
- Attachments
-
- help2-4.msg.gz
- gunzip to produce "help2-4.msg", then rename to "help2.msg"
- (790 Bytes) Downloaded 257 times