I took another look at this, and decided why not go back entirely to the original modprobe binary executable only. The code that was in the script, to install a firmware tarball, is now elsewhere (in /etc/rc.d/functions4puppy4) and is called separately by rc.modules, rc.modules2 and pup_eventd.
The latest idea of mounting the zdrv directly on /lib/modules has one drawback -- installation of extra modules.
One workaround would be to modify the zdrv_xxx.sfs file, which is not so difficult.
Another possible solution is not to mount the zdrv file directly on /lib/modules. Instead, mount it elsewhere, then create a unionfs on /lib/modules. This may seem complicated, but Unionfs is intended to handle forks in its unionfs layers, and this scheme should work fine (touch wood).
...I'll try it.
Comments:Posted on 30 May 2008, 5:12 by kirk
One problem with modifying the zdrv to add modules would be with these proprietary installers like ATI and Nvidia have that want to install to /lib/modules. Guess you could unmount the zdrv and then run the installer then modify the zdrv.
I'm kind of confused about having the modules in a sfs file that's attached with UnionFs. I thought that 4.01alpha moved it's modules into the initrd.gz so that they would be available to the kernel during boot. But to mount a sfs file doesn't the kernel already have the modules it needs? And if you can mount an sfs file, why not put the modules in the main pup_401.sfs file?
I like what you've done in 4.01alpha, just copying the modules into the pup_save file. 18MB is not that much.
Also, alpha1 is working quite well for me.
Posted on 30 May 2008, 9:18 by crafty-one
@BK said :-
"The latest idea of mounting the zdrv directly on /lib/modules has one drawback -- installation of extra modules."
If you can mount an sfs file - OR A FEW - then why not make allowance to mount a second 'zdrvNEW_xxx.sfs' file containing any new or added modules not in the main 'zdrv_xxx.sfs' file - should simplify things - if "new" modules are not needed then this extra 'zdrvNEW' is not mounted..
Where there is a need for this extra 'zdrvNEW' file to be mounted - then maybe a script that can be run in the background AFTER the main bootup has completed to do a "merge" of this extra 'zdrvNEW' file with the existing 'zdrv_xxx.sfs' file thus creating an updated 'zdrv' for the next boot..
Just my $0.002c's..