|Summary:||Anaconda can't find kudzu, aborts install.|
|Product:||[Fedora] Fedora||Reporter:||Dave Jones <davej>|
|Component:||anaconda||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||2||CC:||bdwheele, cai_ljunggren, carmi-redhat-bugzilla, dag, don, freeman, henrik, internet, ja, jkeating, jtraub, karl, mail, mstyne, pfrields, Rainer.Koenig, sam_msn, shane_drinkwater, tim.corcoran, wolfnman2000, zphreak217|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-07 18:06:13 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Dave Jones 2004-03-30 16:46:10 UTC
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. Chaos ensues. How reproducible: Every time.
Comment 1 Dave Jones 2004-03-30 16:47:12 UTC
Created attachment 98970 [details] screengrab of tty1 after the crash
Comment 2 Bill Nottingham 2004-03-30 21:51:04 UTC
Did it actually install any packages?
Comment 3 Jeremy Katz 2004-03-30 23:39:08 UTC
Can you save the attachment (if no floppy, scp /tmp/anacdump.txt from tty2)?
Comment 4 Dave Jones 2004-03-31 11:58:52 UTC
iirc, tty2 was an bash prompt. I'll go through an install again later to be sure.
Comment 8 Jeremy Katz 2004-04-05 21:20:42 UTC
Hmmm, is this reproducible with later trees? I thought that we had the "cannot create transaction lock" thing fixed now.
Comment 9 Brian Wheeler 2004-05-19 19:26:52 UTC
This bug still seems to be present in the final release. My consoles look exactly the same as the screenshots.
Comment 10 Jesse Keating 2004-07-07 16:15:27 UTC
*** Bug 125805 has been marked as a duplicate of this bug. ***
Comment 11 Jesse Keating 2004-07-07 16:18:06 UTC
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 moment.
Comment 12 Carmi Weinzweig 2004-07-26 14:30:17 UTC
This bug also happens on my system (Asus K8V Deluxe with 3ware card), but seems to be solved in FC 3 Test 1. /carmi
Comment 13 Robert Græsdal 2004-08-14 02:05:06 UTC
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 self.currentWindow.renderCallback() File "/usr/lib/anaconda/iw/progress_gui.py", line 242, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 763, in nextClicked self.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 169, in gotoNext self.moveStep() 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 -- My rig: -- Epox 8KDA3+ AMD Athlon 64 2800+ 2x 512MB TwinMOS 200GB SATA Seagate Barracuda Geforce 4 Ti4200
Comment 14 Robert Græsdal 2004-08-14 02:08:41 UTC
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.
Comment 15 Traub, JT 2004-08-26 06:37:12 UTC
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 anything anyway). 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 exact errors. 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).
Comment 16 Traub, JT 2004-08-26 07:10:13 UTC
I just went back and retried the install. I left my harddrive partitioned as it had been and did the install in text mode. 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 going on. 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 hda: hda1 256MB /boot hda2 4G swap hda4 extended hda5 15G / hda6 25G /usr hda7 25G /var hda8 10G /tmp hda3 80G /home hdc: 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.
Comment 17 Karl Vegar 2004-09-16 12:52:33 UTC
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.
Comment 18 Karl Vegar 2004-09-16 13:00:03 UTC
Created attachment 103905 [details] anacdump.txt from text install. it seems these two are similar enough that it probably is the same bug.
Comment 19 Karl Vegar 2004-09-17 08:17:18 UTC
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 properly?
Comment 20 Karl Vegar 2004-09-20 10:12:03 UTC
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.
Comment 21 Traub, JT 2004-09-28 00:34:09 UTC
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 cause). 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 it work). Someone please find a workaround to this, please.
Comment 22 Karl Vegar 2004-09-29 06:56:29 UTC
Some more info. The Core2 x86_32 installer works like a charm, no problem on the first system. 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 quality memory.) 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 -Reboot... I have not attempted this routine. So use at your own risk. Regards.
Comment 23 Jeremy Katz 2004-10-07 18:06:13 UTC
Sounds like this is fixed in FC3 test...
Comment 24 Jeremy Katz 2004-10-07 18:17:54 UTC
*** Bug 123564 has been marked as a duplicate of this bug. ***
Comment 25 Jeremy Katz 2004-10-07 18:18:59 UTC
*** Bug 123692 has been marked as a duplicate of this bug. ***
Comment 26 Jeremy Katz 2004-10-07 18:20:45 UTC
*** Bug 123745 has been marked as a duplicate of this bug. ***
Comment 27 Jeremy Katz 2004-10-07 18:21:03 UTC
*** Bug 123840 has been marked as a duplicate of this bug. ***
Comment 28 Jeremy Katz 2004-10-07 18:27:50 UTC
*** Bug 124029 has been marked as a duplicate of this bug. ***
Comment 29 Jeremy Katz 2004-10-07 18:46:24 UTC
*** Bug 125198 has been marked as a duplicate of this bug. ***
Comment 30 Jeremy Katz 2004-10-07 18:49:34 UTC
*** Bug 125874 has been marked as a duplicate of this bug. ***
Comment 31 Jeremy Katz 2004-10-07 18:54:46 UTC
*** Bug 127128 has been marked as a duplicate of this bug. ***
Comment 32 Jeremy Katz 2004-10-07 19:00:11 UTC
*** Bug 128126 has been marked as a duplicate of this bug. ***
Comment 33 Jeremy Katz 2004-10-07 19:01:47 UTC
*** Bug 129332 has been marked as a duplicate of this bug. ***
Comment 34 Jeremy Katz 2004-10-07 19:04:03 UTC
*** Bug 130947 has been marked as a duplicate of this bug. ***
Comment 35 Jeremy Katz 2004-10-11 02:34:21 UTC
*** Bug 134996 has been marked as a duplicate of this bug. ***
Comment 36 Jeremy Katz 2004-10-24 21:49:12 UTC
*** Bug 136785 has been marked as a duplicate of this bug. ***
Comment 37 Dan Carpenter 2005-02-12 02:28:19 UTC
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 configurations today.