This was a long day...  And, of course, I have a few comments.  :-)

I installed a lot of packages with kickstart.  The installation failed at about the 60% point.

First comment: Guys, I had invested hours in this installation.  Is there a way that exceptions can be caught, logged and the installation resumed?  I KNOW it claims “unhandled exception”, but there should be a catch-all handler, so that all of them are handled.

I subsequently struggled with an array of unknown exceptions and I think they were the result of the mirror list pointing me to a different mirror – one with a corrupt package, but I can’t be sure.  I filed a dozen reports over the course of the day and grumbled under my breath and I blamed you guys.  I hope I was wrong.  Please investigate all the bugs I filed on that day, since they are all related to this one single installation.

Eventually, I succeeded without the mirror list layer.

I don’t know if it is important, but there are at least two things that I was doing differently from a “normal” installation.  The installation repo was not burned to physical optical media and I used a virtual machine to manage the installation.

1) I had the DVD on the local disk as iso, and my extlinux stanza looked like this:

LABEL ins-F13-ks
	MENU LABEL ^KickStart Ins / Upg Fedora-13 (<F4> Edit Kernel Options Help)
	KERNEL /Fedora-13/isolinux/vmlinuz
	APPEND initrd=/Fedora-13/isolinux/initrd.img ro lang=en_US keymap=us ksdevice=eth0 ip=dhcp graphical ks=hd:/dev/sda1:/Fedora-13/ks.cfg

2) I was installing to the 250G disk while running linux from a 4G USB key drive (NOT with the useroverlay foolishness) and I used virt-manager to run qemu-kvm which is how I booted into the installation.  As you can see from the extlinux stanza, I did NOT simply point the virtual CD-ROM to the iso.

(In reply to comment #1)
> This was a long day...  And, of course, I have a few comments.  :-)
> 
> I installed a lot of packages with kickstart.  The installation failed at about
> the 60% point.

Deploying linux on a lot of systems certainly takes time.  Thank you for providing feedback.
 
> First comment: Guys, I had invested hours in this installation.  Is there a way
> that exceptions can be caught, logged and the installation resumed?  I KNOW it
> claims “unhandled exception”, but there should be a catch-all handler, so that
> all of them are handled.

It certainly can be frustrating when you spend a lot of time working around a problem that affects you.  I'm not aware of a method to properly detect and resolve/work-around arbitrary failures.  As always, the anaconda developers welcome ideas in the form of code.  To contribute, see https://www.redhat.com/archives/anaconda-devel-list/.

In this case, I would recommend first helping to analyze the root cause of the failure.  From there, we can make recommendations for future action.  Until then, it would be difficult to make development recommendations.

> I subsequently struggled with an array of unknown exceptions and I think they
> were the result of the mirror list pointing me to a different mirror – one with
> a corrupt package, but I can’t be sure.  I filed a dozen reports over the
> course of the day and grumbled under my breath and I blamed you guys.  I hope I
> was wrong.  Please investigate all the bugs I filed on that day, since they are
> all related to this one single installation.
> 
> Eventually, I succeeded without the mirror list layer.

I recommend keeping discussion in each bug report focused on the specific topic.  For the problems related to mirrorlist and hard drive (and hard drive ISO) install failures, please direct feedback to bug#573492.  Please continue to discuss the "KeyError: 'setuptime' failure in this bug report.

> I don’t know if it is important, but there are at least two things that I was
> doing differently from a “normal” installation.  The installation repo was not
> burned to physical optical media and I used a virtual machine to manage the
> installation.
> 
> 1) I had the DVD on the local disk as iso, and my extlinux stanza looked like
> this:
> 
> LABEL ins-F13-ks
>  MENU LABEL ^KickStart Ins / Upg Fedora-13 (<F4> Edit Kernel Options Help)
>  KERNEL /Fedora-13/isolinux/vmlinuz
>  APPEND initrd=/Fedora-13/isolinux/initrd.img ro lang=en_US keymap=us
> ksdevice=eth0 ip=dhcp graphical ks=hd:/dev/sda1:/Fedora-13/ks.cfg
> 
> 2) I was installing to the 250G disk while running linux from a 4G USB key
> drive (NOT with the useroverlay foolishness) and I used virt-manager to run
> qemu-kvm which is how I booted into the installation.  As you can see from the
> extlinux stanza, I did NOT simply point the virtual CD-ROM to the iso.    

Thanks, that feedback will be helpful in the other bug report (see bug#573492), along with the kickstart file used to produce the failure.

Hello Chris, 

thanks for reporting this. The installation path you've chosen is not very well tested and unfortunately a bit broken.

I manged to reproduce:
1) have a kicstart specifying your timezone, root password and bootloader. Request text install too.
2) The first TUI screen that ever appears is partitioning. Click 'Back'.
3) 'I can't go to the previous step from here' dialog emerges. That's good. Click 'OK'
4) The exception arrives.

I'll be preparing a fix for rawhide (F14).

Fixed rawhide by 35e61b016bd1a83bbb4941622f93a36d9b13dacd, will be in anaconda-14.12.