Yeah, I was just curious more than anything, whether it’s on tty1 or tty2 doesn’t affect me personally.
I might poke at it further if/when I have the time. The code path for selecting the VT seems fairly straight-forward at first glance (famous last words) so I think it shouldn’t be too difficult to trace exactly why it’s selecting tty2.
What I’m finding odd about this is that the only time it causes problems is during the first Plasma session after booting. Logging out then back in again allows autostart GUI programs to run OK. Even with $DISPLAY hard-coded (which one of the devs considers “a bad thing” and the reason for the problem). It makes me wonder if the TTY thing is a red herring and there’s actually some other change in there causing problems.
I’ve played around with this some more and turns out it’s the AMD microcode image. If I boot without it, everything is fine. If I boot with it, I get the kernel panic.
I’ve tested the Arch amd-ucode package (20230625.ee91452d-5) and it works for me. Seems like the Zenbleed mitigation is also contained in their older(?) version, so it might make sense to roll back @philm.
I can’t be the only one with this issue.
I vaguely remember some people having similar problems with previous amd-ucode updates + newer kernels if they were using an older motherboard BIOS. Is yours up to date?
I’ve done a little more testing to check the theory that hard-coding the DISPLAY variable is the problem and can confirm that it isn’t.
I removed all references to DISPLAY in my startup scripts and .profile/.zshrc, reverted to 0.20 and rebooted. Again, GUI programs failed to run. Firefox throws an error:
Error: no DISPLAY environment variable specified
Interestingly, logging out and back again still has everything working as it did previously. The Firefox startup script is now reporting $DISPLAY as :0 (as opposed to what I was setting, :0.0.
Going back to 0.19 and rebooting, no autostarted GUI programs work: again due to no DISPLAY variable being specified. At least proving that one way or another they have to be given that environment variable.
I do now think that your problem is probably nothing to do with ttys and is more likely caused by other changes made to address bugs/security issues between 0.19 and 0.20. That’s one for the developers to answer.
Regarding the autologin I use, I think it works, but since user session is now started on tty2, I’m sometimes left on tty1 even though the session on tty2 logged in automatically.
At the very least it should auto switch to tty2 every time, instead of only sometimes.
That’s a known bug, there are numerous reports of switching issues on the sddm github repo. It even happens without autologin sometimes if you use rootless x11 (because that starts on VT1 and then switches to VT2, or is supposed to).
Will hopefully get fixed as a priority now that 0.20.0 is released, otherwise slower-paced distros like Ubuntu will have the same problem when they upgrade.
Says there only 3 versions are affected. So I guess good news for me as I had reverted back from 6.1.39 when I didn’t like that peak.
Please, please, update right
Unfortunately, 6.1.41-1 is also affected — I’m running it here right now. But as stated, it’s a cosmetic issue; the load is not actually going up, and the pertinent CPU core’s temperature also stays within normal parameters.
Still works here with the icons-only task manager. Check the task manager settings. It normally offers three options…
Alphabetic sorting
Manual sorting
No sorting
If the latter is selected, then one cannot move the task manager entries around by hand. They will then appear on the task manager in the order they were started.