According to Tom Savage: While burning my CPU.
>
> In the original message I said that I could not find the file "System.map"
> anywhere. So I made a link in /boot called System.map linked to
> System.map-2.0.36-0.7 . After that everything was ok.
> It look like this:
> [root@tim-annex2-port1 /boot]# ls -l Sys*
> lrwxrwxrwx 1 root root 21 Feb 7 10:54 System.map ->
> System.map-2.0.36-0.7
> -rw-r--r-- 1 root root 105911 Oct 13 22:41 System.map-2.0.36-0.7
A normal Redhat install "links" its System.map-version_number to
"System.map" during the install, or it should.
Syslog will not find System.map in / /boot or /usr/src/linux if it is called
anything other than "System.map". Hence the symlink with Redhat.
In another message about System.map a few days ago i wrote and said that
System.map was only used for debugging perpourses, now i completly forgot
about Syslog, i must appolagise for that.
Now the reason i say leave System.map where it is after making a new kernel
is that i remove the symlink in /boot because i keep experimenting with
different kernel versions, this can be a pain in the rear-end everytime you
boot because of different module versions being detected.
If no System.map is found in /boot or / then Syslog looks into
/usr/src/linux, now the linux directory is normaly a symlink in /usr/src
pointing to the directory where the sorce is for that particular kernel
version.
That way there are no more problems with;
1) copying System.map evrytime to /boot or where ever.
2) Undefined symbols with modules.
Last but not least its "less work".
On another note, redhat 5.1 sysv initscripts had some problems with an rc
file which did symbolic linking in the /boot directory for the kernel
version being booted, are you using redhat 5.1 by any chance.??
As far as i know there are no problems with Redhat 5.2 and sysv init
scripts.
>
> ----------------------------------
> E-Mail: Tom Savage <[EMAIL PROTECTED]>
> Date: 08-Feb-99
> Time: 10:19:35
>
> This message was sent by XFMail
> ----------------------------------
>
--
Regards Richard.
[EMAIL PROTECTED]
