Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 119447
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: | |||||||||||||
Severity: | high | Docs Contact: | |||||||||||||
Priority: | medium | ||||||||||||||
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 | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | x86_64 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2004-10-07 18:06:13 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Dave Jones
2004-03-30 16:46:10 UTC
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 tty2)? iirc, tty2 was an bash prompt. I'll go through an install again later to be sure. Created attachment 98995 [details]
tty3
Created attachment 98996 [details]
tty4
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 moment. This bug also happens on my system (Asus K8V Deluxe with 3ware card), but seems to be solved in FC 3 Test 1. /carmi 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 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 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). 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. 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 properly? 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 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. 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. 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 configurations today. |