From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en]C-AtHome0407 (WinNT; U)
Description of problem:
Internal error reported during "Finding packages to upgrade..." when attempting to Upgrade from 6.2 to 7.1
A debug file was saved to floppy.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install/Upgrade from 6.2 to 7.1 using CDROM source (from ISO images - checksum verified)
2.Select english, english keyboard
Actual Results: Internal Error occurs during "Finding Packages to Upgrade"
Expected Results: No internal error...
Traceback (innermost last):
File "/usr/bin/anaconda", line 520, in ?
intf.run(todo, test = test)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 1126, in run
rc = apply (step(), args)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/textw/upgrade_text.py", line 33, in __call__
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1277, in upgradeFindPackages
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/comps.py", line 116, in __getitem__
Local variables in innermost frame:
self: <comps.HeaderListFromFile instance at 8271208>
Created attachment 28417 [details]
anaconda save file following internall error
where did you get your install media?
I downloaded the ISO images for CD-ROMS on 24Jun01 from Redhat ftp.
I verified the checksums after downloading the images.
try booting with "linux ide=nodma" at the boot: prompt
Created attachment 29094 [details]
anaconda dump file - internal error
As requested, tried booting with "linux ide=nodma" at the boot: prompt.
Looks to me like same error, at same point in "Finding", with same dump file from anaconda...
What does the dump file indicate?
it's quite odd. We get a list of all the package headers available during the
upgrade and pass that list to a function that determines which packages it
should upgrade. The funcion passes a list back and we go and turn on each
package in the list. So the list we passed in should include the kernel-smp
package, the upgrader decides it should upgrade to it, then we go and turn it on
in the package selection state. This is the point where it fails, because it
seems that the package isn't in the header list after all.
This is a very puzzling bug.
When the installer crashes, can you press <Ctrl><Alt><F4> and see if there are
any interesting error messages?
Sorry, but I got past the bug already by removing the kernel-smp package. Apparently (according to the Gnome rpm query response) it's only
needed for multi-processor systems and I only have 1 cpu. Once I removed that package, the install continued and completed successfully. There
were 438 packages to update (for a total of 1071MBytes) without the kernel-smp package.
However, it seems that there are many changes (upgrading from 6.2 to 7.1) and I'm still working to get everything (network related?) running again
(eth1, telnet, ftp, samba, dns, ipchains, IP masquerading, etc. ). Seems the change from inetd to xinetd has a lot of config-related changes that
need manual intervention. Guess that's progress...
I suppose this bug should be 'closed' - but it was merely side-stepped instead of fixed. Perhaps make a FAQ and indicate the work-around of
removing the kernel-smp package to complete the install. I imagine there's still an anaconda problem lurking somewhere that caused this bug to
appear in my situation, but it no longer stands in my way.