By the way, my problems can be resolved with a few things.

1) Explicitly end pre/post/packages sections with %end, and most of
the errors will go away.
2) Using nomodeset as a kernel flag because (in my case, nouveau)
barfs on this hardware, causing the black screen I described.

- Rich

2011/8/2 Rich <[log in to unmask]>:
> FWIW, the systems I'm having this problem with are Zotac IONITX-A-U
> boards (http://www.zotacusa.com/zotac-ionitx-a-u-atom-n330-1-6ghz-dual-core-mini-itx-intel-motherboard.html).
>
> Since, as I described, loading the forcedeth driver in SL61 makes
> /sbin/loader SIGSEGV, I would not be surprised if it was a driver
> probing issue with either forcedeth or ath_pci or one of its
> dependencies - probably something stranger, since the FMV-A8260 has a
> Marvell 1000BASE-T chip and an Atheros wifi chip, but loading just
> forcedeth without ath_pci in play causes it to die, so...
>
> - Rich
>
> 2011/8/2 夜神　岩男 <[log in to unmask]>:
>>> On Tue, Aug 2, 2011 at 12:35 PM, Troy Dawson<[log in to unmask]>  wrote:
>>>>
>>>> Can you post the top half of your kickstart file, up to the Packages
>>>> section.
>>
>> For what its worth I've been doing installs across about 20 different system
>> configurations lately and the PXE boot and DVD boot (same boot kernel
>> anyway, and not using kickstart -- all of these are specific installations;
>> yes a pain) hangs consistently in this precise way. Black and unresponsive
>> before networking is on.  This happens on exactly one specific model I've
>> found so far out of the pack: Fujitsu FMV-8260 latops with (specifically)
>> Celeron 540 processors and Intel GL960 Express chipset.
>> (Spec link: http://www.fmworld.net/biz/fmv/lifebook/0804/a8260/ )
>>
>> I haven't had time to research this further and didn't want to before
>> posting to list (I've got a lot of other things on my plate first anyway),
>> but this is the exact same set of symptoms I've seen, so thought it worthy
>> of note. It is that exact model, and not its cousins. Both notebooks of this
>> model demonstrate the same behavior, so it really seems to be something
>> architectural that isn't being supported properly by the kernel (and the
>> noprobe behavior makes me think this as well...).
>>
>> -Iwao
>>
>