Upgrading kernel modules with a flash filesystem

["Who Dunnit" <whothevella@hotmail.com>]

Hi,

I was wondering if it is possible to have your kernel modules be stored in a 
partition different from the one on which the kernel is. The intent is to 
simply have /lib/modules/`uname -r` be a symbolic link to a directory on 
another disk.

I am using a 2.6 kernel and the /etc/inittab file seems to invoke 
/etc/init.d/rc.udev before it mounts all the other partitions (say on other 
disks). This leads to a case where udevstart (invoked from rc.udev) tries to 
probe for modules that exist in a partition that hasn't been mounted yet 
leading to a whole bunch of error messages.

Having the partition containing these modules be mounted before 
/etc/init.d/rc.udev is invoked is not an option either since /dev hasn't 
been populated yet.

Being able to point /lib/modules/`uname -r` to a directory in another 
partition seems to be an easy way to "upgrade" modules in flash based 
filesystems where you might not be comfortable erasing existing module files 
before installing new ones for the reason that the whole process takes time 
and any power failure during this time can be catastrophic. Being able to 
download all your modules to a new partition and simply flip 
/lib/modules/`uname -r` to point to a different directory in a new partition 
for the upgrade to automatically happen seems like a nifty feature to have.

Is it possible, using /etc/init.d/rc.udev to be able to only create a subset 
of the final /dev tree so that this model can be made to work?

Or maybe there is a whole different strategy on module upgrades for flash 
based filesystems which, being a Linux novice, I am not aware of.

Cheers!
Vella

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/