Upgrading kernel modules with a flash filesystem

From: Who Dunnit
Date: Fri Jul 07 2006 - 18:46:05 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/