Bug 55068
|
Description
Tom Diehl
2001-10-25 03:28:07 UTC
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 |