Re: Almost painless upgrade to 2.0.26

[turnbull@example.com (Stephen J. Turnbull)]

>>>>> "Dennis" == Dennis McMurchy <denismcm@example.com> writes:

    Dennis>   I had one small hitch in upgrading from 2.0.0 to 2.0.26
    Dennis> last night.  It has to do with modules.  I eventually
    Dennis> realized that I had to do a 'make modules' 'make
    Dennis> modules_install' as part of the compile.  But that hasn't
    Dennis> taken care of all the problems.

For those of you who aren't interested in the details (this is _long_) 
but occasionally get snagged in upgrades, here's a hint:

   less -p '<problem keyword>' /usr/src/linux/Documentation/Changes

/usr/src/linux/Documentation/Changes is _not_ all that technical in
general; it's oriented towards identifying upgrade problems, just as
you've encountered, not towards helping kernel hackers.

Details, as per the Surgeon General's Warning above:

Modules are pretty complicated, and the "user interface" hasn't
settled down yet.  What one would like is something that

1. Keeps the kernel small by leaving out never-used drivers (eg, for
   hardware you don't have).  This has the side benefit of forcing a
   standard interface on the drivers, which then become simpler to
   program and debug.  But still permit adding new drivers on-the-fly
   without rebuilding the kernel.
2. Move as much code as possible out of the privileged area.  Then
   it's much harder for your mouse driver to overwrite your .emacs
   file.
3. Load drivers on demand.  For example, you might use both PLIP and a 
   local printer.
4. Keep track of all this both on a day-to-day basis and when the
   kernel upgrades.
5. And other stuff I've forgotten.

1 is solved by the current module setup, except that the best time for
loading and unloading drivers would be at configure time for newbies,
so they can try different SCSI drivers, for example.  This is not
properly supported (however, I know how to do it, and RedHat and
Debian are apparently thinking about moving in this direction; start
by loading from floppy to a RAM disk, then insmod the SCSI drivers).

2 is not addressed by the current architecture; modules still have
kernel privileges.

3 and the first half of 4 is fairly well addressed by the kerneld.

The rest of 4 is not even properly dealt with at the makefile level
yet.  (IMHO, if modules are configured, they ought to be automatically
built and installed.  Yes, yes, I know if they don't work right,
taihen desu, but that's still taihen for the non-hacker in any case.)

The current Linux module process works like this:

1. Boot kernel.
2. Kernel wakes up built in drivers, almost always including the
   display, mouse, keyboard, and root device, and often many others.
3. (optional, 2.x) Kernel wakes up kerneld.  kerneld will create
   stubs for modules which callback the kerneld.  When activated,
   kerneld finds and insmod's the relevent module.
4. Kernel starts init.  Init runs the rc scripts, one of which does
   depmod -a.  This determines location and dependency tree for
   installed modules.
5. (optional, pre-2.x) Init starts kerneld.
6. (optional) User does an insmod or a modprobe to load a module.
   insmod doesn't know about dependencies, modprobe does.  When a
   module is loaded, kernel checks for version information and refuses 
   to load if present and wrong.

It sounds like your setup is 1, 2, 4, then 6, but I'm not sure.  I
don't know under what conditions depmod says "can't locate module"; I
think it's modprobe saying that, but I can't be sure since they are
the same binary.

    Dennis>   When I boot up I get the following error messages:
    Dennis> 1. Updating module dependencies for Linuz 2.0.26
    Dennis> 	Can't locate module lp
    Dennis> 	Can't locate module slip
    Dennis> 	Can't locate module ppp
    Dennis> I haven't tested the printer, but I know that slip and ppp
    Dennis> are activated at an earlier stage of the boot, and ppp is
    Dennis> usable.  Also there's no reference to these in
    Dennis> /lib/modules/2.0.26/modules.dep .

It sounds to me like they've been included in the kernel.  Things to
check in decreasing order of probability (IMO):  Is your
/etc/conf.modules up-to-date?  If it's still the 2.0.0 version, then
things are going to be weird.  Are these modules present in the proper
directories (./net, ./misc, etc)?  Do a

		      ls -R /lib/modules/2.0.26

Look at the file /usr/src/linux/.config.  It should include lines like

			     CONFIG_PPP=m

for each of the modules.  If the 'm' is a 'y', then it got built in.
Also look at /usr/src/linux/Makefile and make sure it begins with

			    VERSION = 2
			    PATCHLEVEL = 0
			    SUBLEVEL = 26

If not, your source trees are getting confused.  I normally keep at
least the last working version of the kernel around.  If you need to
switch back, you will need to have the correct /usr/include/linux
files to compile any system-related utilities.  So I normally have
/usr/src looking like this

lrwxrwxrwx   1 root     root           12 Nov 25 12:02 linux -> linux-2.0.26
drwxr-xr-x  15 root     root         1024 Jun 24 16:14 linux-2.0.0
drwxr-xr-x  15 root     root         1024 Nov 25 14:06 linux-2.0.26

This helps keep things sorted out.  When upgrading by patching the
easiest thing to do is to copy the whole tree and patch over that.
It's possible to save space by massive symlinking, but this requires
that you know what you're doing; patch doesn't handle that itself.

    Dennis> 2.      Loading the iBCS module
    Dennis>         Cannot open /lib//modules/misc/iBCS.o

I don't fully understand this message; it doesn't include a proper
reference to the kernel version.  I think what's happening is that
insmod looks first in the kernel-specific area, forgets to complain,
then looks in a general catch-all area, and complains when it doesn't
find it there.

    Dennis> If I make a symbolic link to the existing iBCS.o, then it
    Dennis> complains that it's the 2.0.0 version.

It's tagged with version information.  There's no way to work around
this as far as I know; you can only rebuild.

    Dennis>   Why is 'make modules' not taking care of these problems.
    Dennis> What am I doing wrong?

As above, my guess is that the net-serial and lp modules weren't
built, probably because they weren't configured.  There also seems to
be some problem with reporting errors in building the modules; if some 
modules can be built, but others not, the build continues.  So if
you're not watching the build carefully you might miss error messages.

iBCS is a different problem.  As far as I know, iBCS is not
distributed with the Linux kernel sources; I don't know why.  See
/usr/src/linux/Documentation/Changes for details.  Ah, forget that,
it's short:

iBCS and Dosemu
===============

   For a version of iBCS that works with 2.0.x kernels, grab
ftp://tsx-11.mit.edu/pub/linux/BETA/ibcs2/ibcs-2.0-960610.tar.gz

   For a version of Dosemu that works (well, at least as well as DOS
ever works ;-), get
ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/Development/dosemu-0.64.0.3.tgz
or check out http://www.ednet.ns.ca/auto/rddc. Be sure to follow the
instructions in README.newkernels about patching your include files, or
it will not compile.

    Dennis> over and over again, alas without finding any oneiric
                                                          ^^^^^^^
Sugoi vocabulary!

Steve

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@example.com
-----------------------------------------------------------------
a word from the sponsor will appear below
-----------------------------------------------------------------
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.   info@example.com
Tel: 03-3351-5977   Fax: 03-3353-6096