Created attachment 34981 [details]
output of /proc/e820info from within anaconda

FYI,Here is the output of an rpm -qa | grep kernel:
(tigger /2) $ rpm -qa | grep kernel
kernel-smp-2.4.7-10
kernel-enterprise-2.4.7-10
kernel-headers-2.4.7-10
kernel-2.4.7-10
(tigger /2) $

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.

Created attachment 34984 [details]
cat /proc/e820info from Anaconda

Added msw 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.

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.

-- 
tzd.

We are looking into this.

I was also a victim of this problem.  My setup:
Duron 750MHz
Epox 8KTA3
512MB RAM
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.

I am not able to reproduce this on one of our Duron test boxes.  Can everybody
attach their upgrade.log files?

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.

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), giving 
this error message and the time and date of the error.

Created attachment 35561 [details]
upgrade.log from tomg

Created attachment 35562 [details]
Upgrade log from tdiehl. Per your request

Created attachment 35621 [details]
upgrade.log from Seawolf to Enigma

Bugzilla seems to have some brain damage lately when it comes to posting
attachments.

From looking at the upgrade.log files, XFree86 is pulling in kernel-smp and
kernel-enterprise.

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.

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?

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.

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?

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. 

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.

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
GRUB/LILO.

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.

*** Bug 55598 has been marked as a duplicate of this bug. ***

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.

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.

/proc/cpuinfo
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

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

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?

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.

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.

I've heard about this "screen freeze" elsewhere, too. Changing the "Resolution"
to "DEFERRED" instead of "WONTFIX" would look better. ;-)

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.

Understood.

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.

This should be better in 8.0 and later