modprobe script removed, mounting zdrv

I have been playing with some ideas. /sbin/modprobe is a script, has been for quite some time in Puppy. With the latest 4.1alpha I have simplified the script enormously, as the modules are present at /lib/modules and don't have to be fetched.
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.

Posted on 29 May 2008, 23:01


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