| View previous topic :: View next topic |
| Author |
Message |
dg09
n00b
Joined: 24 Apr 2024
Posts: 11
|
 Posted: Fri May 31, 2024 2:38 pm Post subject: Rootless Xorg/SDDM - Sometimes works / sometimes doesn't |
 |
|
Greetings all,
I am having a hard time getting Xorg to run in rootless mode through SDDM. On occasional bootups, there seems to be an issue with the helper taking over the corresponding tty(according to the log file). The behavior is that sometimes the Plasma session will start after logging in through SDDM, while some others, the screen will go black(I presume during the switch from SDDM to Plasma) and not do anything from there. I am able to switch to another TTY and login via the console when that happens, but to my knowledge, there isn't much I can do to restart the display manager from there other than restarting the entire system; restarting the service with rc-service does not work(it will state that it has started but SDDM won't be present on any VT), and there is no running process relevant to SDDM nor X11 whatsoever. The only relevant message I am able to see from the sddm log file when using the x11-user value is the following:
| Code: | | (EE) HELPER: Failed to take control of "/dev/tty1" ("root"): Operation not permitted |
The Xorg log file doesn't seem to contain any indication of errors either. However, I leave the relevant log files attached on a wgetpaste for reference:
/var/log/sddm.log
/var/log/Xorg.0.log
~/.local/share/sddm-helper-start-x11user/sddm.log
This seems to also affect the display manager behavior whenever logging out; during logout, the screen will also go black and stay there, until I forcefully restart the system, but as a difference to when initially logging in, this will always fail, whereas initial logins will sometimes work, and sometimes won't. None of this happens when I remove the x11-user value on the SDDM configuration file.
I have placed the directive "DisplayServer=x11-user" as indicated in the wiki. I also have logind enabled as a global USE flag. I tried recompiling the xorg-server package with the suid flag enabled to see if that would somehow make a difference, but the same results were obtained. I have also added the sddm user into the video group as the wiki states, but none of this has made a difference.
I came across a comment on a forum that adding a delay for SDDM to start seemed to improve the issue; the poster claimed it only happened on his system with a much faster CPU, which happens to be the same line as the one I have(i9). However, I have not tested this solution as I personally think there must be a proper solution(?) or that I'm likely missing something, and I am also not as well versed with OpenRC yet so adding a delay to a service is out of my current knowledge domain. I have only been running Gentoo for about 3 months as my daily driver and I am much more familiar with systemd. Anyway, I'm posting this here hoping someone is able to point me in the right direction.
Appreciate your time and thanks in advance,
- DG |
|
| Back to top |
|
 |
