Somewhere between baselayout-1.11.13-r1 and baselayout-1.11.14-r3, the behavior of modules-update changed so that during boot it terminates with an error "System.map - no such file or directory". This is a change from the past where no error was reported and modules-update completed successfully, resulting in modules.conf and modules.dep having the same timestamp. Now, due to the termination of modules-update, the timestamp on modules.dep doesn't get updated resulting in a mismatch between the two files. This makes /etc/init.d/modules report a problem. -- emerge --info Portage 2.0.54 (!/usr/portage/profiles/default-linux/x86/no-nptl/2.4, gcc-3.4.4, glibc-2.3.5-r2, 2.4.32-gentoo-r2 i686) ================================================================= System uname: 2.4.32-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 2.20GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -funroll-loops -fomit-frame-pointer -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -mtune=pentium4 -funroll-loops -fomit-frame-pointer -O3 -pipe" DISTDIR="/build/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.jf.intel.com/gentoo http://gentoo.osu.osl.org" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/build/tmp" PORTDIR="/build/portage" SYNC="rsync://gentoo.jf.intel.com/gentoo-portage" USE="x86 X alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cscope cups eds emboss encode esd exif expat fam foomaticdb fortran gd gdbm gif glut gnome gpm gstreamer gtk gtk2 idn imlib ipv6 java jpeg kde lcms libg++ libwww mad mikmod mng motif mp3 mpeg mysql ncurses nls ogg opengl oss pam pcre pdflib perl png python qt quicktime readline samba sdl spell ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
The line in modules-update that runs depmod passes "-F /usr/src/linux/System.map" as an argument in order to check for unresolved symbols in the module files. Because this script is run before localmount it will fail to find this file if your /usr is on a separate partition. I worked around it by mounting a second copy of my root partition in a temporary location and copying my System.map file to the appropriate point. I'm not sure what can be done as a permanent fix, however, because I suspect that modules needs to run before localmount in case modules need to be loaded to mount the extra partitions.
this has probably been resolved in baselayout-1.12.x
I think you will find that changing if [ -f /usr/src/linux/System.map ]; then depmod -a -F /boot/System.map ${KV} else ewarn "System.map not found - unable to check symbols" fi to if [ -f /boot/System.map ]; then depmod -a -F /boot/System.map ${KV} else ewarn "System.map not found - unable to check symbols" fi Fixes the problem. It seems logical to me, the system map is installed in the /boot partition, which will always be mounted.
(In reply to comment #3) > > Fixes the problem. It seems logical to me, the system map is installed in the > /boot partition, which will always be mounted. > Actually, no. If you follow the default gentoo partition scheme, /boot will not be mounted when modules-update runs. On my PC, it's never mounted *at all* unless I'm installing a new kernel image.
/boot isnt not a viable option try using modules-update from baselayout-1.12.x
Unmasking and installing baselayout-1.12.0_pre15-r1 corrected the issue with modules-update causing /etc/init.d/modules to fail, but I do still see a message stating that modules.conf is more recent than modules.dep. I guess that I will consider the problem fixed once 1.12.0 or greater is considered to be stable.
*** This bug has been marked as a duplicate of 104288 ***
