Modules-update needs System.map matching the current kernel version, and looks for it in /lib/modules/${KV}/build, which is a symlink to the linux source tree in /usr/src/ which served to build the matching kernel. However, it is common practice to have /usr being a separate partition than /. Unfortunately, upon booting the system, /etc/init.d/modules has to be started before non-root partitions are mounted (e.g for cryptoloop, filesystem modules, etc...). This triggers the current bug, where System.map is obviously non-existent at the time /etc/init.d/modules is started. bug present using: sys-apps/baselayout-1.12.6 possible solutions: - System.map from /boot should be used (problematic for separate /boot partitions, but nice for genkernel users since it copies it to /boot already) - System.map should be copied to /lib/modules/${KV}, not symlinked nor accessible via a symlink - The three solutions at once (current one plus the two above), sequentially testing for each System.map existence and using the first available one. Please note that this is not a dupe of bug #104288 which concerns using the correct System.map via /lib/modules/${KV}/build instead of trusting blindly the /usr/src/linux symlink) Reproducible: Always Steps to Reproduce:
(In reply to comment #0) > possible solutions: > - System.map from /boot should be used (problematic for separate /boot > partitions, but nice for genkernel users since it copies it to /boot already) > - System.map should be copied to /lib/modules/${KV}, not symlinked nor > accessible via a symlink > - The three solutions at once (current one plus the two above), sequentially > testing for each System.map existence and using the first available one. <snip> if [[ -d ${depfile%/*} ]] ; then if [[ ${CFG_NEW_FILE} -nt ${depfile} ]] ; then ebegin "Updating modules.dep" for cfg in /lib/modules/${KV}/build /usr/src/linux-${KV} \ /boot /usr/src/linux "" do cfg="${cfg}/System.map" [[ -f ${cfg} ]] && break done [[ -n ${cfg} ]] && cfg="-F ${cfg}" depmod -a ${cfg} ${KV} eend $? fi else vewarn "The dir '${depfile}' does not exist, skipping call to depmod" fi </snip> Relevant part of /sbin/modules-update from sys-apps/module-init-tools-3.2.2-r2 above. I really don't see what are you trying to fix there. If you can't live with the completely harmless warning about a completely useless file, then copy it to one of the 3 locations. For the rest of users that have better things to do than to stare at the screen during boot, I don't see why they should have 3 redundant copies of System.map scattered across their system for every single kernel version they have installed. Really sounds like some kind of obsession.
added to 2.6.9-r2, thanks for the report !
erm wrong bug
yeah, just copy your System.map to /boot the kernel `make install` does this for you
1. I don't know what's System.map role exactly, but when a service fails to start ([!!] state) with a file not found error, it's not exactly reassuring. 2. I would suspect files having vastly different content would bring up different results... 3. genkernel is a gentoo supported tool (which I use), and gives a /boot/System.map-genkernel-${KV} file, so I'd suppose modules-update could have support for that naming scheme.
considering the purpose of the script (to update module dependencies), it only makes sense to display that when the script failed easy enough to add suffix searching, so modules-update now searches for: System.map{-{genkernel-$KV,$KV},}
Created attachment 109082 [details, diff] modules-update.diff (In reply to comment #6) > easy enough to add suffix searching, so modules-update now searches for: > System.map{-{genkernel-$KV,$KV},} genkernel copies this as e.g. System.map-genkernel-x86-2.6.19-gentoo-r5 (see /usr/share/genkernel/gen_arch.sh) so the above won't match. Getting more PITA than it's worth.
tweaked the code a little to check $(uname -m) followed by a glob if someone complains that they're using genkernel and so they have multiple arches in /boot/, well their answer is too bad
I 'm reporting it works for me (separate /usr, but /boot on /). people having separate /, /boot and /usr will have to cp it to /. now, if you take a look at some page (cached by google): http://209.85.135.104/search?q=cache:BrB5aYHpacMJ:dirac.org/linux/system.map/ that does not seem a useless file to me, at least in some certain interesting circumstances. I may seem obsessive, but I like my computer to be ticking like a swiss clock. whatever, thanks for having provided a fix.
*** Bug 167798 has been marked as a duplicate of this bug. ***
It is not some kind of obsession: If System.map is not found then depmod -a is not executed which means that the system will fail to load modules (unless modules-update --force was executed after the module installation and before the reboot which however might easily be forgotten. Recently, I was simply lucky that I could enter a rudimentary system despite the missing modules.) Similarly, it is also easily forgotten to copy System.map to / (I am one of the people who have /boot and /usr/src/linux on separate partitions, but in the German forums there were also other complaining). Moreover, having several copies of System.map just because of a broken boot-order is IMHO not an appropriate solution. As remarked in #167798, the problem is that baselayout does not provide a way to mount something (i.e. /boot) before /etc/init.d/modules (calling modules-update) is executed. Of course, the user must know what he is doing if he interferes here manually (e.g. anything required to mount /boot and to check the filesystems must be compiled into the kernel) but IMHO there should be some "cleaner" mechanism to allow such interference than just hacking the baselayout scripts (because such hacking is lost or has to be done again at the next baselayout update).
*** Bug 168157 has been marked as a duplicate of this bug. ***
It should be noted that /sbin/modules-update from the latest module-init-tools (3.2.2-r2) runs "depmod -a -F /System.map ${KV}" even if /System.map does not exist! This should be fixed -- if it cannot find any System.map, it must not tell depmod to use a non-existant one, resulting in a line prefixed with "FATAL"... Next comes a patch that fixes the broken depmod call.
Created attachment 111474 [details, diff] Patch for /sbin/modules-update Only passes -F /path/to/System.map to depmod if it actually exists.
it's hard to see what all those changes are for when you say you just want to prevent calling depmod on a non-existent System.map ... by your description, it could be fixed with this one line: [[ -f ${scfg} ]] && cfg=${scfg} && break 2 done + cfg="" done [[ -n ${cfg} ]] && cfg="-F ${cfg}"
*** Bug 171658 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > it's hard to see what all those changes are for when you say you just want to > prevent calling depmod on a non-existent System.map ... > > by your description, it could be fixed with this one line: > [[ -f ${scfg} ]] && cfg=${scfg} && break 2 > done > + cfg="" > done > [[ -n ${cfg} ]] && cfg="-F ${cfg}" > True, although IMHO, this just makes horrible code worse, from a style point of view. But I agree that my changes aren't *that* elegant either, so just add that cfg="" and make us happy ;)
(In reply to comment #16) > *** Bug 171658 has been marked as a duplicate of this bug. *** > @Jakub sorry if i didn't searched well, but that what just an other simple "elegant" solution not just a dumb bug report. :)
added the cfg="" then
I am sorry if I should not be posting to a closed bug but I thought I should try my inquiry here first to see if I could get a response before troubling anyone with a new bug. I'd like to propose adding /lib/modules/${KV}/ to the search directories for System.map Rationale being: -/usr and /boot could be on different partitions at boot time. -Copying System.map to / doesn't really go very well with multiple kernel versions. Adding /lib/modules/${KV}/ to the search directories would be trivial and allow individual System.map files for each kernel version, in a reasonable place that is guaranteed to be there at boot. Or perhaps someone could fill me in as to why this should not be done? Thank you for your time all.
I remerged module-init-tools to get the latest modules-update and err.. it appears it doesn't matter? It looks like depmod creates modules.dep even if I remove all System.map files. Sorry for wasting your time.
added to cvs, cheers