Bug 119447

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.