SELinux blocks kwin_wayland access to nvidia modeset
I installed bazzite on my brothers desktop pc a few days ago through the nvidia open kde image. Most things run smoothly, but sometimes he gets kicked back to the sddm greeter after a few minutes. This only happens if the boot process takes longer than normally. Here is a journal of a boot where this problem happens
https://privatebin.net/?bdb03f3bfc7dab4e#3mguFkxecd8R5dmvs9cWCxfdUS2SxXPzAb7PnT3KAxMF
I noticed the line
AVC avc: denied { getattr } for pid=5037 comm="kwin_wayland" path="/dev/nvidia-modeset" dev="devtmpfs" ino=1013 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0
but I dont know if thats the root cause of the issue.
The only other problem was that the firefox flatpak often crashed during startup. It tried accessing /run/flatpak/wayland-0 display but timed out. The X11 display was not set for some reason (null) so it crashed. Im not sure if this is related, but I worked around it by layering firefox through rpm-ostree and this issue does not happen with the native version
Is something messed up with SELinux the issue here, or could it be something else?
Thanks for your helpPrivateBin
Encrypted note on PrivateBin
Visit this link to see the note. Giving the URL to anyone allows them to access the note, too.
131 Replies
Maybe similar issue for @Aragami @HikariKnight ?
looks identical
Can you verify that the file
/dev/nvidia-modeset is there once booted, i might need to actually make a custom script to fix this
also @Aragami are you also on the nvidia-open image? check with rpm-ostree statusSure, I can check later. Also nice timing. The crashes reappeared and I was about to reinstall Bazzite one of these days
@HikariKnight
hmm ok then its not specific to nvidia-open
Oh ok
Is there a way to fix it?
Ah, I just searched for SELinux in #🛟bazzite-help
I'll look it up when I get to his place tomorrow, sry. I didnt think you guys would be so fast! :P
i was referring to that the issue affects your brother and aragami only, so not a common issue
i would say try make a script with
and run that after boot and see if that fixes it. if it does i will have to try make something more automatic
also looping in @Kyle Gospo for awareness
Should it be run once or on every boot?
yes which is the annoying thing 🙃 we tried to make a service for aragami but its not as straight forward and we dont know if it will even fix the issue
Yeah. I always have to run
sudo /sbin/restorecon -v /dev/nvidia-modeset on every boot sadly. I'll reinstall bazzite kde someday for that reasonHm I looked a bit through your message history @Aragami . Looks like a really annoying issue. Did that really happen through a botched install somehow? I hoped such things wouldnt happen with fedora atomic
I don't know what caused it honestly. I have bazzite installed on an ssd alongside with windows 10. The 1st 2 weeks bazzite kde was working perfectly to me. And then, for some reason on the 14th day it started crashing (basically logging in and few minutes later it gets me to login menu again, and when I try to log in again, it's black screen only)
But running
sudo /sbin/restorecon -v /dev/nvidia-modeset on every boot prevents the crashand that keeps it working? since if it does i can look into making a workaround script since we didnt manage to get the systemd service to do it by itself properly (for context either the dev node doesnt exist, or it does not like the target)
Yeah, it keeps it working. That's how I keep using linux (cause I don't want to use windows more often than linux). Thanks for offering to look into making a workaround script. I really appreciate it :3
ok i will see what i can cook up after work today then and probably push to the testing branch so you both can test it ince its done.
that will be in about uh 8-9 hours or something
maybe 10, depends how much is going on at work today
ok so can whichever of you test this before i push it, i had to stay home for a bit for health reasons so i had time to work on it while things got sorted out
Please use
sudo nano /path/to/file in the terminal to make these files, do not use the graphical programs unless you know what you are doing. you can save the file with CTRL+X in nano
run sudo nano /etc/systemd/system/nvidia-modeset-restorecon.service and add this to it
then run this sudo nano /usr/local/bin/nvidia-modeset-restorecon and add this to it
then run sudo chmod +x /usr/local/bin/nvidia-modeset-restorecon to make it executable and then run it with sudo systemctl daemon-reload ; sudo systemctl start nvidia-modeset-restorecon ; journalctl -t nvidia-modeset-restorecon
if there are no errors from the service or the log, then you can safely enable the service with sudo systemctl enable --now nvidia-modeset-restorecon
if you do get any errors then post them here and i will adjust things until we have something workingWill do that in a few hours when Im at my brothers place. Thank you very much! I hope you'll get better soon @HikariKnight
if it fixes the issue and works i will put out a PR which once merged will add the service files to the system itself, once that is in a build i would recommend removing the service file made here and the script we made as it will be provided by the system then. just need to make sure it works before we actually add it
@HikariKnight There were errros
ok pretty sure the semanage command is not needed then since it was the recommended solution from the log itself, but the devicenode gets properly relabeled
i changed the script to reflect that.
change the script in /usr/local/bin then you can enable the systemd service we made then give me some feedback in a few days if it fixed the issue (or as soon as it crashes if it didnt fix it)
if it fixes the issue i will make a PR to get it included into the nvidia images
I changed it but the errors are the same
Right?
@HikariKnight
yep
journal will still show the error from 14:52:03
Oh dang, I didnt think of that XD
Sry
Will update if something happens ^^
Thank you very much for the help!
anyways at boot it should relabel the nvidia-modeset device node and you can verify it with
journalctl -b 0 -t nvidia-modeset-restorecon
that will show only the log from the current bootCool, no problem
He posted the solution already.
Oh thanks. I was just reading the messages
No problem ^^
Where is the solution posted?
Right here
Tl;dr: create two files and enable the service
Oh it works? I thought it was for testing
Looks like it. We rebooted a few times and it seems fine
Will do. 2 service files, right?
I hope it works for me too 😅
Hikari posted a pretty detailed description
I think one is a service the other a sceipt
Great, I'll check it out more closely in a bit
Also, I thought your temp fix also worked?
I only skimmed your message history though
@HikariKnight I wish you get well soon. I hope it's nothing serious
it is for testing, if it works i will make a PR so it gets added to the nvidia images
was just very low blood sugar so i had to stay home until i had stabilized it 🤣
The
sudo /sbin/restorecon -v /dev/nvidia-modeset? Yeah, still works. But it's pain having to run it on every single boot
Great, will keep you postedthe solution i made that you both are testing will automatically run it at boot
Oof, been there. Low blood sugar sometimes can get bad faster than I ever thought 😅
You're the best. Thanks a lot :3
once the solution is in the nvidia image you remove the service file from /etc/ and do
sudo systemctl daemon-reloadGot it
So after I run
sudo systemctl daemon-reload ; sudo systemctl start nvidia-modeset-restorecon ; journalctl -t nvidia-modeset-restorecon it says -- No entries --
Is it right?I think so
The first version of the script threw errors
Great. So I can proceed with the rest steps left
In my opinion, yes
yes
It worked!! I can't believe it worked. I'm so much happy!!! This saved so many hours cause I was seriously considering re-installing Bazzite KDE
So now I delete this file?
And then I run
sudo systemctl daemon-reload?sudo rm /etc/systemd/system/nvidia-modeset-restorecon.service
but dont do it until i get verification that the issue is gone from both of you and add a PR to get the fix addedNoted. I rebooted my system about 4 times. I won't remove the file for few more days. I'll keep you posted either if the issue reappears or not
For now, it's working
good to know
i got the PR readied so once i know for sure it works i will push it
Great. Thanks a lot ^^
Sooo, it happened again. The issue reappeared. I did a small change though. I put Wallpaper Engine and using it with Wallpaper Engine for KDE plug-in
The plug in was already installed though
@HikariKnight
@HikariKnight You probably want to check this out: https://access.redhat.com/solutions/5462521
Red Hat Customer Portal
GPU devices have wrong SELinux context after each server restart - ...
After each restart GPU devices have wrong SELinux context and can't be used as a consequence without restoring the context with restorecon. $ ls -Z /dev/nvi* crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidia0 crw-rw-rw-. root root system_u:object_r:xserver_misc_device_t:s0 /dev/nvidia1 crw-rw-rw-. root root system_u:ob...
If you can't access - the article states that the SELinux issue is a result of missing udev rules:
Which are supposed to be provided by the NVIDIA drivers
do you have those files?
@Aragami
Not on my bazzite-nvidia-open:stable install. Just the file
this one is provided by negativo17's nvidia-kmod-common
looking for uvm
I'll check right now
Seems they do this in the spec
this might turn into an issue w/ negativo then
GitHub
Issues · negativo17/nvidia-kmod-common
NVIDIA's proprietary driver kernel module common files - Issues · negativo17/nvidia-kmod-common
UVM seems tied to CUDA driver from my brief search. The CUDA driver was also mentioned in that Red Hat article (along with the standard driver)
Same
https://lists.rpmfusion.org/archives/list/[email protected]/message/Q3GQJQFFGZS6Q5D3NWP5BXL5KYANVBDF/
it appears this information is old/out of date
nvidia-uvm was intentionally removed
Oh... So it's not that the issue? Then what is?
If the uvm file is no longer needed, maybe it's just the
60-nvidia-drm.rules file that's missing?I'm not sure but I think folks on the subreddit are having similar issues
https://www.reddit.com/r/Bazzite/comments/1fiucg6/getting_kicked_to_other_tty_after_login_desktop/
Seems related: https://forums.gentoo.org/viewtopic-t-1162236-start-0.html
So question - What monitors do people experiencing this problem have?
I was having this issue, and I managed to resolve it by keeping my ASUS gsync monitor off until after I login via SDDM. My ASUS monitor has a lot of issues with waking up after display off, and flickered for quite a bit if I were to leave it on during login.
I assume the issues with screen wakeup on my monitor were causing some kind of reload/reset with the NVIDIA driver
LG C3 4K 55” TV.
Ooof
I have an Asus monitor with freesync turned on
The issue occured on my brothers machine again as well
He has some kind of HP monitor, I think with freesync. I'll send the exact model name in a bit
For me it crashed only 1 time. I booted the PC 2 more times without running any commands and it didn't crash
The model I have is ASUS VG245Q
Mine is a VG27A
But yeah, this is reliably reproducible for me:
I have only ever seen this issue if I have my Asus monitor on before I login via SDDM, granted it doesn't happen always when it's on, maybe ~50-80% of the time. However, it happens 0% of the time if my Asus monitor is off.
Adjusting/disabling VRR from KDE or at the monitor level has no effect, issue can still occur.
I see. So it a monitor issue after all?
¯\_(ツ)_/¯
The monitor is DisplayPort stamped (implies VESA certification) and UL certified. And it also did not cause crashes on Windows - This inclines me to say it's a driver or OS config bug.
I see. I hope there's a solution to this
would not surprise me this is an nvidia driver issue at this point
any logs from the crash that still happens?
I do recall seeing the same error Lachsak posted, comparing logs from when the issue occurs vs ones where it doesn't. It'll be a bit before I can grab a fresh set of logs, using my machine for work stuff right now.
I haven't seen my logs. But I remember that when I sent my logs it was the same error
Log from a boot/login with the issue (i.e. my Asus monitor was on at SDDM login): https://privatebin.net/?ae7588f961b6ef57#77XWCjjhED7S5n5gKLuGjdBLbfK1pRG4uhfWwmKgmD1s
PrivateBin
Encrypted note on PrivateBin
Visit this link to see the note. Giving the URL to anyone allows them to access the note, too.
Log from a boot/login with the monitor off and no issues: https://privatebin.net/?04c8765909560132#4p2W34aQfCGNYz3zjwuu6PdMLRhCP2MUdW8A7PJad23A
PrivateBin
Encrypted note on PrivateBin
Visit this link to see the note. Giving the URL to anyone allows them to access the note, too.
glanced at it before heading to work, there is nothing that stands out, sddm just crashes when it tries to load the desktop from what i gather from the log
Well, business as usual then .-.
I swear, every time there is an issue its novideo drivers
Probably a shot in the dark, but I had a similar but not identical issue. Im using a different distro (NixOS) and didn't have this issue since using early kernel modesetting. I wanted to try that out as well on my brothers machine, but didn't even know if bazzite already does that, and if not, how to get it working with rpm-ostree
its a likely suspect when we cannot replicate the issue on machines with amd or intel cards and the only difference between the images is the nvidia driver (and the inclusion of x11 for now), does not leave much for imagination when the issue happens on both x11 and wayland.
what i would be curious about is if this can be replicated on the gnome image to see if this is a sddm+nvidia issue 🤔
since so far we know
* happens on nvidia
* potentially related to VRR
* happens with both x11 and wayland
* not caused by selinux (error was apparently a red herring?), but does help alleviate the issue
i would still like to see a log with the crash on a system with the selinux workaround applied though before ruling out the last point
Huh funny, was having this issue today and was almost impossible to use because it was always kicking me to sddm login again. But then when i turned on my computer and the monitor was off and turned on after it had booted (accident, i forgot my monitor turned off becaused i had shut down my computer) it just booted normaly and didn't crash
Also this also happens on Kinoite-nvidia image, tested yesterday
Interesting question
F
Is it safe to update yet?
Literally waiting for crash logs with the fix applied since someone said it happened even with the fix we are trying.
Sry, I collected some from my brothers machine yesterday evening
If we havent selected the wrong boot, this should be a log with the cerash
And that one was after the Selinux workarounds
@HikariKnight
cant see anything that sticks out, but i will have a look closer when im not sick
Thanks for all the help!
And sorry for the delay
Get well soon ^^
ty
confirming that the workarround fixed it for me
i have opened a PR to testing to get it added to the image, just need it to be properly tested there first
I'm sorry, I couldn't check for crash logs these days. Let me know if you need mine as well
Hopefully it will work. Thanks for the help. Hope you get well soon :3
I've some free time and willing to test any configuration you'd like. 2070 Super.
I'm extremely sick atm so not anytime soon. 🙃
Hopefully will have some time today to test the scripted/service fix
Tried setting up the SELinux script/service. Still got the issue, found this line in the journal:
Sep 24 19:46:42 beanzy-desktop systemd[1]: nvidia-modeset-restorecon.service - Runs restorecon on nvidia-modeset at boot was skipped because of an unmet condition check (ConditionPathExists=/dev/nvidia-modeset).
Only line referencing the nvidia-modeset-restorecon serviceDo you still have the issue when using ostree: 1, or only ostree: 0?
Isn't that dynamic, depending on updates?
Yes it is
I read someone say on reddit that it only happened on 0, I had it on both.
I always boot on ostree: 0. I didn't know what the other options were
0 is your current deployment, 1 is for rollback
For rollback? Meaning? Sorry if it sounds like a stupid question. English isn't my native language
If the current deployment is not working or you are unable to boot, the secondary image is the "rollback" image which is the previous, working image. Whenever you update Bazzite, your current deployment then becomes the rollback (image 1) and then the new updated image is image 0.
Oh cool. Thanks a lot for the info
Sorry to barge in here like this, but i'm the OP of the reddit post.
The Issue was not tied to OsTree:0, it seems that rebooting temporarily solved the issue until the next (cold) boot and I misinterpreted that as "OsTree:1 works fine" - absolutely my bad, should have tried a simple reboot without switching the tree as well 😅
This issue right here is tied to nvidia drivers, and pretty unrelated to which OStree deployment is selected, I think?
In short, boot process takes forever and kicks you back to SDDM
Also, I finally got a log with the workaround applied and a confirmed crash to SDDM happening
Exactly that, yes.
But if you witch to TTY3 after getting kicked back to the greeter, you can kill the session on TTY2, switch to TTY1 and log in again. This time with a working Session that will not self terminate.
Which - to me at least - is super weird. I'd expect a driver issue to be persistent and not sort itself out after on hickup.
Huh, didnt know that
I found that by poking around in loginctl the other day.
From what I understand, It seems like the intended behaviour of KDE is :
Spawn Greeter on a TTY
Auth the user > spawn Desktop on another TTY, transfer User to Session
Kill Greeter
I noticed that after i get kicked back to the Greeter, there will be 3 Sessions (including my Session on TTY3)
TTY1 : User : SDDM - State : Online
TTY2: User : Me - State : Closing
TTY3: User : Me - State : Active
After killing the Session on TTY2 (and 3) and logging in again, there will be only one Session
TTY2 : User : Me - State : Active
There are screenshots in a issue over on Github
https://github.com/ublue-os/bazzite/issues/1704
GitHub
[NVIDIA - STABLE] Getting kicket back to SDDM Greeter after login ·...
Describe the bug After login, i get kicked back to the Greeter/Lockscreen located on TTY1. If i try to login again, the Desktop won't load / the screen stays black. What did you expect to happe...
Is there a way to fix it?
I'm facing this problem now.
Am I get it right that problem will not appear if I turn off my primary display (with freesync) while booting?
apparently
What a bizarre workaround lol. Well, hope it'll fixed soon, whatever causes it.
Because of that I've reinstalled it twice.
And reinstalled W10 twice, god that was a nightmare.
Thanks you all here!
Can I help it tho?
By providing logs or smthg
seems to be an nvidia exclusive issue so probably nothing we can do in the end
as we have already tried fixing what the logs complained about (selinux type enforcements) and that seemed to not fully fix it
I haven't tested it
That makes me hate Nvidia more than I ever thought I could 🥲