doh, I forgot to upgrade there are a handfule of packages to upgrade for 2.2.x
compatibility! Thanks.
Simon Hill wrote:
>
> Hi Justin,
>
> If you are installing this kernel on a Red Hat system, the following info may
> be useful. If not, pls ignore.
>
> Simon Hill
>
> ---------------------------------------------------------
>
> If you have 2 module directories, such as
> /lib/modules/2.0.36 and /lib/modules/2.0.36-0.7, it depmod's
> one one of them and uses the modules of the other for
> modprobe, etc.
>
> I've seen this on the x86. Not sure if it applies to others
> or not.
>
> ------- Additional Comments From [EMAIL PROTECTED] 12/23/98 12:09 -------
> It looks like what happens is that it gets to
>
> if [ -e /lib/modules/preferred ]; then
> depmod -a preferred
> else
> depmod -a
>
> in /etc/rc.d/rc.sysinit, runs depmod on prefered, and then kerneld
> tries to find dependancies for /lib/modules/<version>/ from
> /lib/modules/<version>/modules.dep .
> /lib/modules/<version>/modules.dep in turn has dependancies for
> /lib/modules/preferred/ instead, and so this doesn't work.
>
> [EMAIL PROTECTED] says the priority for this needs to be higher; none
> of us have permissions to change it.
>
> ------- Additional Comments From [EMAIL PROTECTED] 12/23/98 12:12 -------
> erm. those should be /lib/modules/version/ instead of /lib/modules//
> .. Angle brackets apparently aren't liked by bugzilla.
>
> ------- Additional Comments From [EMAIL PROTECTED] 12/23/98 13:57 -------
> Here's what appears to be happening:
>
> 1) The linux kernel sends KERNELD_REQUEST_MODULE.
> 2) /sbin/kerneld picks up the message and execs
> /sbin/modprobe -k -s modulename
> 3) modprobe does
> read_config_file(NULL)
> which does
> if (!access("/lib/modules/preferred/modules.dep", R_OK) {
> depfile = "/lib/modules/preferred/modules.dep";
> add_set("/lib/modules/preferred")
> }
> and then does
> add_set("/lib/modules");
> add_set("/lib/modules/default")
> and finally
> add_set("/lib/modules/2.0.x"); # 2.0.x is kernel release
>
> This results in /lib/modules/2.0.x being searched for modules
> to be loaded before /lib/modules/preferred.
>
> Try "modprobe -c | grep path" to see the currently configured
> set of paths to be searched in first found order.
>
> The work around is to add to /etc/conf.modules:
>
> for i in sound ipv6 ipv4 cdrom block scsi net misc fs
> do
> echo "path[$i]=/lib/modules/preferred" >> /etc/conf.modules
> done
>
> and verify that /lib/modules/preferred precedes /lib/modules/2.0.x
> using "modprobe -c"
>
> This problem could (should?) be fixed in modprobe.c ...
>
> ------- Additional Comments From [EMAIL PROTECTED] 12/23/98 15:15 -------
> ... and now has been fixed in
> dist-5.2.1/modultils-2.1.85-10
> dist-6.0/modultils-2.1.121-2
>
> ------- Additional Comments From [EMAIL PROTECTED] 01/07/99 13:10 -------
>
> *** Bug 96 has been marked as a duplicate of this bug. ***
>
> The modprobe utility puts the preferred directory at a
> priority lower than enything else. The effect is that if
> you have a directory named /lib/modules/2.0.36 then
> whatever is in this directory will take precedence over the
> contents of /lib/modules/preferred ->
> /lib/modules/2.0.36-0.7
>
> This is only a problem if you build a new kernel and kernel
> modules and the modules are installed in the 2.0.36
> directory. If you then boot from the new kernel everything
> is OK, but if you boot from the original release kernel
> 2.0.36-0.7 then you get module load problems.
>
> I assume that the preferred directory (symbolic link) was
> intended to have the higest priority, and that when you boot
> from a newly linked kernel the rc.sysinit will remove
> preferred which causes the 2.0.36 to take the place of
> higest priority.
>
> ------- Additional Comments From [EMAIL PROTECTED] 12/16/98 12:10 -------
> The script in /etc/rc.d/rc.sysinit creates a new preferred link
> everytime the machine boots based on the version of the kernel it
> detects therefore if you boot a new kernel it should set the preferred
> link to the directory with the new modules. One thing you should do
> before doing a modules_install during the kernel compilation is move
> your old /lib/modules/2.0.x to /lib/modules/2.0.x.old or something
> like that. That way your old modules do not get overwritten if you
> want to revert back to an older kernel later.
>
> On Tue, 27 Apr 1999, Justin Georgeson wrote:
> >I went through all the make xconfig; make dep; make clean; make bzImage;
> >make modules; make modules_install and didn't see any errors, I put all
> >the file in /boot and made a new initrd image with the new modules. Then I
> >edited /etc/lilo.conf and ran lilo. All fine. So I rebooted, problem.
> >There seems to trouble with the modules that were compiled. I booted an
> >old kernel and checked /lib/modules/2.2.6 and noticed there was no
> >modules.dep, so I ran depmod -a 2.2.6 and was given this:
> >
> >/lib/modules/2.2.6/fs/romfs.o: unresolved symbol(s)
> >/lib/modules/2.2.6/fs/nfsd.o: unresolved symbol(s)
> >/lib/modules/2.2.6/fs/minix.o: unresolved symbol(s)
> >/lib/modules/2.2.6/net/tulip.o: unresolved symbol(s)
> >/lib/modules/2.2.6/net/dummy.o: unresolved symbol(s)
> >/lib/modules/2.2.6/scsi/aic7xxx.o: unresolved symbol(s)
> >/lib/modules/2.2.6/block/nbd.o: unresolved symbol(s)
> >/lib/modules/2.2.6/block/rd.o: unresolved symbol(s)
> >/lib/modules/2.2.6/block/loop.o: unresolved symbol(s)
> >
> >I would have thought this would have created problems during make modules.
> >I also tried redoing it all and instead of doing make modules_install and
> >copying the rest by hand running make install, this had the same effect.
> >Any ideas here?
> >
> >
> >---------------------------------------------------------------------------
> >Send administrative requests to [EMAIL PROTECTED]
> --
> Simon Hill ([EMAIL PROTECTED])
> Operating Systems Specialist
> Department of Utilities
> University of Texas
> ---------------------------------------------------------------------------
> Send administrative requests to [EMAIL PROTECTED]
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
