We are trying to migrate to systemd but one hurdle remains: tail -20 Xorg.0.log.old [ 14.514] (II) UnloadModule: "libinput" [ 14.514] (II) UnloadModule: "libinput" [ 14.514] (II) UnloadModule: "libinput" [ 14.514] (II) UnloadModule: "libinput" [ 14.514] (II) UnloadModule: "libinput" [ 14.534] (WW) xf86OpenConsole: VT_ACTIVATE failed: Input/output error [ 14.534] (EE) Fatal server error: [ 14.534] (EE) xf86OpenConsole: Switching VT failed [ 14.534] (EE) [ 14.534] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 14.534] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 14.534] (EE) [ 14.535] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error [ 14.535] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error [ 14.535] (WW) xf86OpenConsole: VT_GETSTATE failed: Input/output error [ 14.535] (EE) Server terminated with error (1). Closing log file. What ever I do I cannot get past this. Tried lots of stuff. The same kernel/sddm etc. work fine in openrc I know this is a shot in the dark but perhaps someone has a clue(google does not)
Share the full log?
Created attachment 833127 [details] Xorg log
Vmware virtual machine? I would not expect much of difference with Xorg on openrc and systemd systems. There are few code paths that it can goes with you, and you'd need to see which one works. - systemd rootless X -- make sure X is built with systemd/elogind USE flag and no suid USE is enabled. - systemd root X -- build xserver with suid USE flag - openrc rootless X -- see https://wiki.gentoo.org/wiki/Non_root_Xorg - openrc root X -- same as systemd's above. Nowadays the way it should work is it should use logind interface (confirm you have seat) and then it will use current VT. If it tries to do VT switching, perhaps something went wrong, like you do not have seat assigned and because +systemd USE flag it tries to go rootless route and fails hard. Could also be that the vmware drivers for it's virtual GPU are somewhat not compatible with modern modesetting. All in all, you are 100% able to get X started in the same way on systemd as on openrc system, its just perhaps global systemd USE flag got on your xserver and this is why it no longer works.
(In reply to Piotr Karbowski from comment #3) > Vmware virtual machine? I would not expect much of difference with Xorg on > openrc and systemd systems. This one is VM, where we create our local Gentoo dist. The problem happens on any machine though. > > There are few code paths that it can goes with you, and you'd need to see > which one works. > > - systemd rootless X -- make sure X is built with systemd/elogind USE flag > and no suid USE is enabled. I have for systemd: x11-base/xorg-server USE=systemd udev xorg xvfb and for openrc: x11-base/xorg-server USE=elogind udev xorg xvfb > - systemd root X -- build xserver with suid USE flag > - openrc rootless X -- see https://wiki.gentoo.org/wiki/Non_root_Xorg > - openrc root X -- same as systemd's above. > > Nowadays the way it should work is it should use logind interface (confirm > you have seat) and then it will use current VT. If it tries to do VT How do a confirm I really have a seat ? > switching, perhaps something went wrong, like you do not have seat assigned > and because +systemd USE flag it tries to go rootless route and fails hard. > Could also be that the vmware drivers for it's virtual GPU are somewhat not > compatible with modern modesetting. > > All in all, you are 100% able to get X started in the same way on systemd as > on openrc system, its just perhaps global systemd USE flag got on your > xserver and this is why it no longer works. Don't quite understand the last part, should I change something on xorg-server?
The linked wiki page describes checking if seat is assigned. Have you read it? The simplest way would be to add temporary +suid to xorg-server and see if it makes things work for you, if so, your issue is that you might not get a seat, and debug it from there (systemd's pam integration is a good thing to look into first).
(In reply to Piotr Karbowski from comment #5) > The linked wiki page describes checking if seat is assigned. Have you read > it? > > The simplest way would be to add temporary +suid to xorg-server and see if > it makes things work for you, if so, your issue is that you might not get a > seat, and debug it from there (systemd's pam integration is a good thing to > look into first). I added xorg USE=suid and rebooted, SDDM still show the same error w.r.t seat I got: ps uaxxw | grep X root 1269 0.6 0.4 283776 65928 ? Ssl 19:28 0:02 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{9bc4141b-e9ce-44e7-9785-c1c9c16252d3} -background none -noreset -displayfd 20 -seat seat0 vt7 w.r.t PAM I have: sddm-greeter:session optional pam_systemd.so systemd-user:session optional pam_systemd.so system-login:-session optional pam_systemd.so
I found something: systemctl disable console-getty.service That got my VTs working again, not sure what that service is good for though. One minor diff w.r.t openrc, 1:st VT (Alt+F1) does not get an login prompt. I just see the various msgs from kernel/systemd from starting up
That sounds like problem with sddm itself and has not much to do with xserver alone. If freeing tty from agetty helps you then the simplest workaround for wonky sddm would be to configure MinimalTTY to 7 in sddm config so it does not try to get control over used terinal. Beside workaround, if sddm cannot take over tty1 then it sounds like it has no seat assigned to it, something that you'd need to investigate on your end. Once you can confirm that re-enabling getty and setting MinimalTTY to 7 lets you to start sddm, I would prefer to close this bug and encourage you to follow it up with sddm upstream, then perhaps open new bug this time for sddm.
(In reply to Piotr Karbowski from comment #8) > That sounds like problem with sddm itself and has not much to do with > xserver alone. If freeing tty from agetty helps you then the simplest > workaround for wonky sddm would be to configure MinimalTTY to 7 in sddm > config so it does not try to get control over used terinal. > > Beside workaround, if sddm cannot take over tty1 then it sounds like it has > no seat assigned to it, something that you'd need to investigate on your > end. > > Once you can confirm that re-enabling getty and setting MinimalTTY to 7 lets > you to start sddm, I would prefer to close this bug and encourage you to > follow it up with sddm upstream, then perhaps open new bug this time for > sddm. (Assuming MinimalTTY really means MinimumVT ) I already have MinimalVT=7: cat /etc/sddm.conf [Theme] # Current theme name Current=infinera [X11] MinimumVT=7 #ServerArguments=-keeptty -nolisten tcp ServerArguments=-nolisten tcp Also tested lightdm at some point and it had a similar problem with VTs VTs 2 to 6 works as expected Does this confirm having a seat:? root 1035 0.6 0.8 2226448 133480 ? Sl 13:26 0:01 /usr/bin/X -nolisten tcp -auth /var/run/sddm/{efae64ee-9cfa-45ae-88ad-dc32bd37d72c} -background none -noreset -displayfd 17 -seat seat0 vt7
'Similar problems' is nothing that I can help you with without actual details. You seems to have X running as root, whatever it is USE=suid or sddm decided to spawn it as such. You should bring it up with sddm upstream, clearly some interfaces must be missing if it works with elogind but not with systemd, as for this moment I see no indication that something is wrong with xorg-server itself unless you cannot start it after you log via startx and $XSESSION or .xinitrc.
