[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > Do `showtrans /tmp/console' in that state and you will see one of the > arguments is the filename /tmp/console.
Well, "ps aux" already showed that. > Basically, /dev/console is being set up right, but is being > tickled to turn on in some way, and that's causing the problem. But /dev/console is the standard location. Why shouldn't programs be allowed to access it? The problem is that another translator starts reading the console device although there is already one. The /dev/console accesses should be directed to the existing translator, so that they don't start a new one. This is why I suggested making native-install move the /tmp/console node to /dev: to get /dev/console associated with the translator. Then there is still the problem that some program may have called ttyname() and will try to reopen /tmp/console. Making /tmp/console a symlink to /dev/console would take care of that. This scheme may not work if /tmp and /dev are different file systems, since the translator might not survive the move. It would be better if native-install could create /dev/console and set its passive translator like it does now, and then somehow attach the active translator to the node with something like "settrans --active --copy=/tmp/console /dev/console". Is that possible?
