when performing a new system install using a Stage 3 tarball, I have encountered problems where the kernel does not correctly install itself. More specfically, when upgrading from gentoo-sources-2.6.11-r4 to 2.6.11-r6, I've copied the .config files to the new kernel directory. I verified the configuration settings using "make menuconfig", and exited, saving my changes. Then I built the kernel using the following command: # make && make modules modules_install install the kernel compiles properly, but it failed on the first attempt to install itself in /boot. needless to say, subsequent attempts at booting into the new kernel failed, because the script had failed to install the new kernel on the boot volume. reissuing the exact same kernel building command a second time resulted in proper installation of the kernel. it appears that the install portion of the script is intermittently failing to actually perform the install of the newly built kernel onto the /boot volume. Reproducible: Sometimes Steps to Reproduce: 1. emerge gentoo-sources 2. make && make modules modules_install install 3. examine contents of /boot Actual Results: sometimes the kernel is installed, sometimes it is not. :( Expected Results: kernel should be both compiled and installed gentoo / # emerge --info Gentoo Base System version 1.4.16 Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Pentium III (Coppermine) Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Apr 23 2005, 01:56:54)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-mmx -mtune=pentium-mmx -pipe -O2 -fweb -frename-registers -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium-mmx -mtune=pentium-mmx -pipe -O2 -fweb -frename-registers -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi berkdb bitmap-fonts crypt cups emboss encode foomaticdb fortran gdbm gif gnome gpm gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl svga tcpd truetype truetype-fonts type1-fonts xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
just to clarify: i have encountered this problem twice in two days with the 2.6.11-r6 kernel: 1) when upgrading an existing system and upgrading the kernel from 2.6.11-r4 to 2.6.11-r6. this is the system that is referenced in the output of "emerge --info" above. 2) when installing Gentoo de novo (on a blank system) using a Stage 3 tarball and emerging the current version of gentoo-sources from the portage tree (2.6.11-r6).
Are you sure you had correctly mounted you /boot partition (if any) before you "make install". The correct procedure to build a 2.6 kernel is: make menuconfig make make modules_install If using an existing config file is like this: cd /usr/src cp old-kernel-dir/.conf linux/ make oldconfig make make modules_install Have you done this by this steps?
We generally don't use the "make install" part of the kernel build system - did some Gentoo docs mention this, or did you pick this up from somewhere else? Copying over the image manually should be fail-safe :)
yes Carlos, i had the foresight to assure that my /boot partition was properly mounted, but thanks for thinking of that in your approach of a differential diagnosis of the problem. i am quite confident that the problem was not attributable to operator error -- especially when the issuance of the command on a second occasion resulted in a successful install when the first one did not. fwiw, i have always used "make install" when performing Gentoo installations, and i have never experienced such failures in the past. when it happened to me yesterday, i had thought that this problem was a fluke and I had no intention of reporting it... that is, until I had some of my Stage 1/3 Install Guide users and Jackass! Project testers send PMs to me commenting about this exact problem when emerging 2.6.11-r6. given that other people have been experiencing the problem, i thought it bugworthy. DSD, to answer your question, i have been using "make install" quite successfully with Gentoo for an awful long time. i don't actually know if i've actually read it in one of the Gentoo docs, but i can confirm with absolute certainty that THOUSANDS of Gentoo users have been using the "make install" command when following the Gentoo Docs that I have authored -- the Stage 1/3 Installation Guides. i sincerely hope that the comment "We generally don't use the "make install" part of the kernel build system" was not meant to imply that "make install" is unsupported in Gentoo.
Well, I've never used it, so I'm not exactly sure what it does. But if you are confident that the problem has been introduced in 2.6.11 and is a generally reliable install method, then thats ok, but we can't really do anything unless you are more specific as to why it doesnt work. Attaching a log of "make install" output would be a starting point.
thanks. does the system normally keep a log of the output of "make install"? if so, i could look for it on the boxes that have had the problem occur -- that is, if the log isn't overwritten by the subsequent kernel build instead of being appended by it. so if you could point me to the location of the log file, i could check on this. thanks.
No, there are no logs. I'm just interested in seeing the output of a bad "make install" compared to the output of a successful "make install". The output of "ls /boot" before and after a failed install would also be useful. It would also help if you could clarify the "failure" - I notice that it installs several files to /boot - are none of them there? Which is the file that you are trying to boot or expecting to boot from?
when a make install failure occurs, none of the files that are expected to be installed appear to actually be installed on the boot volume. the kernel that i am expecting to boot from following the make install command in this case is named vmlinuz-2.6.11-gentoo-r6. the following files are normally copied to the boot volume during a successful install. this is the output of "ls -lht" from my /boot volume: lrwxrwxrwx 1 root root 27 Apr 29 12:51 System.map -> System.map-2.6.11-gentoo-r6 -rw-r--r-- 1 root root 931K Apr 29 12:51 System.map-2.6.11-gentoo-r6 lrwxrwxrwx 1 root root 31 Apr 29 12:51 System.map.old -> System.map-2.6.11-gentoo-r6.old lrwxrwxrwx 1 root root 23 Apr 29 12:51 config -> config-2.6.11-gentoo-r6 -rw-r--r-- 1 root root 28K Apr 29 12:51 config-2.6.11-gentoo-r6 lrwxrwxrwx 1 root root 27 Apr 29 12:51 config.old -> config-2.6.11-gentoo-r6.old lrwxrwxrwx 1 root root 24 Apr 29 12:51 vmlinuz -> vmlinuz-2.6.11-gentoo-r6 -rw-r--r-- 1 root root 1.9M Apr 29 12:51 vmlinuz-2.6.11-gentoo-r6 lrwxrwxrwx 1 root root 28 Apr 29 12:51 vmlinuz.old -> vmlinuz-2.6.11-gentoo-r6.old -rw-r--r-- 1 root root 930K Apr 29 12:25 System.map-2.6.11-gentoo-r6.old -rw-r--r-- 1 root root 28K Apr 29 12:25 config-2.6.11-gentoo-r6.old -rw-r--r-- 1 root root 1.9M Apr 29 12:25 vmlinuz-2.6.11-gentoo-r6.old as you can see, some of them are backups of the previous versions which are backed-up with the .old file extension. i do not have a screen capture of the output from a failed kernel installation. to my recollection, it was the same as the screen output from a successful kernel installation, and there was no warning that something had gone awry. i will try a few kernel compiles and installs to see if i can duplicate the problem, and if so i will post screen output that contrasts a successful and an unsuccessful install. thanks.
Do you have /sbin/installkernel ? If so, which package owns it? # emerge -n gentoolkit ; equery belongs /sbin/installkernel Have a look at when that package was last upgraded. # emerge -n genlop ; genlop <that-package>
see comment #4
