Using modules-update from sys-apps/baselayout-1.12.0_pre6-r3 I get the following warning on every boot: "System.map not found - unable to check symbols". This happens due to the fact that /sbin/modules-update checks for the presence of /usr/src/linux/System.map, which is not available at boot time, since /usr is not yet mounted. On another note, there is no guarantee that the kernel source for the currently running kernel is present in /usr/src/linux - this location can specified for all portage activity using the KERNEL_DIR environment variable - or the user could be booting an older kernel...
you'd get a warning from insmod then, so it's not like you can 'fix' modules-update to not warn using the wrong System.map is probably worse than getting a warning though ...
----- <dsd_> ok, well that can be fixed relatively easily then <dsd_> ie /lib/modules/2.6.13-gentoo/build/System.map <dsd_> but the mounting prob will still exist ----- Probably a good idea to avoid issues for when /usr/src/linux do not point to the right place, but yeah, its not going to fix /usr on diff partition. Only way I can see to do that, will be to do a modules-update early during shutdown/reboot, and then there still might be some loopholes ...
Actually, early in halt.sh might work.
Created attachment 67505 [details, diff] Patch for /sbin/modules-update This patch fixed part of the problem: use the System.map from the currently running kernel.
Any chance of getting this patch applied before baselayout-1.12 goes final?
baselayout-1.12 wont be going stable for quite some time :p
Then can we please have it applied to the stable branch?
Personally, I would question if this was still needed (OK, it is but bare with me) 2.6 has successfully booted the requirement of having System.map, so the only thing which is still needed is for a 2.4 kernel. Since we have gone 2.6 default, we can possibly look at this as a means for back-compatibility and shelving support. I woudl also remove any warnigns on a 2.6 kernel as this is completely unneccessary. Of course, I may be mistaken so please correct me but I know of nothing which uses this anymore.
heh.. except for depmod apparently, but I'll leave the question open anyways!
Correct me if I am wrong, but isn't System.map also used for debugging the kernel? Looking up module symbols etc?
/proc/kallsyms supplies (afaik) identical information. I have a niggling feeling it is lacking some very minor symbol information, but of course this is accessible only via the running kernel configuration. IE: why System.map still bodes a potential use.
Erk, sorry, forgot about this. How about this patch: ----- Index: sbin/modules-update =================================================================== --- sbin/modules-update (revision 1601) +++ sbin/modules-update (working copy) @@ -227,10 +227,10 @@ # is more recent then modules.dep if [[ ${CFGFILE2} -nt /lib/modules/${KV}/modules.dep ]] ; then if [[ -d $(depdir) && -f /proc/modules ]] ; then - if [[ -f /usr/src/linux/System.map ]] ; then - depmod -a -F /usr/src/linux/System.map ${KV} + if [[ -f /lib/modules/${KV}/build/System.map ]] ; then + depmod -a -F /lib/modules/${KV}/build/System.map ${KV} else - ewarn "System.map not found - unable to check symbols" + depmod -a ${KV} fi fi fi ----- The user's system will bork if he reboot into a broken kernel, but he should in theory see that already at kernel install time if he uses 'make install'. PS, John, why dont the kenrnel guids persist on copying the kernel image, and not rather use 'make install' and then using /boot/vmlinuz or /boot/vmlinuz-${KV} in grub/lilo ??
I'll assume the guides use make install for simplicity reasons. In all cases, I never use it personally. Do you have a list of the documents which comment on "make install" at all? I will get them changed so they also advise on: cp arch/XXXX/boot/bzImage /boot/bzImage-KV or vmlinuz of course. I often just have a bzImage && bzImage-safe symlink to the appropriate files.
(In reply to comment #12) > Erk, sorry, forgot about this. How about this patch: Looks good to me :) > The user's system will bork if he reboot into a broken kernel, but he should in > theory see that already at kernel install time if he uses 'make install'. > > PS, John, why dont the kenrnel guids persist on copying the kernel image, and > not rather use 'make install' and then using /boot/vmlinuz or > /boot/vmlinuz-${KV} in grub/lilo ?? How is that related to this bug?
(In reply to comment #14) > (In reply to comment #12) > > The user's system will bork if he reboot into a broken kernel, but he should in > > theory see that already at kernel install time if he uses 'make install'. > > > > PS, John, why dont the kenrnel guids persist on copying the kernel image, and > > not rather use 'make install' and then using /boot/vmlinuz or > > /boot/vmlinuz-${KV} in grub/lilo ?? > > How is that related to this bug? > Err, because I forgot that 'make modules_install' does the 'depmod -ae ...'. Its anyhow easier ;p
Committed to svn.
*** Bug 112125 has been marked as a duplicate of this bug. ***
*** Bug 112764 has been marked as a duplicate of this bug. ***
*** Bug 119322 has been marked as a duplicate of this bug. ***
*** Bug 119947 has been marked as a duplicate of this bug. ***
According to this link: http://www.dirac.org/linux/system.map/ klogd looks into: /boot/System.map /System.map /usr/src/linux/System.map to find System.map. My /usr is on a different to my / partition and I never had any problems until the recent baselayout update. I assume that the copy of System.map in the /boot worked fine for the last few years. Could it be reverted to look into /boot as well as /usr/src/linux? -- Regards, Mick
What problems have you run into after the baselayout update? Also, is there any particular reason you use klogd? The functionality it uses System.map for is fully implemented into the kernel (kallsyms).
Sorry, perhaps I didn't explain myself properly. I don't have any 'real' problems following the last baselayout update, other than the "System.map not found - unable to check symbols" error message coming up when I boot. This causes some delay to my booting, but that's all. I didn't know that klogd has been superseded by kallsyms (too technical for me to know) - so was merely guessing as to what has gone amiss with my system lately. -- Regards, Mick
*** Bug 123807 has been marked as a duplicate of this bug. ***
*** Bug 121237 has been marked as a duplicate of this bug. ***
*** Bug 123973 has been marked as a duplicate of this bug. ***
*** Bug 124517 has been marked as a duplicate of this bug. ***
I have recently noticed this bug every time I attempt to do a modules-update. I have no idea if my /etc/modprobe.conf or map files (which hotplug depends on) are being generated completely or successfully, all I see is the error message. I see it mentioned in the comments that a fix has been committed to svn, I can't seem to locate the svn repository, so I can't see what the fix was. I have been manually copying System.map to /boot/System.map-x.x.x for at least 10 years, why has this behavior changed recently in gentoo? Does the fix involve supporting System.map being in /boot, as other apps such as procps and klogd do?
This bug still exists on my system too. I get the error whenever I boot up. I see the bug has been closed and marked as fixed. Where do I find the fix?
*** Bug 129339 has been marked as a duplicate of this bug. ***
I applied this patch and it doesn't work. The line /lib/modules/${KV}/build/System.map is just a symlink to /usr/src/linux ! I changed the line to /lib/modules/${KV}/System.map and placed a copy of System.map in this dir and now everything is working.
*** Bug 131229 has been marked as a duplicate of this bug. ***
A simple workaround is to do this after each kernel installation: # cp /usr/src/linux/System.map /
*** Bug 143403 has been marked as a duplicate of this bug. ***
*** Bug 165020 has been marked as a duplicate of this bug. ***
