Enhance boot params, pupsfs, zdrv, fdrv, adrv, ydrv, psave

Under development: PCMCIA, wireless, etc.
Message
Author
gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#41 Post by gyro »

Then unless some bug is found in the code, this is done.
gyro

jlst

#42 Post by jlst »

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..

jlst

#43 Post by jlst »

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

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#44 Post by gyro »

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 agree with peebee.

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

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#45 Post by gyro »

Well, here's a patch to get rid of EXTRAFW. (untested)
gyro
Attachments
noEXTRAFW.diff.gz
gunzip to produce &quot;.diff&quot; file.
(1.36 KiB) Downloaded 192 times

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#46 Post by gyro »

Here's a first attempt at a "help2.msg".
I understand that there's a limit of 25 lines for this file.
gyro
Attachments
help2.msg.gz
gunzip to produce &quot;help2.msg&quot;
(729 Bytes) Downloaded 269 times

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

Re: Enhance boot params, pupsfs, zdrv, fdrv, adrv, ydrv, psave

#47 Post by greengeek »

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.
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.

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...) :-)
.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#48 Post by gyro »

@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

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#49 Post by greengeek »

Thanks gyro, that is very helpful. cheers

Robin2
Posts: 180
Joined: Sat 17 Jan 2015, 18:17

#50 Post by Robin2 »

gyro wrote:@greengeek,
Note2: The save layer is always above any sfs's, so a ".pet" can update any sfs.
Does this mean that my xenialsave-ACER.2fs file operates at level 0 in your hierarchy.

And thanks for the very useful clarification of the layers.

...R

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#51 Post by gyro »

Robin2 wrote:Does this mean that my xenialsave-ACER.2fs file operates at level 0 in your hierarchy.
Yes, if that's the name of your savefile.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Updated boot help msg files

#52 Post by gyro »

Here is my second attempt at a "help2.msg".
And my first atempt at a "help.msg".
gyro
Attachments
help2-2.msg.gz
gunzip to produce &quot;help2-2.msg&quot;, rename to &quot;help2.msg&quot;
(722 Bytes) Downloaded 260 times
help.msg.gz
gunzip to produce &quot;help.msg&quot; file.
(822 Bytes) Downloaded 262 times

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#53 Post by greengeek »

gyro wrote:Note2: The save layer is always above any sfs's, so a ".pet" can update any sfs.
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.

(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!

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#54 Post by gyro »

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, it's a tmpfs mounted at "/initrd/pup_rw"
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?)
Yes.
greengeek wrote:If so that possibly explains why I have better outcomes using pets than I do using sfs files.
If the files in the sfs are unique, then an sfs has the same effect as a pet.
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

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#55 Post by 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
Attachments
help-2.msg.gz
gunzip to produce &quot;help-2.msg&quot;, rename to &quot;help.msg&quot;
(825 Bytes) Downloaded 282 times
help2-3.msg.gz
gunzip to produce &quot;help2-3.msg&quot;, rename to &quot;help2.msg&quot;
(784 Bytes) Downloaded 252 times

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#56 Post by gyro »

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
Attachments
help2-4.msg.gz
gunzip to produce &quot;help2-4.msg&quot;, then rename to &quot;help2.msg&quot;
(790 Bytes) Downloaded 254 times

jlst

#57 Post by jlst »

I think help-2.msg and help2-4.msg are ok

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#58 Post by gyro »

jlst wrote:I think help-2.msg and help2-4.msg are ok
Thanks.
Then another pull-request on the way.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#59 Post by gyro »

A new version is available for download from the first post.
It corresponds to the code uploaded to woof-ce.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#60 Post by gyro »

Added patches for "shutdownconfig" and "rc.shutdown" to support the "psave" boot parameter, to the first post.
gyro

Post Reply