Author |
Message |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Fri 03 Jun 2016, 12:14 Post subject:
|
|
Here's a first attempt at a "help2.msg".
I understand that there's a limit of 25 lines for this file.
gyro
Description |
gunzip to produce "help2.msg"
|

Download |
Filename |
help2.msg.gz |
Filesize |
729 Bytes |
Downloaded |
323 Time(s) |
|
Back to top
|
|
 |
greengeek

Joined: 20 Jul 2010 Posts: 5834 Location: Republic of Novo Zelande
|
Posted: Fri 03 Jun 2016, 14:22 Post subject:
Re: Enhance boot params, pupsfs, zdrv, fdrv, adrv, ydrv, psave Subject description: Support UUID and partition Label - done |
|
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...)
.
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Sat 04 Jun 2016, 01:43 Post subject:
|
|
@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
|
Back to top
|
|
 |
greengeek

Joined: 20 Jul 2010 Posts: 5834 Location: Republic of Novo Zelande
|
Posted: Sat 04 Jun 2016, 02:57 Post subject:
|
|
Thanks gyro, that is very helpful. cheers
|
Back to top
|
|
 |
Robin2
Joined: 17 Jan 2015 Posts: 180
|
Posted: Sun 05 Jun 2016, 04:51 Post subject:
|
|
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
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Sun 05 Jun 2016, 12:17 Post subject:
|
|
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
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Sun 05 Jun 2016, 13:48 Post subject:
Updated boot help msg files |
|
Here is my second attempt at a "help2.msg".
And my first atempt at a "help.msg".
gyro
Description |
gunzip to produce "help2-2.msg", rename to "help2.msg"
|

Download |
Filename |
help2-2.msg.gz |
Filesize |
722 Bytes |
Downloaded |
304 Time(s) |
Description |
gunzip to produce "help.msg" file.
|

Download |
Filename |
help.msg.gz |
Filesize |
822 Bytes |
Downloaded |
310 Time(s) |
|
Back to top
|
|
 |
greengeek

Joined: 20 Jul 2010 Posts: 5834 Location: Republic of Novo Zelande
|
Posted: Sun 05 Jun 2016, 16:11 Post subject:
|
|
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!
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Mon 06 Jun 2016, 07:34 Post subject:
|
|
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
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Mon 06 Jun 2016, 09:20 Post subject:
|
|
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
Description |
gunzip to produce "help-2.msg", rename to "help.msg"
|

Download |
Filename |
help-2.msg.gz |
Filesize |
825 Bytes |
Downloaded |
328 Time(s) |
Description |
gunzip to produce "help2-3.msg", rename to "help2.msg"
|

Download |
Filename |
help2-3.msg.gz |
Filesize |
784 Bytes |
Downloaded |
298 Time(s) |
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Mon 06 Jun 2016, 11:15 Post subject:
|
|
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
Description |
gunzip to produce "help2-4.msg", then rename to "help2.msg"
|

Download |
Filename |
help2-4.msg.gz |
Filesize |
790 Bytes |
Downloaded |
309 Time(s) |
|
Back to top
|
|
 |
jlst
Joined: 23 Nov 2012 Posts: 571
|
Posted: Mon 06 Jun 2016, 14:23 Post subject:
|
|
I think help-2.msg and help2-4.msg are ok
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Mon 06 Jun 2016, 14:59 Post subject:
|
|
jlst wrote: | I think help-2.msg and help2-4.msg are ok | Thanks.
Then another pull-request on the way.
gyro
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Wed 08 Jun 2016, 14:47 Post subject:
|
|
A new version is available for download from the first post.
It corresponds to the code uploaded to woof-ce.
gyro
|
Back to top
|
|
 |
gyro
Joined: 28 Oct 2008 Posts: 1799 Location: Brisbane, Australia
|
Posted: Thu 09 Jun 2016, 09:51 Post subject:
|
|
Added patches for "shutdownconfig" and "rc.shutdown" to support the "psave" boot parameter, to the first post.
gyro
|
Back to top
|
|
 |
|