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): How reproducible: Always 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. Additional info:
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 to FC5. Please retest with Fedora Core 5. Thank you.
The problem appears to be resolved with the FC5 rescue disk.
Thanks for the update.