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

[gyro]

Probably the easiest way to test this project is, in any Woof-ce based puppy, replace the "init" in "initrd.gz" with the "init.woof2" file atached to the first post, (renamed as "init" of course).
gyro

[gyro]

A patached "initrd.gz" for xenial 7.0.1 has been added to the first post as a download url.
gyro

[Robin2]

A patached "initrd.gz" for xenial 7.0.1 has been added to the first post as a download url.
gyro

That's very good of you. Thanks.

Actually I have discovered that XenialPup will boot direct from my ACER eMMC with the original initrd.gz and this

Code: Select all

append pupsfs=mmcblk0p1:/puppy_xenial_7.0.1.sfs

...R

[gyro]

@Robin2,

I have to confess that I also have my own agenda for making a patched "initrd.gz" for xenial 7.0.1 available for download.
Being a very recent woof-ce puppy, it's "init" script is virtually identical to that in current woof-ce, thus the patched xenial "init" is virtually identical to the patched woof-ce "init".
The one line that is differnet between the two, has no bearing on these patches.
So, testing the patched xenial 7.0.1 "init" is almost as good as directly testing a patched actual woof-ce "init".
(Unlike the Tahr 6.0.5 and Tahr64 6.0.5 versions which do not contain support for an fdrv.)

gyro

[jlst]

I did some tests, and your changes seem work as expected... I'll take some time perform more tests. I'm using a grub4dos menu and a usb frugall install... usb_label = ZBOOT

This boots ok and finds adrv

title Puppy Linux - PRECISE
kernel /PUPPYBOOT/precise/vmlinuz psubdir=PUPPYBOOT/precise pmedia=atahd pfix=fsck,nocopy pupsfs=ZBOOT: zdrv=ZBOOT: ydrv=ZBOOT: adrv=ZBOOT:/test/adrv_precise_5.7.1.sfs
initrd /PUPPYBOOT/precise/initrd.gz

EDIT: I also tested an harddrive with several partitions and it works.

[jlst]

I tried the init script you provided in your first post... it doesn't work with the initrd.gz i *build* (errors occur), so I stick with the current init script in the initrd_progs repo which is patched with your changes (but that change is not yet committed/pushed)

boot device: sdb1 (usb)

adrv=sda5:/test/....sfs (hard drive)

Sooo... I booted with a usb and pmedia=atahd, it couldn't find the adrive... I always use PSUBDIR, so after looking carefully at the code

this

echo "ONEDEV=$ONEDEV ONEFS=$ONEFS ONEDRV=$ONEDRV PSUBDIR=$PSUBDIR" >> /tmp/puppy-file-search.log #101127 for debugging.

if [ -d /mnt/data${PSUBDIR} ];then

if [ "$VMLINUZ" = "" ];then #search for kernel.qky and vmlinuz...

became

echo "ONEDEV=$ONEDEV ONEFS=$ONEFS ONEDRV=$ONEDRV PSUBDIR=$PSUBDIR" >> /tmp/puppy-file-search.log #101127 for debugging.

if [ -d /mnt/data ];then

if [ "$VMLINUZ" = "" ];then #search for kernel.qky and vmlinuz...

note that -> if [ -d /mnt/data ];then

after this change i repacked the initrd.gz and then it found the adrv with the Network Wizard which appeared finally with its popups in the desktop.

Overall your changes are solid and I will add them to the initrd_progs repo which is dedicated to experiment with the latest version of all the initrd programs, which includes busybox 1.24.2 with almost all its applets enabled.

Meanwhile you might want open a pull request at the woof ce main repo.

I just want know, what do you think of this particular change I just pointed out?

[gyro]

I just want know, what do you think of this particular change I just pointed out?

It doesn't look right.
But then I couldn't pinpoint the actual situation based on the information you provided.
If the filename spec starts with a "/" then PSUBDIR should be ignored for that file. I will do some more testing myself.
Could you please post the output from "/proc/cmdline" for the situation that fails, and a "diff -u" between the version of "init" that failed and your modified "init" that worked.

I will also attempt to patch the "init" script from initrd_progs.

gyro

[gyro]

@jlst,

I found a bug.
I'll get back with a new set of patches and a patched "init" for initrd_progs.
(And I'll update all the "initrd.gz" files.)

gyro

[gyro]

boot device: sdb1 (usb)

adrv=sda5:/test/....sfs (hard drive)

Sooo... I booted with a usb and pmedia=atahd, it couldn't find the adrive... I always use PSUBDIR, so after looking carefully at the code

this

echo "ONEDEV=$ONEDEV ONEFS=$ONEFS ONEDRV=$ONEDRV PSUBDIR=$PSUBDIR" >> /tmp/puppy-file-search.log #101127 for debugging.

if [ -d /mnt/data${PSUBDIR} ];then

if [ "$VMLINUZ" = "" ];then #search for kernel.qky and vmlinuz...

became

echo "ONEDEV=$ONEDEV ONEFS=$ONEFS ONEDRV=$ONEDRV PSUBDIR=$PSUBDIR" >> /tmp/puppy-file-search.log #101127 for debugging.

if [ -d /mnt/data ];then

if [ "$VMLINUZ" = "" ];then #search for kernel.qky and vmlinuz...

note that -> if [ -d /mnt/data ];then

after this change i repacked the initrd.gz and then it found the adrv with the Network Wizard which appeared finally with its popups in the desktop.

I've found the problem. That "if" means the ata drive is not serached at all.
I'm going to try a different solution, moving my code to after the end of that "if".

gyro

[gyro]

I have attached an updated "init" script that fixes problems with finding specified sfs files on ata drive when booting from usb.
It's a patched version of the "init" script from the "initrd_progs" project.

More updated files will follow.

gyro

[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