Bug 55068 - anaconda installed the incorrect kernel
Summary: anaconda installed the incorrect kernel
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.2
Hardware: athlon Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
: 55598 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-25 03:28 UTC by Tom Diehl
Modified: 2007-04-18 16:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-12 17:25:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of /proc/e820info from within anaconda (326 bytes, text/plain)
2001-10-25 03:33 UTC, Tom Diehl
no flags Details
cat /proc/e820info from Anaconda (326 bytes, text/plain)
2001-10-25 05:29 UTC, Michael Schwendt
no flags Details
Upgrade log per your request (deleted)
2001-10-29 21:56 UTC, Tom Diehl
no flags Details
Upgrade log per your request (deleted)
2001-10-29 21:56 UTC, Tom Diehl
no flags Details
Upgrade log per your request (deleted)
2001-10-29 21:57 UTC, Tom Diehl
no flags Details
Upgrade log per your request (deleted)
2001-10-29 22:46 UTC, Tom Diehl
no flags Details
upgrade.log file from tomg@io.com (deleted)
2001-10-29 23:09 UTC, tom georgoulias
no flags Details
upgrade.log file from tomg@io.com (deleted)
2001-10-29 23:10 UTC, tom georgoulias
no flags Details
upgrade.log from tomg@io.com (35.49 KB, text/plain)
2001-10-30 02:43 UTC, tom georgoulias
no flags Details
Upgrade log from tdiehl@rogueing.com. Per your request (36.82 KB, text/plain)
2001-10-30 02:59 UTC, Tom Diehl
no flags Details
upgrade.log from Seawolf to Enigma (36.39 KB, text/plain)
2001-10-30 07:11 UTC, Michael Schwendt
no flags Details

Description Tom Diehl 2001-10-25 03:28:07 UTC
Description of Problem:Upon upgrading my athlon system with 512 Megs of 
memory anaconda installed the enterprise and smp kernel. this was an 
upgrade from 7.1 to 7.2

Version-Release number of selected component (if applicable):

How Reproducible:Do not know. Can only do the upgrade once.

Steps to Reproduce:
1. Upgrade an athlon machine from 7.1 to 7.2

Actual Results:

Expected Results:

Additional Information:

Comment 1 Tom Diehl 2001-10-25 03:33:32 UTC
Created attachment 34981 [details]
output of /proc/e820info from within anaconda

Comment 2 Tom Diehl 2001-10-25 03:38:20 UTC
FYI,Here is the output of an rpm -qa | grep kernel:
(tigger /2) $ rpm -qa | grep kernel
(tigger /2) $

Comment 3 Michael Schwendt 2001-10-25 05:28:33 UTC
Same here with a Duron and less memory during upgrade from Seawolf to Enigma. I
was surprised to get kernel-enterprise-2.4.7-10 as default GRUB entry and the
other kernels installed, too:

Could this be due to "kernel-drm" dependency confusion? From /tmp/upgrade_log:

Upgrade Dependency: XFree86 needs kernel-enterprise, automatically added.
Upgrade Dependency: XFree86 needs kernel-smp, automatically added.
Upgrade Dependency: XFree86 needs kernel, automatically added.
Upgrading kernel-enterprise.
Upgrading kernel-smp.
Upgrading kernel.

Comment 4 Michael Schwendt 2001-10-25 05:29:40 UTC
Created attachment 34984 [details]
cat /proc/e820info from Anaconda

Comment 5 Tom Diehl 2001-10-26 14:36:42 UTC
Added msw@redhat.com to the cc list since he asked me to file this bug. Also I 
have upgraded a amd k62-300 with 129 Megs of memory in it and anaconda 
installed the smp kernel. It would not even boot the thing. It hung when the 
system went to run level 3. Changing to the standard kernel fixed it. Do you 
want the /proc/i810e info on it? Actually Out of the 5 machines I upgraded 
here the only one that it got right is the p133 I use for a firewall. the 
others are all amd something or others and it either installed the enterprise 
kernel or the smp kernel.

Comment 6 Tan Zheng Da 2001-10-28 14:26:38 UTC
I experienced something similar here.  My box is a Pentium classic 166, with an
Adaptec AIC-7850 SCSI card and 3Ware Escalade card.  I did the upgrade from 7.1
to 7.2, using the updates disk to address the 3ware issue.  My 7.1 was
previously updated to the 2.4.9 Red Hat kernel.  I chose to retain LILO instead
of using GRUB.

After the update, Red Hat 7.2's 2.4.7-SMP kernel was installed as the default
although it installed the UP version as well.  

Upon boot up, the system hangs when the drivers for the Adaptec SCSI card is
loading.  Works when I rebooted to the UP kernel, and also works after I updated
it to the Red Hat 2.4.9 UP kernel.


Comment 7 Brent Fox 2001-10-28 15:17:29 UTC
We are looking into this.

