Bug 160618 - Installer crashes during Post Install
Installer crashes during Post Install
Status: CLOSED DUPLICATE of bug 139146
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
: 160542 161024 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-16 00:56 EDT by darkfrog
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-04 11:56:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Traceback (most recent call last): (1.31 MB, text/plain)
2005-06-18 14:07 EDT, KUTILEK Martin
no flags Details
Chris C anaconda dump (155.76 KB, application/x-zip-compressed)
2005-06-20 15:08 EDT, Chris C.
no flags Details
Chris C - anaconda dump "linux ide=nodma" (158.20 KB, application/x-zip-compressed)
2005-06-20 17:03 EDT, Chris C.
no flags Details
anaconda dump (1.39 MB, text/plain)
2006-01-02 19:54 EST, Josh
no flags Details

  None (edit)
Description darkfrog 2005-06-16 00:56:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
When I do an installation of Fedora Core 3 or 4 on this specific machine (it's somewhat older, but other flavors install fine) everything completes successfully but at the end of the installation during Post Install it throws an exception:

Traceback (most recent call last):
File "/usr/lib/anaconda/gui.py", line 1137, in handleRenderCallback
  self.currentWindow.renderCallback()
File "/usr/lib/anaconda/iw/progress_gui.py", line 244, in renderCallback
  self.intf.icw.nextClicked()
File "/usr/lib/anaconda/gui.py", line 873, in nextClicked
  self.dispatch.gotoNext()
File "/usr/lib/anaconda/dispatch.py", line 174, in gotoNext
  self.moveStep()
File "/usr/lib/anaconda/dispatch.py", line 242, in moveStep
  rc = apply(func, self.bindArgs(args))
File "/usr/lib/anaconda/packages.py", line 1204, in doPostInstall
  stdout = devnull)
File "/usr/lib/anaconda/iutil.py", line 53, in execWithRedirect
  raise RuntimeError, command + " can not be run"
RuntimeError: /usr/sbin/kudzu can not be run

Version-Release number of selected component (if applicable):
Fedora Core 3 and 4 (release)

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora Core 3 or 4 from CDs (from ISO images) - images work on other machines without problems
2. Any installation of packages will reproduce this, but I am trying to do a mimimalistic installation.
3. Installation runs through without any problems until the Post Install process and then it throws the Exception mentioned in "Description"
  

Actual Results:  The Exception mentioned in "Description" - I then lose mouse support, but am able to scroll through the information with my keyboard. If I go to "Debug" the monitor goes to standbye mode and essentially is dead.

When I reboot the machine I get the LILO screen, but am not proficient enough with LILO to manually configure it.

Expected Results:  ...installation was a success? :-p

Additional info:

I have tried changine memory out, changing CDROM drives, video card, etc.  The only things that have remained consistently has been the motherboard and hardrive.

I was hoping that Fedora Core 4 would have addressed this issue, but apparently not.  I have confirmed that the CDs are good and work on other machines. I know it's a hardware issue that is causing this, I'm just not sure exactly what it is or the work-around.

Specifications:
-----------------
Hardrive - 40gig IDE Western Digital
Motherboard - P4VXASD with an Intel P4 1.4GHz CPU
Memory - 384MB (in two chips - swapped between the two without any change)
Video - RIVA128 (also tried with a Creative Labs CT6610)
Keyboard - Microsoft Ergonomic Keyboard
Mouse - Microsoft IntelliMouse Explorer Wireless
Comment 1 Jeremy Katz 2005-06-16 16:23:10 EDT
Can you verify your media according to
http://rhlinux.redhat.com/anaconda/mediacheck.html? 

Also, could you provide the full traceback?
Comment 2 darkfrog 2005-06-16 23:55:49 EDT
I just completed the media verification and there were no problems.

As for the full traceback I'm not sure how to get that. As I mentioned
previously, the Exception kills mouse support and even though I can tab down to
"Debug" when I hit Enter on it the screen goes blank and the system is locked. I
have tried to boot to the hard drive afterwards and it goes to LILO and I hit
enter and it starts to load but then locks up there as well.

I would typically think these were just systems of a hardware problem, but I had
been running SuSE 9.2 on this machine without any trouble at all for a long time
before I decided to switch it to FC.
Comment 3 KUTILEK Martin 2005-06-18 14:07:13 EDT
Created attachment 115656 [details]
Traceback (most recent call last):

