boot/System.map: Bad file descriptor
Just added a new kernel but when running /sbin/lilo -R linux-smp
I get the error
Would i need to delete the first one?
do ls -l in the /boot directory. System.map needs to be a soft (symbolic) link to System.map-2.6.10-1.14_FC2smp. In other words delete System.map and do ln -s
/boot/System.map-2.6-1.14_FC2smp /boot/System.map. Grub is your bootloader in FC2 and should catch the changes. If you are running lilo, you would need to check /etc/lilo.conf, then run /sbin/lilo.
Thanks for the reply.
If i delete system.map won't this stop the original kernel loading if there are problems loading the new kernel? should i not keep both maps?
You originally typed 'system.map, and I was thinking that your links and filenames might be hosed. I am on FC3 and Grub on this machine. There will always be at least two symbolic links in /boot. vmlinuz which links to vmlinuz-2.6-whatever, and System.map which links to System.map-2.6-whatever. This is your current rumming kernel. As you select a different kernel from the boot menu these links switch to the kernel and System.map you chose.
When you added the new kernel did you do it from up2date, recompile? What is the structure of /etc/lilo.conf?
I am not familiar with the -R switch to /sbin/lilo. I have always edited /etc/lilo.conf by hand and just ran /sbin/lilo. Even when apt, yum, up2date, etc. add a new kernel image, I will check lilo.conf or grub.conf to see what changes have been made. I don't want to lead you down the wrong path so please provide more info.
Am running a server so no Xserver or gui is installed. Server was running redhat 8 but did a yum upgade to FC2 a year ago. All went well but the kernel (2.4 ) was left as the running kernel along with lilo the default bootloader.
I understand that there is/was a problem with FC2 not making a new kernel the default if your using a lilo bootloader.
The latest kernel is not compiled by me but simply installed via yum.
On a desktop i would normally edit lilo and run /sbin/lilo -v but since the server is in a remote location i use the R switch. As i understand it, you add the kernel but don't make it the default, you run /sbin/lilo -R kernel_name which means "make new kernel load at next boot" i believe it also means that should that kernel not load properly, the old ( default ) will load up instead.
If you do ls -l in the /boot directory of that machine, what shows?
[michael@blacky boot]$ ls -l
-rw-r--r-- 1 root root 54308 Feb 1 23:39 config-2.6.10-1.760_FC3smp
drwxr-xr-x 2 root root 1024 Feb 25 18:41 grub
-rw-r--r-- 1 root root 304751 Feb 8 19:12 initrd-2.6.10020705_NOSELINUX.img
-rw-r--r-- 1 root root 304740 Feb 13 06:18 initrd-2.6.10021105_NOSELINUX_SMP.img
-rw-rw-r-- 1 root root 534843 Feb 5 22:18 initrd-2.6.10-1.760_FC3smp.img
drwx------ 2 root root 12288 Feb 4 12:39 lost+found
-rw-r--r-- 1 root root 94440 Feb 9 17:48 memtest86+-1.50
lrwxrwxrwx 1 root root 37 Feb 13 06:18 System.map -> System.map-2.6.10021105_NOSELINUX_SMP
-rw-r--r-- 1 root root 1099825 Feb 8 19:12 System.map-2.6.10020705_NOSELINUX
-rw-r--r-- 1 root root 1094435 Feb 13 06:18 System.map-2.6.10021105_NOSELINUX_SMP
-rw-r--r-- 1 root root 760696 Feb 1 23:39 System.map-2.6.10-1.760_FC3smp
lrwxrwxrwx 1 root root 34 Feb 13 06:18 vmlinuz -> vmlinuz-2.6.10021105_NOSELINUX_SMP
-rw-r--r-- 1 root root 2509520 Feb 8 19:12 vmlinuz-2.6.10020705_NOSELINUX
-rw-r--r-- 1 root root 2333124 Feb 13 06:18 vmlinuz-2.6.10021105_NOSELINUX_SMP
-rw-r--r-- 1 root root 1405753 Feb 1 23:39 vmlinuz-2.6.10-1.760_FC3smp
Neither System.map or vmlinuz (you are missing that altogether) are links, yet I wonder what /etc/lilo.conf says. It would be nice to know that before doing the following;
ln -s System.map-2.6.10-1.14_FC2smp System.map
ln -s vmlinuz-2.6.14-1.14_FC2smp vmlinuz.
I've got lilo on another machine but it's compiling a kernel right now and I can't disturb it.
Somewhere in this mess I've got the current LILO HOWTO and Boot-Prompt HOWTO.
Remote admin, cool! - I envy you.
I might be wrong here, but if i remove system.map and the new kernel fails, the old kernel won't load either ?
I delete the map = entry in favor of setting up /boot with links to System.map, System.map.old, System.map.001, etc. and adjusting lilo.conf accordingly. Same with vmlinuz, i.e. vmlinuz, vmlinuz.old, vmlinuz.001. Can't tell you why I've done it this way. Probably old habits from Debian. IMHO. You appear to have lost or renamed the original System.map file for kernel 2.4.26, so you are in a precarious position anyhow. I would guess that the 'map' file in /boot is the original System.map-2.4.26 for vmlinuz-2.4.26. So, decision time.... If it was me I would rename map to System.map-2.4.26 make the link from System.map to System.map-2.4.26 (since you know what you've got there), then decide how you want to approach System.map-2.6.10-1.14_FC2smp.
**********WHOOOOOOOOOOA************** ok, stop the presses, I stupidly just noticed you have 2
lilo.conf entries for 2.6.10-1.14_FC2smp. The last entry looks bogus and should be gone. The first entry
should read 'label=2.6.10-1.14_FC2smp' or 'linux-smp' depending on how you feel. This still may not help the issues with 'bad file descriptor' but it will get you going in the right direction when combined with the suggestion above to correct the link to your original kernel. And lastly, what does 'uname -r' return on that machine?
In this case, it's Lilo that is bitching about the System.map mismatch.
It's the *current* (running) kernel that you have an issue with. You need System.map to be valid for that system - that file named map from 2004 may be a candidate to be renamed as System.map
Presuming you are currently running a 2.4.26 system, go looking for System.map-2.4.26 - that'll be the fella you want.
Don't know how RH handle things like that though - it's unlikely to be named that in /usr/src but you might be lucky.
Your new kernel/config/system.map names look o.k. to me - that is how I would structure it. If the version extension agrees it will be found - even if a (different) System.map exists.
Linux will apparently boot without the System.map - you may get the odd message. Depending on how your system is built, if you were to delete it from /boot, it may find it anyway. Of course without being able to run lilo, you have a separate issue of the bootloader anyway.
I don't like links for this sort of thing, as I change kernels a lot. Rebooting to flip-flop kernels shouldn't mean updating a symlink all the time. But as I don't do Fedora, I won't make a suggestion on best solution for you.
Note: for some reason the above Howto seems to be in trouble as tldp.org has a page up stating that the document is down for review. Anyone know why??
As pixie is dealing with what appears to be a production server, I would not disregard the System.map links in /boot as suggested by syg00. Although correct that System.map isn't critical to the system, it could have unintended effects on programs such as klogd. It is a symbol table unique to the kernel build that produced it. It is there if for nothing more than standardization and post-oops troubleshooting.
The following is cut 'n pasted from the reply of "Ben Caradoc-Davies", a
friendly netizen who replyed to a similar tread in
/boot/System.map is used by ksymoops to convert addresses (in kernel oops) into symbols.
Does lilo need it?
Is it needed for loadable modules?
Do other applications use this file?
There is nothing stopping them. :-)
/boot/System.map is a symbolic link to the appropriate map file. You can do this by hand, or in the case of recent RedHat releases, this link is updated at boot time by the following in rc.sysinit:
if [ -L /boot/System.map -a -r /boot/System.map-`uname -r` ] ; then
ln -s -f System.map-`uname -r` /boot/System.map
I guess it is for you to decide.
And yes, I'd be *REAL* careful with prod systems too.
The last couple of paragraphs were info only - I should have been a bit clearer.
And given the code snippet, links are not an issue with later RH releases apparently.
OK, the running kernel is 2.4.26 on a production server.
The system.map listed in /boot i assume is for 2.4.26. As a search for system.map throws up the one in /boot and also one in /usr/src/linux-2.4.26 but its called just system.map there is no file called system.map-2.4.26
So does that seem right? The server was booted about six months ago without problem so i'm thinking it must be..........but then again you say it will boot a kernel without any system.map ? /me/scratches head.
I have two kernels installed on my desktop pc. In /boot there is a file called just system.map for the original kernel and system.map-2.6.10-1 for the newer running one. I can switch between either kernels fine. I just can't work out why this shouldn't work on the server.
But if the system.map in /boot is not the one for 2.4.26, how about if i delete that system.map, (and the 2004 map ) then move the system.map from /usr/src/linux-2.4.26 to /boot and leave the soft link to system.map-2.6.10-1.14_FC2smp ?
Bad assumption - if the /boot/System.map was for the current kernel, you wouldn't have this problem.
The /usr/src/linux-2.4.26/System.map is likely to be correct.
Looks like you have "touched" the /boot/System.map recently - certainly since the last boot.
- don't EVER delete anything - rename to something memorable.
- after that rename, copy /usr/src/linux-2.4.26/System.map to /boot
- symlink if you (and others who know RH) deem it necessary.
- rerun the lilo command - you'll know if the System.map matches the kernel. Get the test out of the way without having to resort to a boot.
- be happy (we hope)
|All times are GMT -5. The time now is 11:54 AM.|