Comment 8 tom georgoulias 2001-10-29 14:55:58 UTC
I was also a victim of this problem.  My setup:
Duron 750MHz
Epox 8KTA3
stock 7.1 with all updates applied.

During my upgrade Anaconda installed 3 kernels (std Athlon, SMP, and Enterprise
versions).  The Athlon version wouldn't boot, so I used the Enterprise one to
boot up, replaced the Athlon kernel with an i686 one, and removed the SMP and
Enterprise versions.  Everything seemed to be OK, so I used up2date to grab the
2.4.9-7 i686 RPM and installed that.  My system is functioning normally so far.

Other details:  I opted to replace Lilo with GRUB.  Prior to the upgrade, I was
using the 2.4.9-6 i686 kernel on 7.1.

Comment 9 Brent Fox 2001-10-29 21:08:11 UTC
I am not able to reproduce this on one of our Duron test boxes.  Can everybody
attach their upgrade.log files?

Comment 10 Tom Diehl 2001-10-29 22:52:48 UTC
I do not know what is going on but everytime I try to send the attachment I 
get some some kind of oracle database error. Let me know where you want me to 
send the attachment.

Comment 11 tom georgoulias 2001-10-29 23:14:25 UTC
I got this error message while uploading my upgrade.log file.  Sorry for the
duplicate, empty attachments.  I did email this to the bugzilla account.
Content-type: text/html
Software error:
DBD::Oracle::st execute failed: ORA-01691: unable to extend lob segment 
BUGZILLA.SYS_LOB0000003839C00008$$ by 972 in tablespace ENG_DATA02 (DBD 
ERROR: OCILobTrim/OCILobWrite/LOB refetch) at 
/var/www/bugzilla/bugzilla/createattachment.cgi line 124.

For help, please send mail to the webmaster (bugzilla@redhat.com), giving 
this error message and the time and date of the error.

Comment 12 tom georgoulias 2001-10-30 02:43:28 UTC
Created attachment 35561 [details]
upgrade.log from tomg@io.com

Comment 13 Tom Diehl 2001-10-30 02:59:08 UTC
Created attachment 35562 [details]
Upgrade log from tdiehl@rogueing.com. Per your request

Comment 14 Michael Schwendt 2001-10-30 07:11:34 UTC
Created attachment 35621 [details]
upgrade.log from Seawolf to Enigma

Comment 15 Brent Fox 2001-10-30 19:02:33 UTC
Bugzilla seems to have some brain damage lately when it comes to posting

Comment 16 Brent Fox 2001-10-30 19:09:17 UTC
From looking at the upgrade.log files, XFree86 is pulling in kernel-smp and

Comment 17 Brent Fox 2001-10-30 19:11:26 UTC
I could not reproduce the problem because I did a minimal 7.1 install and then
upgraded that to 7.2.  That means that I didn't install XFree86 and therefore
didn't run into this situation.

Comment 18 Brent Fox 2001-10-31 05:30:51 UTC
I did a 7.1 install with XFree86 and then upgraded to 7.2, but I was still
unable to reproduce this behavior.  Now I'm confused.  Did any of you update
your XFree RPM from what 7.1 installed?

Comment 19 Tom Diehl 2001-10-31 05:36:12 UTC
I was using a stock 7.1 install with redhat updates if any. I do not recall if 
there was any for XFree86 but I do not recall any.

Comment 20 Michael Schwendt 2001-10-31 08:04:03 UTC
My comment from 2001-10-25 01:28:33 referred to upgrade.log already where
XFree86 was listed as responsible for pulling in the kernel packages.

My system was a completely updated Seawolf, including the most recent kernel
2.4.9-6 updates. XFree86 was the original 4.0.3-* one. Only temporarily I had
tested a special XFree86 version from Mike Harris, but have always replaced
those packages again.
There is a minor chance that I haven't had a kernel rpm installed (not even a
backup kernel rpm), but only my own custom kernels.

What would happen if you "rpm -e --nodeps" the kernel rpm on Seawolf and then
upgraded to Enigma? Would this be enough for XFree86 to pull in _all_ kernel
packages to satisfy kernel-drm dependency?

Comment 21 Tom Diehl 2001-10-31 13:46:22 UTC
Hummm since Michael brought up installed kernel info I thought it might be 
significant that I too was using custom kernels. Although I left the stock 
redhat kernel for 7.1 in place I had built and installed custom kernel rpms 
the latest of which was based on 2.4.10-ac12. At the time of the upgrade there 
were several of these kernels installed all of which were of a later version 
then what redhat was providing with 7.2. Interestingly enough after the 
upgrade I noticed that anaconda had rm'd all of my custom kernels from the 
system even though they were of a later version than what anaconda installed. 

Comment 22 tom georgoulias 2001-11-01 03:38:52 UTC
I have not upgraded XFree86 outside of any standard RH errata updates.  The 7.1
system I was using before the 7.2 upgrade had all of the updates applied and thy
only non-Red Hat RPMs that relate to XF86 are the Nvidia proprietary drivers I
use.  If I recall correctly, I had both the 2.4.3-12 and 2.4.9-6 kernels
installed when I upgraded to 7.2.  Let me know if you want more info from me and
I'll be glad to help.

