is there any way to check after the fact?
dnf list –installed x11-driver-video-amdgpu
One other thing you could try is to start the system as normal, switch to a VT, stop sddm, and just type startx and see if the session stays alive.
My guess is that the card and mesa are not happy. You might need to use wayland if that works, until @bero or someone else can assist with it.
ok, so the first command gave me (after I fixed the - to a – (thanks auto characters lol))
x11-driver-video-amdgpu.znver1 23.0.0.6-1 cooker-znver1
in bright green
so I assume that means it installed properly.
which would be
sudo systemctl stop sddm
then just startx
When I switch to tty2 manually after GUI log-in the DE stays live (I actively timed it for 20min and it has sat for much longer) So if I do the startx, how will I know the difference?
I have done so but (moron here) then I decided to check which tty it was on so if there would have been a noticable difference I just made it irrelevant, I’ll reboot and do it again lol
Wait, I think I get it now.
I restarted normally, logged in from GUI, let it switch to tty2 after the 30sec.
Then I manually switched to tty3, logged-in, stopped sddm, startx
Seems to be staying live on tty3
I can just manually switch anyway. It just means I will have to remember not to wander off to make coffee when I boot up while I’m still 1/2 sleep in the morning. (Or if I do, just reboot again anyway)
So long as there are no other issues this might generate until this is solved it should be fine. I don’t need to worry about games in the meantime. The only other things I might need a fully operational GPU for are a couple of map-making flatpaks that use the GPU and a Appimage program that uses gpu acceleration, but they can probably wait for a month or two also.
I’m gonna go ahead and set this up in my study and.
- connect my good monitors
- install daily necessities
- Try those apps I mentioned
- see if I can get my speakers working (gonna need HdaJackRetask or similar)
And see what happens.
If it stays in the GUI without you switching to a TTY or stopping sddm, then it should be fixed.
Just a tidbit. My problems are mainly with sddm not KDE. I generally, whenever I install QT based desktops have to remove sddm, and install lightdm as the login manager it tends to fix the problem. I do not know why my computer does not play well with sddm but it just does not.
I think I got a bit confused at one point there.
I’m going to rephrase the odd behaviours using a bit of what I have learned so far.
Then I will rephrase the question I was trying to ask here
The odd behaviour
After starting OMLx from Grub
- The DM Log-in screen loads on terminal 1
- After logging in from that screen, the display stays on terminal 1 with blinking cursor, while sddm loads on terminal 2
- If I then switch manually to terminal 2 within 30 sec, the DE session stays running stably.
- If I don’t switch manually, after 30 sec the system automatically switches to terminal 2 with DE running, but it then crashes after 1 min. The screen goes black, no cursor or anything.
- After another 30 sec, the DM log-in screen comes up on terminal 1 again, but it only stays there for 5 sec before crashing to the blinking cursor.
-If I log in from that screen, within the 5 sec, the whole cycle seems to repeat from the initial GUI log-in screen.
-If I do not log-in within that 5 sec window, either no inputs work or all the terminals all have the same blinking cursor.
New details. These were from me trying to follow this
- Immediately after loading from Grub. If I don’t log-in from the GUI and instead switch directly to terminal 2 and log-in from there. Then do
sudo systemctl stop sddm, thenstartx, the DE loads and remains stable (at least 2 min) (note: rebooting from Konsole from here seems to take waay too long). - After loading from Grub, If I log-in from the DM/GUI.
-If I then switch to terminal 3 (instead of 2) and log-in, thensudo systemct stop sddm(within the 30sec window), thenstartx, the DE loads and remains stable on terminal 3.
-If I don’t log-in and stop sddm within 30sec, the system automatically switches to Terminal 2, then crashes, etc.
When I asked this question
It was in reference to
I was trying to ask.
How do I tell the difference between
-Switching manually to the DE on terminal 2 after logging-in from the DM/GUI. (Which leads to the session staying live)
and
-Logging-in from a different terminal (3), then stop sddm then startx. (Which leads to the session staying live.
I think I have misunderstood something here.
That sounds like it would be an easy fix.
I’m not sure it will work though. ROME Plasma6 znver1 build 4271 (from before the latest update) ran without issue, and it was using sddm also unless I’m mistaken.
I will happily try it though, if it can eliminate possibilities. I will need to get directions though.
EDIT: I think I might have seen instructions for something similar in here somewhere.
Let’s simplify then. The goal is to get it to stop killing the session. x11-driver-video-amdgpu is supposed to fix that. If it did not fix it, then it’s still a problem.
sddm is buggy, anyway. It will put the graphical session on any VT it wants, whenever it wants. If the session stays alive after you manually run startx then the problem is most likely sddm you will want to verify you can do 3D accelerated things in that startx session. For the time being, you can also do this before startx until the issue can be nailed down:
sudo systemctl disable sddm
It will mean you have to manually start sddm in the future for testing, but it will save you a step. We should also begin a log collection process that is outlined in the support template since your software and configs have changed.
Hey again @zeroability .
First, you must have been up suuper late last night. I hope you’re not destroyingyour sleep patterns on my account.
Switching manually to VT2 (instead of waiting for it to switch automatically after 30 sec) stops it killing the session anyway. This seemed to me like it would be relevant, but it seems you don’t think so, so I will ignore it from now on.
I started the dsync process last night as described here
$ sudo dnf clean all ; dnf clean all ; dnf repolist
$ sudo dnf distro-sync --refresh --allowerasing
After the dsync command it said it was going to remove
x11-driver-video-amdgpu
So i said N to the update. I don’t know if this is relevant, but it might be so…
-Manually running startx does keep the session alive also.
-Are there any 3d accelerated programs available through dnf that you can recommend testing with. (I am assuming this would be better than running flatpaks)
I have just done this.
By “log collection process” I think you mean collecting logs progressively, as in one after each boot or something.
I couldn’t find anything in support template; support template in details; the Resources/Resources Index; or the wiki, about doing this (I’m probably just blind) so I assume it would just be a matter of doing them manually (journalctl > journlctl.txt) at appropriate times.
If that progressive logs “process” is what you’re after, would I be better off reinstalling again first. Then doing nothing to the system other than specific instructions, and collecting logs at each boot or as directed?
I may be better off moving it back to the work room and using the basic HDMI monitor also. My dual DP monitor setup in here is also, occasionally, doing odd things where one of the monitors isn’t loading the wallpaper, so eliminating them might make this easier for you guys. On the other hand, I’m guessing this is probably also related to sddm, so it might be better to use these monitors for the sake of more info in the logs.
EDIT:
Should I just try swapping to lightdm (as mentioned above by @pastorczo13 and see if it fixes things
Wait, I think I might be an idiot.
sddm is an application isn’t it (duh)
Which would mean the bit in “Support Template in Details” here
would be relevant to a “log collection process”
Is that what you meant?
I just downloaded FurMark
And the benchmark and stress tests seem to run fine.
One odd thing, the benchmarking presets didn’t like my second monitor being active, complaining about the resolution being 5120x1440, but I can’t remember if that was normal for FurMark or not.
Rumble videos play ok too
As does an m4v file.
Don’t worry about updating until the next UM, because we update ROME in batches of software. By then, the version will be correct.
Normally the second monitor issue will present itself with a bunch of applications, such as sddm especially if it’s on HDMI or a cheaper monitor with really bad EDID or HDCP. That’s not just a Wayland/X11 thing, either. I have seen set tops and Windows PC’s also have resolution and refresh rate detection issues and confusions with running applications. Unplug the second monitor and see if you can reproduce any of the problems with the session restarting.
Right on cue, there will be comments…
“This doesn’t happen on the mainstream distro I use.”
They have fiduciary responsibilities to people that they took money from. Which means many of the core things they do suffer regressions when they add new “features” and they have to patch the fixes in with other “features” so it doesn’t look bad on them (coughcoughwayland).