[solved] Start Rom fails with Unable to open /dev/tty

guest.001

Same problem here. It seems that after an update the init process changed somehow, and now emulationstation is started in tty1. I solved the same way:

Change all the '/dev/tty' with '$TTY' in runcommand.sh
Put on the top of runcommand.sh the line 'TTY="$(tty)"'

Mybe these changes may be done upstream ?

mitu

@guest-001 said in [solved] Start Rom fails with Unable to open /dev/tty:

Mybe these changes may be done upstream ?

What's your use case ? ES (and the child runcommand) could start on a different VT, so harcdoding the VT where the runcommand is expecting it to be it's not correct. /dev/tty is a special file pointing to the current process' running VT, it's the correct way to use it.

EDIT: I see you're not using the same /dev/tty1 value, but the ${tty} env var - but this should be the same as using /dev/tty. What version of RetroPie are you using ?

guest.001

I do not remember from which image I started, however I did various update. 'uname -a' gives me

Linux retropie 4.14.62-v7+ #1134 SMP Tue Aug 14 17:10:10 BST 2018 armv7l GNU/Linux

However, I think I tracked back my issue: If during the startup the rpi got a ssh connection BEFORE the emulationstation started, then emulationstation will run on /dev/tty1, otherwise it correctly uses /dev/tty.

However, using $(tty) everywhere seems to me a good thing to do.

mitu

@guest-001 said in [solved] Start Rom fails with Unable to open /dev/tty:

However, I think I tracked back my issue: If during the startup the rpi got a ssh connection BEFORE the emulationstation started, then emulationstation will run on /dev/tty1, otherwise it correctly uses /dev/tty.

I don't see how that woud work out, but on my install, emulationstation starts by default on /dev/tty1, regardless of any SSH connection to the PI.

However, using $(tty) everywhere seems to me a good thing to do.

Sure, there's more than one way to skin a cat :).

guest.001

I don't see how that woud work out, but on my install, emulationstation starts by default on /dev/tty1, regardless of any SSH connection to the PI.

Right now I am not able to reproduce the issue anymore. Also using the original runcommand.sh, the roms always starts correctly, regardless of the SSH connection. At this point I can not be sure that the my changes did the trick.

I do not know what was going on, but and this was what happened:

NOTE: original runcommand.shwithout any change
Start the rpi
Open an SSH connection before the emulationstation splashscreen pops up
Launch any rom
An error flashed, complaining about the access to /dev/tty
The system went back to the rom selection

NOTE: I could correctly launch any rom if I skip the point 3 (i.e. no SSH connection opened)
NOTE: I made repeated test: 2-3 times for each scenario (with or without SSH) with multiple reboots

mitu

@guest-001 said in [solved] Start Rom fails with Unable to open /dev/tty:

Open an SSH connection before the emulationstation splashscreen pops up

So just opening a SSH connection without any other commands been run will be enough to reproduce this ?

guest.001

@mitu said in [solved] Start Rom fails with Unable to open /dev/tty:

So just opening a SSH connection without any other commands been run will be enough to reproduce this ?

Yes, this was my experience. But now I can not reproduce it anymore, so I am not sure if it was not something else.

guest.001

Problem happened again. I do not know why it generates, however I can confirm that substituting all the /dev/tty with /dev/tty1 in runcommand.sh fixes it. Using $(tty) does not works since tty gives the error not a tty. To get some other info, I added on the top of runcommand.sh the lines

echo "" > ~/tmp.out
users &>> ~/tmp.out
groups &>> ~/tmp.out
ls -lha /dev/tty &>> ~/tmp.out
sudo stty --file=/dev/tty &>> ~/tmp.out
echo "XXXXXXXXXXXXXXXXX $LINENO $(tty)" &>> ~/tmp.out
ls -lha /dev/tty1 &>> ~/tmp.out
sudo stty --file=/dev/tty1 &>> ~/tmp.out

the result is

pi pi
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi
crw-rw-rw- 1 root tty 5, 0 Sep 10 18:13 /dev/tty
stty: /dev/tty: No such device or address
XXXXXXXXXXXXXXXXX 8 not a tty
crw--w---- 1 root tty 4, 1 Sep 10 18:27 /dev/tty1
speed 38400 baud; line = 0;
min = 1; time = 0;
iutf8
-icanon -echo -echoe -echok -echoke

After some reboots, the things starts to work again with /dev/tty also. The previous log changed to:

pi pi pi
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi
crw-rw-rw- 1 root tty 5, 0 Sep 10 18:59 /dev/tty
speed 38400 baud; line = 0;
iutf8
-echok
XXXXXXXXXXXXXXXXX 8 /dev/tty1
crw------- 1 pi tty 4, 1 Sep 10 18:59 /dev/tty1
speed 38400 baud; line = 0;
iutf8
-echok

Returning to the causes of the problem: I have a lot of undervoltage due to a buggy case with an integrated power regulator. Can an undevoltage cause this sort of problem?

mitu

@guest-001 said in [solved] Start Rom fails with Unable to open /dev/tty:

Can an undevoltage cause this sort of problem?

No, that's not from that. However you haven't said anything about your setup or any script you might be running alonside runcommand.sh that might trigger this.

guest.001

Well... I do not know what to say about my setup. I use a raberrypi 3b+. No change to the boot configuration. I did not install weird script or software (in a previous setup I used the nespi-case scripts, but after that I re-made a clean installation). I updated multiple time the system with retropie_setup or raspi-config. I installed and run the Steven Selph scraper. I installed some emulator (commmodore 64, amiga, etc).

If you have some specific questions, but nothing strange come to my mind about my installation.

mitu

@guest-001 The original poster had problems when starting runcommand.sh from /etc/rc.local, for which the solution was to change the /dev/tty to /dev/tty1.
There is no reported problem when using runcommand.sh normally, from ES, so I was wondering if you had a similar script set-up - especially since you were talking about noticing an error when a SSH connection was made before ES starts.
I don't know what might trigger your problems, but if you can reliably reproduce it from a RetroPie image, then share the steps necessary to get the error and we can try and see where the problem occurs.