On 13/07/2015 18:42, Alexander Kapshuk wrote: > On Mon, Jul 13, 2015 at 5:29 PM, Alan McKinnon <[email protected]> > wrote: >> Did a new install, the new kernel can't load modules: >> >> # modprobe nfsv3 >> modprobe: ERROR: could not insert 'nfsv3': Exec format error >> >> Odd. Never had this before. The module file itself is a regular 64-bit >> ELF file, just as it should be (compared to a working module on another >> machine) >> >> gcc is 4.8.4 as supplied by a recent stage3-amd64-20150709.tar.bz2: >> # gcc -v >> Using built-in specs. >> COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4/gcc >> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.4/lto-wrapper >> Target: x86_64-pc-linux-gnu >> Configured with: >> /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/configure >> --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr >> --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4 >> --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/include >> --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.4 >> --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.4/man >> --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.4/info >> --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/include/g++-v4 >> --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.4/python >> --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt >> --disable-werror --with-system-zlib --enable-nls >> --without-included-gettext --enable-checking=release >> --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.4 >> p1.6, pie-0.6.1' --enable-libstdcxx-time --enable-shared >> --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu >> --enable-multilib --with-multilib-list=m32,m64 --disable-altivec >> --disable-fixed-point --enable-targets=all --disable-libgcj >> --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto >> --without-cloog --enable-libsanitizer >> Thread model: posix >> gcc version 4.8.4 (Gentoo 4.8.4 p1.6, pie-0.6.1) >> >> make.conf seems correct: >> CHOST="x86_64-pc-linux-gnu" >> CFLAGS="-march=native -O2 -pipe" >> CXXFLAGS="${CFLAGS}" >> ACCEPT_KEYWORDS="~amd64" >> >> The kernel loads and runs OK: >> # uname -a >> Linux download 4.1.2-gentoo #1 SMP Mon Jul 13 13:28:40 SAST 2015 x86_64 >> Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz GenuineIntel GNU/Linux >> >> and the kernel was built with gcc auto-detection: >> # grep NATIVE /boot/config-4.1.2-gentoo >> CONFIG_MNATIVE=y >> >> and the .config was grabbed from a working machine with very similar >> hardware (one minor hardware upgrade ahead) >> >> I haven't done a full world update yet, most code is still what's in the >> stage3, but always in the past that hasn't been a problem; the stage >> must successfully build a kernel and load the modules. >> >> Module loading works just fine when booted from the Gentoo minimal >> install image. >> >> So, what dumbass n00b error did I make today? >> >> >> -- >> Alan McKinnon >> [email protected] >> >> > > Does 'modprobe -nv' say anything useful? > > Anything of interest in '/var/log/dmesg'? >
I hang my head in shame (and not for the first time either....) /boot in fstab had option "noauto", so all my kernels were installed to the / volume. The real /boot volume had a valid kernel on it, from the initial install with the minimal CD, and the .config was made with localyesconfig. It was a perfectly valid working kernel, that just happened to NOT match /lib/modules anymore.... Fixing fstab, a few "make install && make modules_install" lus a grub-install just for fun fixed the whole lot. Sorry for the noise.... -- Alan McKinnon [email protected]
