As per the subject. The problem is that starting X11 as non-root needs a session, which openrc doesn't seem to be able to provide. The classical way of starting kodi on boot, as illustrated here: https://wiki.gentoo.org/wiki/Kodi#OpenRC_.2B_xinit does not work anymore. I haven't tried the inittab approach. What did work was re-merging Xorg with USE=suid and adding this to /etc/X11/X11/Xwrapper.config (yes there are two dirs named X11 in that path): allowed_users = anybody needs_root_rights = yes Ideally, we'd find a way to start kodi on boot without having to have Xorg suid set.
I encountered the same problem and have found the following Gentoo related workaround so far (just to link it here): https://flameeyes.blog/2019/06/02/boot-to-kodi-2019-edition/
I did a little more research and think that the issue lays in start-stop-daemon is not fixable in a trivial way. When logging in within a TTY as the kodi user and typing: ``` $ startx /usr/bin/kodi-standalone ``` everything works without a suid enabled X. xinit on it's own does not work but need an argument more (that is set automatically by startx): ``` $ tty_num = $(tty) $ tty_num = ${tty#/dev/tty/} $ xinit /usr/bin/kodi-standalone -- vt${tty_num} ``` This command forces X to start in the same virtual terminal respectively session the current kodi user is logged in (this can also be checked with loginctl). Starting X on another virtual terminal (and session) does not work. This is also the difference to the suid enabled X. This X can open another virtual terminal and start in this terminal. That means that the openrc script somehow needs to provide a new virtual terminal together with an (e)logind session as user kodi _before_ starting X (btw, that is exactly that what a login manager does). In the OpenRC example in the wiki the only "login manager" is start-stop-deamon, since start-stop-deamon runs as root and changes the user to kodi. However, start-stop-deamon is only capable of changing the user but does _not_ assign a new virtual terminal to it and also doesn't manage the (e)logind session in any way (I'm not sure, if systemd provides such functionality). At least, I have not found an option in the manpage for that. Within the "exec" part of start-stop-deamon we cannot do anything anymore, since we are already user kodi and are not permitted to start a new session anymore. So I guess, the only good solution is to extend start-stop-deamon with elogind support.
Seems not to be trivial on systemd, too: https://wiki.archlinux.org/index.php/Systemd/User#Xorg_and_systemd
Just switched to flameeyes lightdm configuration as well. It does seem like it might be the best way to proceed forward. I did find USE=gnome was required on lightdm personally to pull in the accountsservice dependency. Unless someone comes up with something better, I'll probably update the wiki in 1-2 days with that as a recommended replacement. It adds an extra layer in the stack, but I think we can count on lightdm working more reliably into the future than the alternatives. I expect we'd all rather be watching a movie than debugging why we got a shell instead of Kodi.
The Wiki has been updated with a lightdm replacement: https://wiki.gentoo.org/wiki/Kodi#Using_lightdm Feedback and changes are welcome. If we have a few people happy with those instructions then we can likely close this issue.
Is this bug still relevant, since kodi-18 belongs to the dark age of python 2.7? I can start kodi 19 with X11 as non-root no problems.
(In reply to Gabriel from comment #6) > Is this bug still relevant, since kodi-18 belongs to the dark age of python > 2.7? I can start kodi 19 with X11 as non-root no problems. I've been using one of the solutions in the wiki for a while with no issue. I think this can be closed. If candrews@ wants to reopen, feel free.
