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

[gyro]

@jlst,

I have attached a patch to the "init" in the previous post.
This version fails more gracefully if you misspell the filename when specifying an sfs file.

gyro

[gyro]

Please see the first post for downloads for this version.

It fixes a problem where specified sfs files were not found if they resided on a partition that did not contain a PSUBDIR directory.

Also properly implements the following preference when looking for sfs files:
1) Specified partition + specified filename
2) Specified partition + default filename
3) Default partition + default filename

The code changes are in the 2search-woof.diff patch, but I have updated the following patches to fix the line numbers.

gyro

[gyro]

@initrd_progs project folk, we have a problem.

My "1func-woof2.diff" fails to apply to your "init".
The problem is your patch to remove "umntfunc()".
Some of the lines changed by your patch fall within the significant slabs of code that my "1func-woof2.diff" attempts to delete, so the old version of the code fails to match.
And some of my inserted code requires appropriate changing.

A number of ways forward to avoid later conflicts:
1) I could create a commit and pull-request to "woof-CE/woof-code/huge_extras/init" "testing" with a "remove umntfunc" patch based on your "init".
2) You could merge your "remove umntfunc" patch with "woof-CE/woof-code/huge_extras/init" "testing".
3) My patches get merged into "initrd_progs" "init" rather that "woof-CE/woof-code/huge_extras/init".
In this case I would want to have my individual patches retained as separate commits. To facilate this I could provide them as individual patches against "init_progs" "init".

Any thoughts?

gyro

[gyro]

Here is a tar of the patches that apply to the initrd_progs "init" script.
Extract with tar to produce 5 ".diff" files in the same directory.
Patch "init" with the ".diff" files in order, they should apply cleanly.

gyro

[jlst]

I was just going to test your patched init, but now you're giving me options, I choose 3.

01micko said that the work in initrd_progs will land in the main repo in the next woof iteration, whatever that means.

So you're free to do whatever you like in intird_progs, of course I might add some commits too, open a pull request there and I will merge it asap and will take the time to test for an hour or two..

If you're using the build script, now you have about 360 apps to toy with including a busybox version of guess_fstype...

[jlst]

OK gyro, I applied the patches and tested a couple of times... looks ok. So I opened a pull request (I added 5 commits crediting as the author), here it is, confirm it's ok and then i'l

https://github.com/puppylinux-woof-CE/i ... ogs/pull/8

This very init file can be placed in the main repo with 1 commit, you may open a pull request or i'll push it directly crediting you as the author (whatever you think is right), but you might want to test it with a tharpup and slacko initrd.gz first ...

[gyro]

@jlst,

Looks good.
Inspecting the changes looks OK.
Downloaded file is identical to my "init.initrd_progs3".
Testing in Tahrpup 6.0.5 "initrd.gz", worked fine.
Booted from ata and usb, no problems.
Booted "pfix=nocopy", no problems.

I haven't been able to test on a machine with limited memory so some sfs get copied to ram and some don't. (Don't have one.)

My only query is, did I use the correct file for testing?
I clicked on your URL.
Clicked on "Commits" tab
Against "init: "psave" boot parmam can specify a partition and filename." clicked on "<>" button.
Clicked on "Clode or download" button
Clicked on "Download ZIP"
Extracted zip file
Used "0initrd/init"

I have no problem with you continuing with your pull-request.

Thanks for your help.

gyro

[jlst]

Uhmmm I'm not sure... I merged it before repeating your steps, this is the current init:

https://raw.githubusercontent.com/puppy ... nitrd/init

if there are no diffs with the init you used then it's ok.

This init doesn't have any particular change that requires some extra adjustments.. the big difference now is in the static progs:
- cp -> busybox cp
- find -> busybox find
- xargs -> busybox xargs (has changed from -l to -n 1)
and some other apps : busybox

[gyro]

Uhmmm I'm not sure... I merged it before repeating your steps, this is the current init:

https://raw.githubusercontent.com/puppy ... nitrd/init

if there are no diffs with the init you used then it's ok.

I downloaded the "init" of your URL, and "diff" shows no difference between it and the one I used.

gyro

[jlst]

Ok i did it... the huge_extras/init has been updated with 1 commit. Even in your github account page shows that you did the commit hehe

https://github.com/puppylinux-woof-CE/w ... 138ac16538

[gyro]

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

[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]

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]

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]

Well, here's a patch to get rid of EXTRAFW. (untested)
gyro

[gyro]

Here's a first attempt at a "help2.msg".
I understand that there's a limit of 25 lines for this file.
gyro

[greengeek]

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]

@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

[greengeek]

Thanks gyro, that is very helpful. cheers

[Robin2]

@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