Zacarias --
I'm having a bit of trouble following your writing, so please forgive me if
this isn't responsive.
Before Mary did anything, she had one kernel (perhaps /boot/vmlinuz-2.2.12)
and a set of related modules in /lib/modules/2.2.12 . She then compiled a
new kernel, which compiled into /usr/src/linux/something_or_other/zImage .
Somehow (she never said how, but it usually done by hand), she mv'd or cp'd
this kernel to /boot, I assume under a different name -- let's call it
/boot/vmlinuz-SMP .
She also did "make modules", which compiled the modules she needed for the
new kernel, then "make modules_install", which REPLACED the old
/lib/modules/2.2.12 with a new /lib/modules/2.2.12 ... which had the modules
for the new, SMP kernel, not the ones for the old, stock kernel.
She updated LILO to default to the new kernel. But for some reason (we don't
know what; she probably doesn't know what, yet), the new kernel did not boot
correctly. Fortunately, being a careful sysadmin, she had kept her old
kernel around, and proceeded to boot it (I'm skipping some details here, but
it's a standard LILO setup).
Alas, this old kernel doesn't work with the new modules ... the old and new
kernels are sufficiently different, despite both being variants of 2.2.12,
that modules compiled for one won't work with another. (In theory, the
MODVERSIONS setting corrects for this; in practice, it is somewhat
disappointing.)
So ...
... she had the new kernel and associated modules, but some error in
the compile process makes it a non-functional kernel.
... she has the old kernel, but she lacks its associated modules.
She didn't say, but I bet the system boots and inits, but doesn't connect to
the network (because it needs module support for the NIC).
If she were on site, the fix would (probably) be easy -- boot with the old
kernel, work from the console, and fix the problems with the new kernel.
Since she's about 5000 miles from the server, that's not an option.
Does this clear things up?
At 09:01 PM 6/3/00 +0200, Zacarias ecumberri Sanchez zacals wrote:
>From:"Mary Christie Generalao" <[EMAIL PROTECTED]>
>
>>Thanks a lot. Really im starting to feel the difficulties of
>>administering
>>remote machines (with no tech support onsite).
>>
>>Mary Christie
>
>>----- Original Message -----
>>From: Ray Olszewski <[EMAIL PROTECTED]>
>>To: Mary Christie Generalao <[EMAIL PROTECTED]>;
>><[EMAIL PROTECTED]>
>>Sent: Saturday, June 03, 2000 10:30 PM
>>Subject: Re: unresolved symbols
>
>>> It sounded like you compiled a new (for example) 2.2.13 kernel on
>>> a system that had an old 2.2.13 kernel, and you did not extend the
>>> version number to distinguish them.
>Well, that extend is something like sub-sub-version, isn't it?
>>> As a result, when you did "make modules_install", you overwrote
>>> the old kernel's modules with the new ones. (Unless you previously
>>> did something like "mv /lib/modules/2.2.13
>>> /lib/modules/2.2.13-old", thus making the modules backup that the
>>> standard kernel-compile README file recommends; then you have them
>>> safely tucked aside and you can put them back quite easily.)
>And now I don't understand a shit,... You state she compiled a new
>kernel so then I think there are two kernels the 2.2.13new and the
>2.2.13old (the active one before compile(kernel,modules)/reboot) or
>only one (if it is also overwriten given the fact that they are not
>distingued. Then she overwrites old modules. So: what's wrong with
>that? She hasn't distinguished among them and overwrite occurs, but
>after this, she has the matching 2.2.13new kernel and 2.2.13new
>modules, so all should be ok when booting. Then, how did she came
>up with those unresolved symbols?
>She might had lost the old modules and maybe the image, but she should
>have the new ones.
>But, hey, I think now there might be old modules in the directory if
>they weren't removed. Is it what I'm missing? I cannot think of
>another.
>I have not had experience with different equal-version kernels.
>Where may I find information on that extend-def and equal-versions?
>I would be glad if someone explains me all that mess I have.
>>>
>>> If you and the machine are not co-located, this is tough to fix.
>>> You need to reload the kernel-image file for your default kernel
>>> or compile a new kernel that works. You might have a config file
>>> for your default kernel in /boot; some distributions include one
>>> with the image, but others don't.
>I know nothing about that, do you do remote administering by Telnet?
>
>Oh well, TIA.
------------------------------------"Never tell me the odds!"---
Ray Olszewski -- Han Solo
Palo Alto, CA [EMAIL PROTECTED]
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