rab0171610
Guru
Joined: 24 Dec 2022
Posts: 423
|
| Posted: Sat Jun 01, 2024 4:20 am Post subject: |
|
|
| Could you please explain why you feel it is necessary for your setup to run X in rootless mode? I guess my point is that it is atypical which explains why you might be having issues. While it can be done, many people have also had issues with this esp when using SDDM/KDE. You might be better off not using SDDM and using startx to run rootless mode. Another thing to consider would be to switch to Wayland if you feel typical X permissions are a serious security issue for you. |
|
| Back to top |
|
|
dg09
n00b
Joined: 24 Apr 2024
Posts: 11
|
| Posted: Sat Jun 01, 2024 6:07 am Post subject: |
|
|
| rab0171610 wrote: | | Could you please explain why you feel it is necessary for your setup to run X in rootless mode? I guess my point is that it is atypical which explains why you might be having issues. While it can be done, many people have also had issues with this esp when using SDDM/KDE. You might be better off not using SDDM and using startx to run rootless mode. Another thing to consider would be to switch to Wayland if you feel typical X permissions are a serious security issue for you. |
Appreciate your input. It's not so much a concern for security. More of a thing of habit, I guess. I usually like to make things work. I also have been running rootless Xorg for several years now, though that has been on Arch, and with many different setups; window managers, desktop environments, tty logins with xinit/startx, display managers, etc., and never had a problem with it there, so that kinda makes me want to make it work here too. I recently migrated to Gentoo, which has been my daily driver for around 2~3 months now give or take(I'm enjoying quite a bit so far; quite likely here to stay), and this is the only thing I am not yet able to get fully working. Getting to know Portage, OpenRC and dracut for initramfs generation took a bit of adjusting compared to how easy mkinitcpio and crypttab on Arch and systemd are, but I managed to get it all working, from dmcrypt and LVM with snapshots to plymouth splash screen with automatic unlocking at boot, nfs mounts, etc., so I guess this puzzle is merely a thing of intrigue at this point.
I definitely plan on trying Wayland once again soon, when the Nvidia driver 555 with the explicit-sync protocol implemented is officially released and available on the Portage tree. I spent some time on Wayland before already, more specifically with Hyprland on my laptop which has a 3060M on it for a few months, and while the majority of the experience was rather good, the constant visual glitching at some point would become more of a nuisance, despite them not being a major issue that would prevent me from working or anything of the sort, such as crashes, but still annoying at some point. This new desktop I built has a 4090 for which I did compile everything with Wayland support in anticipation for the Nvidia driver. However, while the Plasma session on Wayland seems to run fairly well(I dare say it even feels more responsive and snappy than Xorg), it still has several issues compared to Xorg; the font scaling seems off for the entire UI, requiring individual adjustments over each type of font face often looking disproportionate, so to me, not quite feasible yet, and also the desktop icon placements would move to random places after resuming suspend or after the screen would lock and turn off after being inactive for some time. These things don't happen on Xorg at all, which is why I wish to remain on Xorg, for the time being anyway. Thanks again for your input. Will be taken into consideration  |
|
| Back to top |
|
|
rab0171610
Guru
Joined: 24 Dec 2022
Posts: 423
|
| Posted: Sat Jun 01, 2024 7:30 am Post subject: |
|
|
Ok, I run Wayland with KDE Plasma and Nvidia proprietary driver for over a year with no issues so far. I can't tell any difference in the fonts. I use a forced font DPI of 144, a 16:9 resolution, 100% scaling and no issues at all, including gaming. As for rootless mode, it may have something to do with your tty issues.
I still don't see the point of rootless mode if you are not doing it for security reasons. Seems like more of a hassle than it is worth IMO. I do understand your desire to make it work however and respect your desire to do things your own way. That is the beauty of Gentoo. |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 653
|
| Posted: Sat Jun 01, 2024 12:19 pm Post subject: |
|
|
Try this dummy service to keep the boot process "alive" and force sddm on to any tty that isn't tty1: | /etc/init.d/dummy: | #!/sbin/openrc-run
depend() {
after display-manager
}
start() {
ebegin "Keeping boot alive"
sleep 10
eend $?
}
stop() {
:
eend $?
} |
It needs to be executable so run chmod u+x /etc/init.d/dummy and remember to add it to the correct runlevel rc-update add dummy default.
It probably doesn't need to be 10 seconds long, but you can play with that if you like.
If it works, I can update it to check that "sddm is up and running" then exit, so it doesn't sit there doing nothing longer than it needs too.
EDIT: | Quote: | | but to my knowledge, there isn't much I can do to restart the display manager from there other than restarting the entire system |
Just login as root, and run /etc/init.d/display-manager restart. If it gives an error and doesn't start sddm run killall -9 sddm then
/etc/init.d/display-manager zap start
| Quote: | | I personally think there must be a proper solution(?) |
There are commits to SDDM since 0.19 that cause issues for sysvinit users, until they are fixed upstream we'll have to make do with "workarounds" such as this. |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1249
Location: Richmond Hill, Canada
|
| Posted: Sat Jun 01, 2024 12:38 pm Post subject: |
|
|
Ralphred,
Would you mind kindly explain why the script needed and how it force SDDM to use any tty?
I can understand the shell script logic but I am not able to understand how it is related to sddm or tty since in the script there is nothing remotely close to any of those thing.
I have a sdd/kde/plasma mystery at hand would love to understand how this script relate to Gentoo default kde/plastma with sddm.
Thank you very much! |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 653
|
| Posted: Sat Jun 01, 2024 1:11 pm Post subject: |
|
|
The 0.20 updates to SDDM put the VT selection in the hands of a specific collection of code, despite having a cmake variable floating around to specify a "minimum VT" the automatic "first free tty" selector code ignores it. Instead of trying to force the code to behave I just "game" it by making the ttys I don't want SDDM to run on unavailable to it.
In this case that means extending the time of the boot process so tty1 is still in use, by the boot process, when SDDM starts. There may be other ways to achieve this, for example turning off the "background" flag for sddm in the display-manager openrc-run script should work too, but the dummy script is simple, standalone, and should test if SDDM trying to use tty1 is the issue in dg09's case. |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1249
Location: Richmond Hill, Canada
|
| Posted: Sat Jun 01, 2024 2:00 pm Post subject: |
|
|
Ralphred,
Thank you very much!, it make perfect sense. |
|
| Back to top |
|
|
dg09
n00b
Joined: 24 Apr 2024
Posts: 11
|
| Posted: Sat Jun 01, 2024 7:07 pm Post subject: |
|
|
| rab0171610 wrote: | Ok, I run Wayland with KDE Plasma and Nvidia proprietary driver for over a year with no issues so far. I can't tell any difference in the fonts. I use a forced font DPI of 144, a 16:9 resolution, 100% scaling and no issues at all, including gaming. As for rootless mode, it may have something to do with your tty issues.
I still don't see the point of rootless mode if you are not doing it for security reasons. Seems like more of a hassle than it is worth IMO. I do understand your desire to make it work however and respect your desire to do things your own way. That is the beauty of Gentoo. |
rab,
I see, thank you for the details. Interestingly enough, this happens on both my Nvidia systems, both on Arch(Plasma 6.0.4) and Gentoo(Plasma 5.27.11), and only on the Wayland sessions, whether using only the laptop's built-in display or whether plugged in to the same monitor the desktop uses(a 4K ultrawide monitor with a 21:9 ratio). These artifacts aren't at all apparent when booting them with their integrated Intel GPUs. Needless to say, I'll be testing both some more soon as the driver is released . And yes, that is indeed the beauty of Gentoo. I might just forget about rootless xorg for the time being. It's not critical. More my nagging sense making me want it to work haha.
| Ralphred wrote: | Try this dummy service to keep the boot process "alive" and force sddm on to any tty that isn't tty1: | /etc/init.d/dummy: | #!/sbin/openrc-run
depend() {
after display-manager
}
start() {
ebegin "Keeping boot alive"
sleep 10
eend $?
}
stop() {
:
eend $?
} |
It needs to be executable so run chmod u+x /etc/init.d/dummy and remember to add it to the correct runlevel rc-update add dummy default.
It probably doesn't need to be 10 seconds long, but you can play with that if you like.
If it works, I can update it to check that "sddm is up and running" then exit, so it doesn't sit there doing nothing longer than it needs too.
EDIT: | Quote: | | but to my knowledge, there isn't much I can do to restart the display manager from there other than restarting the entire system |
Just login as root, and run /etc/init.d/display-manager restart. If it gives an error and doesn't start sddm run killall -9 sddm then
/etc/init.d/display-manager zap start
| Quote: | | I personally think there must be a proper solution(?) |
There are commits to SDDM since 0.19 that cause issues for sysvinit users, until they are fixed upstream we'll have to make do with "workarounds" such as this. |
Ralphred,
Thank you for your comment and suggestions, really appreciate your time. I have tried this and it doesn't seem to have any effect. The resulting boot is the same, with the logs indicating the same error; "Operation not permitted". I increased the dummy sleep time up to 60s for trial's sake and it resulted in the same.
| Quote: | Just login as root, and run /etc/init.d/display-manager restart. If it gives an error and doesn't start sddm run killall -9 sddm then
/etc/init.d/display-manager zap start |
This I had tried as well. killall -9 sddm doesn't have an effect either because at that point the sddm process seems to have exited; there is no such process at that point. I even looked up the process table with top and htop, but it isn't there. Nothing related to the X server is running at that point. Restarting the display-manager service, either with either zap start or with rc-service both result in the same: what I see is the screen going back to the previous VT where the SDDM login screen was, but it stays completely black with a blinking cursor and nothing else happens. Going back to another tty to re-do the process results in the same cycle(even with the blinking cursor, the sddm process, or anything related to the X server, doesn't exist). There are also no errors thrown when starting the service through another tty. It gracefully complies, but nothing else happens.
I was not aware of the SDDM changes you are pointing out. That may hopefully resolve it in the near future when they are available on the Portage tree. For the time being, I may try tinker a bit more with it if I find other potential solutions but eventually I may just stick to the default config if I don't. Once again, thanks a bunch for your input and explanations! |
|
| Back to top |
|
|
rab0171610
Guru
Joined: 24 Dec 2022
Posts: 423
|
| Posted: Sun Jun 02, 2024 7:51 am Post subject: |
|
|
Ah, I do not have hybrid graphics system. Just a dedicated Nvidia GPU.
I think you are right about getting the system working as intended with a more traditional, "default" setup (X, KDE, SDDM). Once you have any issues worked out, then attempt to get the rootless mode working on Gentoo. It will make it a lot easier to troubleshoot that way. |
|
| Back to top |
|
|
dg09
n00b
Joined: 24 Apr 2024
Posts: 11
|
| Posted: Sun Jun 02, 2024 11:37 pm Post subject: |
|
|
| rab0171610 wrote: | Ah, I do not have hybrid graphics system. Just a dedicated Nvidia GPU.
I think you are right about getting the system working as intended with a more traditional, "default" setup (X, KDE, SDDM). Once you have any issues worked out, then attempt to get the rootless mode working on Gentoo. It will make it a lot easier to troubleshoot that way. |
That's the thing haha. There is no other issues. It all works great. As mentioned, this is the only thing I can't get to work. Everything else works error-free; no errors in logs, no weird dmesg issues, etc. The Wayland thing I wouldn't consider an issue since it happens on other distributions and other systems too, so not a Gentoo thing. Otherwise, no issues at all. |
|
| Back to top |
|
|
rab0171610
Guru
Joined: 24 Dec 2022
Posts: 423
|
|
| Back to top |
|
|
dg09
n00b
Joined: 24 Apr 2024
Posts: 11
|
| Posted: Mon Jun 03, 2024 4:15 am Post subject: |
|
|
Apparently we do.
While I do appreciate your input, all of this has already been pointed out multiple times throughout this thread, since your first response. It's perfectly clear by now that you don't see a point in such, and it is now also clear that you have much better things to do with your time. I get that, and that's cool. Not sure what you're trying to achieve by insisting several times that it is useless and giving such remarks regarding time and priorities though, especially after having said that you respect the decision and that fulfilling the desire of making it work is part of the beauty of Gentoo; that's surely not gonna stop me from trying to make it work nor mark the thread as solved. I did already say I may drop it eventually after some more tinkering, so again, kinda pointless to insist(?).
Thanks for the links, but I ran across them while looking for solutions; I am aware it is problematic, and I am also aware that it doesn't work for everybody. That doesn't mean someone here couldn't be of some help though, such as Ralphred who did provide some aid, and hence the post; unfortunately, his workaround did not work for my case, but he still provided useful insight regarding the issue at hand. As also noted already, rootless X is fully working on my other installation and on my other system, despite them being on a different distribution, but both with SDDM and KDE, so me trying to get it working on my Gentoo installation is not quite a waste of time nor a wrong priority for me. Regardless, once again, I appreciate your input  |
|
| Back to top |
|
|
cbxd
n00b
Joined: 07 Aug 2018
Posts: 4
Location: France
|
| Posted: Wed Jun 05, 2024 5:19 pm Post subject: |
|
|
Hi,
I came across your post while searching for a solution to another issue.
The issue you're having reminds me of another I faced a few years ago. Basically, the desktop session would not open until there was a keystroke or a mouse click. Eventually, it was resolved installing and enabling service haveged.
Please see the solution here: https://forums.gentoo.org/viewtopic-t-1087136-highlight-.html
Maybe I'm wrong and this does not have anything to do with the issue you're facing.
Regards,
Chris |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