Comment 23 Michael Schwendt 2001-11-01 08:22:47 UTC
Well, I can only guess what _could_ have been special about my installation. I
usually keep the latest Red Hat i686 kernel package installed to satisfy
dependencies (such as kernel-drm) and to use it as a backup kernel entry in

But due to ext3 conversion, there is a minor chance that I haven't had a kernel
rpm installed (not even 2.4.9-6 as a backup kernel), but only my own custom K7
kernels. If the upgrade.log contained "rpm -qa" that would help.

Comment 24 Brent Fox 2001-11-08 16:38:32 UTC
*** Bug 55598 has been marked as a duplicate of this bug. ***

Comment 25 Need Real Name 2001-11-09 19:18:01 UTC
Confirming that this also happened to me during an upgrade from 7.1 to 7.2.  The
system in question is a Dell Latitude c800, 1 GHz Intell Pentium III
(coppermine).  RH7.1 was on this sytem for only a few days before the upgrade,
and I believe it had the original 7.1 kernel plus the current update kernel. 
During the upgrade to 7.2, Anaconda installed 3 versions of the 7.2 stock i696
kernel:  UP, SMP and Enterprise.

Comment 26 kitchen_506 2001-12-26 21:27:07 UTC
Similar problems upgrading from 7.1 + ximian to 7.2; replicated problem on a
full install of 7.2.  Don't know what the kernel was that was installed on the
update since I reimaged with a full install, but the old kernel on the full
install was the athlon kernel and the duron chip apparently didn't like it.

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 3
model name      : AMD Duron(tm) Processor
stepping        : 1
cpu MHz         : 800.058
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 1595.80

Comment 27 Jeremy Katz 2002-04-04 20:51:03 UTC
If you don't have any kernel packages installed, then we install everything that
can resolve the dependency to be safe.  That's the only way that I can replicate
this behavior, and unfortunately in that case, there's very little we can do
within the upgrade to get a better idea of what properly resolves the dependencies

Comment 28 Tom Diehl 2002-04-04 21:54:50 UTC
I think you are missing the point. This is an athlon machine and the athlon kernel was NOT even installed. Had it been I would have never opened this 
bug. If you are going to make anaconda install ALL of the kernels then install ALL of the kernels not just the intel ones. How hard would it be to do 
a cat /proc/cpuinfo and grep for athlon during the install. If it returns a zero exit code install the athlon kernel in addition to whatever other 
kernels you want. Baring that why not have an option to choose what kernel you want installed. Make it an expert mode choice if you like but it 
should be a choice none the less. What am I missing?

Comment 29 Jeremy Katz 2002-04-04 22:06:52 UTC
You're missing the fact that upgrades are handled by lots of really scary code
in RPM that is almost guaranteed to break if it changes, especially this late in
a release cycle.  On installs, we actually do install the athlon kernels but
upgrades are a slew of special cases, unfortunately.  Additional screens aren't
possible because we're past screen and translation freeze dates.

Comment 30 Michael Schwendt 2002-04-04 22:11:47 UTC
I must admit, I'm surprised by this resolution, too. There ought to be a much
more elegant "fix" to this problem, especially since custom kernels are not
uncommon. Installing an SMP kernel on a single processor system doesn't look
good either.

Grep'ping /proc/cpuinfo for Athlon would not work for Duron. But the user could
be prompted at least if no kernel rpm was installed and detecting the CPU type
didn't work and /boot/kernel.h couldn't be used either.

Comment 31 Michael Schwendt 2002-04-04 22:13:47 UTC
I've heard about this "screen freeze" elsewhere, too. Changing the "Resolution"
to "DEFERRED" instead of "WONTFIX" would look better. ;-)

Comment 32 Jeremy Katz 2002-04-04 22:23:37 UTC
Ah, but upgrading from a system without any Red Hat Linux kernels installed is
distinctly not in something that is overly supported.  I'll defer it, but it's
still not going to be high on the priority list in the scheme of things.

Comment 33 Michael Schwendt 2002-04-04 22:57:43 UTC

The least you could do is let the doc writers document it somewhere as a caveat.
Sort of, that for a distribution upgrade to function flawlessly, a kernel
package for the right architecture must always be installed even if it is not used.

The kernel-drm dependency alone (and packages requiring the kernel package)
gives not enough reason to think that the kernel package is strictly required
and a custom kernel won't do it. Because a user who knows his custom kernel has
all the required features could think it would be okay to get rid of the stock
kernel. It is a trap that this confuses the upgrade installer. Since Red Hat
provides the kernel-source rpm for building custom kernels, this should at least
be documented.

Comment 34 Jeremy Katz 2003-03-12 17:25:04 UTC
This should be better in 8.0 and later

Note You need to log in before you can comment on or make changes to this bug.