on rc.sysinit there is a posible "race condition" between calling getkey
(for interactive startup) and killing getkey (before starting selected
runlevel scripts)

{
# Clean up utmp/wtmp
>/var/run/utmp
touch /var/log/wtmp
chgrp utmp /var/run/utmp /var/log/wtmp
...
kill -TERM `/sbin/pidof getkey` >/dev/null 2>&1
}&
if [ "$PROMPT" != "no" ]; then
  /sbin/getkey i && touch /var/run/confirm
fi
wait

as you can see, if the code between the {} runs too fast, you could end
with an stalled "getkey" waiting forever for input (as i have experienced
on some Compaq Dual Processor, Hardware RAID systems and the simpler script
from RH6.2)

to be fair, i've been unable to reproduce the same "hung" on 7.0final but
there is a theorical posibility that if given enough resources this could
happen (there seems to be a need for about 1 second before the kill is
reached for getting a successfull kill of getkey)

my solution was to patch rc.sysinit so getkey is called with a "timeout"
parameter (seems like someone on RH tought it could happen before and added
the timeout parameter but no fix on the rc.sysinit script)

if [ "$PROMPT" != "no" ]; then
  /sbin/getkey -3 i && touch /var/run/confirm
fi
wait

RH6.2's getkey doesn't have the "timeout" parameter so a backport should be
released with the modified rc.sysinit to fix this problem.