This is the result of the debug button after the crash in fc4
Comment 4 darkfrog 2005-06-18 14:20:50 EDT
I can't get that information since hitting the Debug button makes the screen go
blank and the machine locks.
Comment 5 Chris C. 2005-06-18 15:10:40 EDT
I've obtained the same error with the same symptoms. The computer similar, with 
PIV 1.4GHz and P4VXASD motherbord with the latest possible update of BIOS. The 
same message as error description. I suffered the same problem with FC3.
Solution for FC3 is described in bug #139146. The given solution is exchange 
the microcode at the beginning of instalation process in text console (Ctr-Alt-
F2) in the background of installation performed by anaconda.
I'm trying to repeat this procedure, but I'm still receving errors.
First of all, I've extracted files microcode.ko, microcode.dat and 
microcode_ctl files from original rpms from FC4.
I'm trying to use script from bug 3139146 (named just "m").
The script is:

#!/bin/sh
insmod microcode.ko
rm -rf /dev/cpu
mkdir /dev/cpu
mknod /dev/cpu/microcode c 10 184
./microcode_ctl -f microcode.dat
dmesg | tail

I've checked the number of device in mknod - is correct (LINUX ALLOCATED DEVICES
, Maintained by Torben Mathiasen <device@lanana.org> Last revised: 05 April 
2005, ftp://ftp.kernel.org/pub/linux/docs/device-list/devices.txt) - character 
device, major code 10, minor code 184.
I executed commands from the above script line by line in console.
After command "./microcode_ctl -f microcode.dat" I've obtained message, that 
device does not exist and cannot be written (or something similar).
So, I think, that the main problem may be microcode update. Do you have any 
idea how to perform that or what I'm doing incorrectly?
Comment 6 Chris C. 2005-06-18 15:13:17 EDT
Ecxuse me, script "m" is from bug #139146, of course.
Comment 7 Chris C. 2005-06-18 16:56:14 EDT
I've just discovered that I have problem earlier - with loading microcode.ko 
module. No insmod or modprobe can load this module. It is not on list after 
lsmod. Any idea?
Comment 8 Victor Engmark 2005-06-19 11:14:10 EDT
I've had a similar problem with my installation of FC4. Checked the SHA1 in
Windows, started in graphical mode with the automated check just to be sure,
selected English / Dvorak, selected workstation installation on hdb1
(overwriting a FreeBSD 5.4 installation), got an error message after selecting
automated partitioning (sth about being unable to proceed), worked around this
by deleting the hdb1 partitions and selecting automated install again, and
proceeded to the "Ready to install" screen. When pressing continue, I got the
same message as in the original post, except the last line started as follows:
"error: Error: Error informing the kernel about modifications to partition
/dev/hdb2 - Device or resource busy. This means Linux won't know about any[...]"

Sorry for the vague description, but I've been unable to reproduce this error.

My system is an AMD Athlon XP 1600+ w/1GB RAM on nVidia nForce2 motherboard.

I did not have the same problem when installing FC3 on the same configuration
(except Norwegian kbd layout) when that was new.
Comment 9 Chris Lumens 2005-06-20 11:41:10 EDT
If you're getting the traceback on failing to run kudzu, please attach the
/tmp/anacdump.txt file.
Comment 10 Chris C. 2005-06-20 15:08:47 EDT
Created attachment 115711 [details]
Chris C anaconda dump

Here is my anaconda dump created after the error in instalation process
(written on floppy i the last visible window).
Comment 11 Chris Lumens 2005-06-20 15:24:55 EDT
Chris C. - please try booting with "linux ide=nodma" and see if the problem
continues to occur.  As you can see in your anacdump.txt, something else is
going wrong here and it's most likely that almost no packages are being installed:

error: db4 error(-30977) from db->cursor: DB_RUNRECOVERY: Fatal error, run
database recovery
Comment 12 Chris Lumens 2005-06-20 15:27:29 EDT
*** Bug 160542 has been marked as a duplicate of this bug. ***
Comment 13 Chris Lumens 2005-06-20 15:29:34 EDT
*** Bug 161024 has been marked as a duplicate of this bug. ***
Comment 14 Chris C. 2005-06-20 17:03:46 EDT
Created attachment 115719 [details]
Chris C - anaconda dump "linux ide=nodma"

Here is my dump for "linux ide=nodma". Instalation finishes as in previous.
Comment 15 Chris C. 2005-08-14 08:58:31 EDT
The problem is still open for me. Do you have any idea?
Comment 16 Sathya 2005-10-17 06:29:06 EDT
I am getting the exact same error when installing FC4. I had Windows XP and 
wanted to Dual boot. Now I am left with nothing. It will boot into GRUB and 
then nothing. I have tried installing atleast 8-10 times this weekend.
Please help!!!
Comment 17 Josh 2006-01-02 19:54:43 EST
Created attachment 122702 [details]
anaconda dump

I'm having the same issue and have attached my dump file.  I've tried to
install a couple times, including a minimal install attempt, all with the same
result.  I haven't tried an ide=nodma, but I'll try that next.
Comment 18 Chris Lumens 2006-01-04 11:56:34 EST

*** This bug has been marked as a duplicate of 139146 ***

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