You are not logged in.
I added to the bottom of my .bash_profile a single command to start a graphical app: emulationstation. This does what I want and, if I log in to this account, it starts automatically.
I then set up autologin per the wiki and that also works: when I turn on the computer, it automatically logs in to that account. The problem is that the program, when it starts, immediately fails to initialize its graphics subsystem claiming that /dev/dri is unavailable. This app uses SDL if that makes a difference and fails during SDL_Init. If I add a "sleep 2" to my .bash_profile right before I start the app, though, it works every time.
This implies to me that I need have agetty wait until something has finished initializing, but I don't know what or how to make it wait for it. I tried adding "Type=idle" to the getty override file as well as "Type=simple" but that didn't make a difference.
How might I debug this further?
Offline
Are you booting to graphical.target or multi-user.target ?
$ systemctl get-defaultLast edited by Lone_Wolf (2019-01-22 14:35:36)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I'm booting to the graphical target. The fact that adding a small sleep fixes it makes me think that getty is still running too early for some reason.
Offline
for some reason
Graphical Target stops when X has started, multi-user stops when console login is reached.
The getty "Automatic login to virtual console" method is intended to work with multi-user target , not graphical target.
There is however a clean solution to combine getty autologin with X applications :
Boot to multi-user target
getty performs autologin to a virtual console
xinit / startx are run automatically and initialise the graphical environment
xinitrc is used to start the application .
See https://wiki.archlinux.org/index.php/Xinit
Last edited by Lone_Wolf (2019-01-29 10:19:45)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline