From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030113
Description of problem:
Since FC4 (and continuing with the FC5test2 release), the controlling tty (/dev/tty) doesn't seem to work in the boot kernel used in rescue mode.
Any processes that attempt to open /dev/tty will fail. (This affects ssh,
dump and restore, and possibly other commands.)
Also, possibly related, is that tty-generated signals (e.g. Ctrl-C -> SIGINT) never seem to get to the foreground processes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. At rescue shell prompt, run "ssh -vvv host-or-ip command" (for a particular host & command)
2. Note failure to open /dev/tty.
3. "ln -f /dev/tty1 /dev/tty" fixes that, assuming you're on tty1 (but ^C still broken).
Actual Results: The workaround of linking /dev/tty to the actual tty device for the current shell gets the commands to work, but this is a poor substitute. Also, signal handling is still broken this way.
Expected Results: Opens of /dev/tty should work, as should tty-generated signals.
Seeing the same thing here using the FC4 rescue cd
[This comment added as part of a mass-update to all open FC4 kernel bugs]
FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel. As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
Please retest with Fedora Core 5.
The problem appears to be resolved with the FC5 rescue disk.
Thanks for the update.