SDDM. I remember there was something with the pacdiff -s after the Stable update on 23-07-10.
The sddm configuration file changed for me then. Did you do:
The [community] repository has been merged into [extra] and is now empty.
It may take a bit of time for mirrors to catch up (more details here 11).
Update your system and handle the pacman
sudo pacman -Syu "pacman>=6.0.2-11"
In order to remove the defunct [community] repo changes must be made to /etc/pacman.conf.
Changes will be provided in a file with the extension .pacnew 9.
Pacman provides the utility pacdiff to manage these files and will use vim -d for comparison if the environment variable DIFFPROG is not set.
If you would like to use a different comparison tool you may prepend the env var:
DIFFPROG=meld pacdiff -s
Then sync with the repositories again:
sudo pacman -Syu
… back then? If not, that might be the reason for your issues, but just my 2c, you can keep them, I might be wrong!
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’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.
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.
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.