Red Hat Bugzilla – Bug 119447
Anaconda can't find kudzu, aborts install.
Last modified: 2015-01-04 17:05:08 EST
Description of problem:
Anaconda gets all the way through the install past formatting
filesystems & setting up rpm database, and then tries to run
/usr/sbin/kudzu, which doesn't exist.
Created attachment 98970 [details]
screengrab of tty1 after the crash
Did it actually install any packages?
Can you save the attachment (if no floppy, scp /tmp/anacdump.txt from
iirc, tty2 was an bash prompt.
I'll go through an install again later to be sure.
Created attachment 98995 [details]
Created attachment 98996 [details]
Hmmm, is this reproducible with later trees? I thought that we had
the "cannot create transaction lock" thing fixed now.
This bug still seems to be present in the final release. My consoles
look exactly the same as the screenshots.
*** Bug 125805 has been marked as a duplicate of this bug. ***
Dave/Jeremy, I am able to reproduce this very easily by kickstarting
and setting up a partition set as follows:
part /boot --fstype ext3 --size 100 --asprimary
part swap --size 2048
part / --fstype ext3 --size 1 --grow
Note the size of 1 and --grow. If I bump up that size of 1 to say
10240, still use --grow, the kickstart is able to continue w/out
issues. This may be a red herring, but it is how I am able to
replicate every single time. Will post info about the hardware in a
This bug also happens on my system (Asus K8V Deluxe with 3ware card), but seems to be
solved in FC 3 Test 1.
Same problem/message on my 2 week old system. Trying to install
custom Fedora Core 2, with winXP already installed. After formatting
(and some other stuff I didn't catch, I'm a newbie so dunno what it
did) I get the following:
Traceback (most recent call last):
File "/usr/lib/anaconda/gui.py", line 1048, in handleRenderCallback
File "/usr/lib/anaconda/iw/progress_gui.py", line 242, in
File "/usr/lib/anaconda/gui.py", line 763, in nextClicked
File "/usr/lib/anaconda/dispatch.py", line 169, in gotoNext
File "/usr/lib/anaconda/dispatch.py", line 237, in moveStep
rc = apply(func, self.bindArgs(args))
File "/usr/lib/anaconda/packages.py", line 1127, 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
AMD Athlon 64 2800+
2x 512MB TwinMOS
200GB SATA Seagate Barracuda
Geforce 4 Ti4200
Forgot to mention: I downloaded a DVD iso, and the test before
installing passed. I've tried installing custom four times, all
produced the exact same result even though my package selection
weren't always the same.
This occurs for me on a Fedora Core 2 install.
I did *not* use the 'grow' partition information (I don't believe -- I
ended up using disk druid but used fixed-sized partitions for
everything except /home where it shouldn't have been installing
It gave this error when it started attempting to transfer the OS image
to the newly formatted drives.
I also tried reformatting and using the existing (already sized)
partitions on a second attempt at installing and it gave me the same
The CD's all passed the media test as well (not sure if that does an
MD5 sum of the CDs but I saw other threads with similar errors which
claimed that to be the problem so figured I'd mention it even though
it looked like they got farther in the install than I did).
I just went back and retried the install.
I left my harddrive partitioned as it had been and did the install in
All I did in the disk druid was set the mount points on the drive and
tell it to reformat. No size changing occured.
I also selected an 'basic' desktop install figuring that I can install
everything else I want later if I can get the darned thing up and running.
It went through the format and the RPM copying phases, and entered the
postinstall config phase and gave the same error.
There were no messages on any of the consoles about failing MD5s or
anything, nor anything else which might give me a clue as to what was
The system is an AMD-64 on a K8V SE Deluxe Motherboard with 1G of ram,
and 2 160 GB hard drives. I'm using a Liteon 8x DVD+-R/RW double
sided combo drive and using CD's obtained by Glenn Stone from Pogo (I
know this will mean something to Jesse, hence I mention it).
The drives are partitioned as follows
hda1 256MB /boot
hda2 4G swap
hda5 15G /
hda6 25G /usr
hda7 25G /var
hda8 10G /tmp
hda3 80G /home
hdc1 70G /data
hdc2 50G /data/music
hdc3 40G /data/games
I had quite a bit of fighting with Disk Druid the first time I tried
to set up the partitions because it didn't want to put my / partition
when I wanted it and kept trying to rearrange the partitions on hda to
suit it's whim (side gripe, whatever happened to fdisk/cfdisk and
letting users make this decision for themselves without the software
trying to second guess them and getting it wrong?? that's as bad as MS
:/ (and yes, RH8/9 did it too and I hated it then too)).
I know during that first install where I fought with Disk Druid, I did
end up tweaking with the sizes of partitions and such to try and get
them as I wanted.. Didn't *quite* manage it (I wanted hda3 to be / and
be right after swap on the disk) but got close enough as you see
above. So I would easily believe the 'size=1, grow' bit for that
install. It doesn't however explain why the second and third attempts
where I reused and reformatted the existing disk geography failed to work.
I'm pretty sure that the CD's are good (as I said in my previous post).
I'm hoping for an explanation and a workaround or at least other
things to try so that I can actually install my new machine and start
building it as replacement for my current slightly aging desktop.
Created attachment 103904 [details]
anacdump.txt from graffical install.
I got similar problems. On a Chaintech ZNF3-250, using a SATA drive.
Disk Druid finds the drive no prob. Seems to format it, at least I can find a
familiar layout on /mnt/sysimage in linux rescue after the crash.
Here is the anacdump.txt from the graffical attempt.
Created attachment 103905 [details]
anacdump.txt from text install.
it seems these two are similar enough that it probably is the same bug.
Hm, I mght have found a workaround.
Install FC2 32 bit. (might work with other versions as well.)
Boot on FC2 64 bit CD#1
Use the upgrade option. (Since this was a fresh in my case I went
ahead after the warning that this probably would not work.)
Upgrade went without a flaw as far as I can tell. Anyone got a
suggestion as to how I might test that I really got FC2 64 bit working
Forget that workaround.
Everything seems fine, untill I trie to install any 64 bil app, whitch
promptly tells me I'm running in 32 bit, sorry, no can do.
Has anyone actually found a work-around to this yet.
I am *completely* unwilling to install FC3 test 2 (FC3 test 1 was
installed on this exact same box as a test and it installed but then
core dumped -- expected (somewhat) with -test releases) on a
production machine which my home machine is.
The CDs I have all pass the media check.
I did not grow any partitions or anything (as Jesse implied might be
The process *CLAIMED* that it installed the RPMs but didn't actually
install squat and just dropped right into the post-configuration which
is where it didn't find kudzu (because it wasn't actually installed).
I need a way to install this. I find it very frustrating that this
sort of problem is in a 'release' branch.
I *REALLY* don't want to migrate to a distro other than Fedora Core
because I've been using Redhat since around redhat 3. Unfortunately,
right now that's looking like my *only* option! (and yes, I need/want
the 64 bit install which seems to be what this bug has to be related
to given the previous comment about installing FC2 32 bit and having
Someone please find a workaround to this, please.
Some more info.
The Core2 x86_32 installer works like a charm, no problem on the first
Core1 x86_64 does not recognise the SATA drives at all, so installing
Core1 and upgrading is not a viable workaround.
However, I tried to install FC2 x86_64 on my home system last night.
Almost same mobo, same chipset, same spec cpu, less memory. (And lower
Only difference of note is the disk's. This time it was a couple of
regular ATA drives. (Kind of in between some windoze partitions.)
This install went flawlessly on first attempt.
This raises the question, does this have something to do with the SATA
support in the install system? It seems that the SATA drives are
formated and set up properly, even the error logs are stored on the
disk's, and awailable from the recovery system after, but I guess
somewhere a file copy or somesuch is attempted before the SATA drives
are fully online.
A theory of a possible workaround.
-Attempt install, let it fail.
-Reboot on install CD.
-Enter recovery mode
-Remount / in rw mode (is this posible at all?)
-Import kudzu into the right folder
I have not attempted this routine. So use at your own risk.
Sounds like this is fixed in FC3 test...
*** Bug 123564 has been marked as a duplicate of this bug. ***
*** Bug 123692 has been marked as a duplicate of this bug. ***
*** Bug 123745 has been marked as a duplicate of this bug. ***
*** Bug 123840 has been marked as a duplicate of this bug. ***
*** Bug 124029 has been marked as a duplicate of this bug. ***
*** Bug 125198 has been marked as a duplicate of this bug. ***
*** Bug 125874 has been marked as a duplicate of this bug. ***
*** Bug 127128 has been marked as a duplicate of this bug. ***
*** Bug 128126 has been marked as a duplicate of this bug. ***
*** Bug 129332 has been marked as a duplicate of this bug. ***
*** Bug 130947 has been marked as a duplicate of this bug. ***
*** Bug 134996 has been marked as a duplicate of this bug. ***
*** Bug 136785 has been marked as a duplicate of this bug. ***
If you switch to tty2 and type fdisk -l you'll see + signs in the
output for the systems that don't install correctly. That means that
it's not a full block.
The system will install correctly if the partition use full blocks.
The SATA vs IDE thing is a red herring I think. I've seen both kinds
of systems fail.
My work around is to manually fdisk the system so that no + sign shows
up in the fdisk output. I've done this on 3 pretty different