Summary: | gentoo-sources-2.6.11-r6: Intermittent Install Failures | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bob <custom_basses> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bob
2005-04-29 09:16:11 UTC
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 |