I don’t get this, my graphical interface is on tty1 and not tty7 as it is on every other SuSE/openSUSE box I’ve ever built (and I’m going back to SuSE 4 at least).
It’s a UEFI dual boot system with Windoze 10 and openSUSE Leap 42.3 and an NVidia GTX 970 graphics card.
I had real problems trying to install Leap 42.3 as it kept hanging at ‘starting udev’ and ended up installing 42.2 which worked and then updating to 42.3 via zypper dup.
I’ve got another PC set up as UEFI dual boot Windoze 10 and openSUSE Leap 42.3 which installed without a hitch (without the GTX 970) and that has the graphical interface on tty7
Have I managed to change some configuration setting by accident and how do I put it back?
Hmmm…just an idea (so apologies if I’m on the wrong track here)…how is ‘NAutoVTs=’ configured in /etc/systemd/logind.conf?
From ‘man logind.conf’
Takes a positive integer. Configures how many virtual terminals (VTs) to allocate by default that, when switched to and are
previously unused, “autovt” services are automatically spawned on. These services are instantiated from the template unit
autovt@.service for the respective VT TTY name, for example, email@example.com. By default, autovt@.service is linked to
getty@.service. In other words, login prompts are started dynamically as the user switches to unused virtual terminals.
Hence, this parameter controls how many login “gettys” are available on the VTs. If a VT is already used by some other
subsystem (for example, a graphical login), this kind of activation will not be attempted. Note that the VT configured in
ReserveVT= is always subject to this kind of activation, even if it is not one of the VTs configured with the NAutoVTs=
directive. Defaults to 6. When set to 0, automatic spawning of “autovt” services is disabled.
~> cat /etc/systemd/logind.conf
# This file is part of systemd.
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
# See logind.conf(5) for details.
And if you update to 0.17.0, the package will remove the default options from /etc/sddm.conf, which will result in exactly the file that has been posted, unless you explicitly added other options.
Should not matter, because those options are set in /usr/lib/sddm/sddm.conf.d/. But if you would downgrade again (42.3 comes with 0.14.0), the sddm.conf will not be replaced (because it is a config file), so you will miss those options then.
No idea if that’s the case here, but it would be one possible explanation.
Yes, I expected that.
But you wrote that these affected system are upgraded from 42.2.
Did you maybe use KDE:Frameworks5 (sddm 0.17.0) on 42.2, and then upgraded with only the standard repos (which would downgrade sddm to 0.14.0)?
That’s actually the only way your problem can happen IMHO.
I’m pretty sure there’s no bug in this regard when upgrading from 42.2 to 42.3.
I am/was intending to upgrade to Frameworks 5 (with sddm 0.17.0) once I was happy with the basic install.
This will fix your “problem” as well, as sddm.conf is not necessary anymore. (the shipped default config is in /usr/lib/sddm/sddm.conf.d/ and does set MinimumVT=7)
It was a basic install of 42.2 then set up the repositories for 42.3, adding Frameworks5 and Qt5 repos then zypper dup. I don’t think I even ran an update on the original 42.2 install, going straight on to the upgrade.
I’d had a couple of days failing to get 42.3 to install - hanging at ‘starting udev’ - so I decided to try installing 42.2 (which worked), and then immediately upgraded to 42.3
I assure that that’s what I did - I’ve no idea how things went awry, the main thing is they seem to be sorted now - so I’m happy to stop there
:\OK - one weirdo. While building the workstation it ended up sat on the floor of my (crowded) study as I was also building/configuring another workstation for my other half (who needs Windoze for work). While it was booting, I accidentally nudged it and the boot screen went from it’s usual friendly green to a virulent red as did the user login. I assumed I’d just moved the HDMI a bit because the system was fine once logged in. It was only after that that I noticed the tty problem but, then again, I hadn’t checked on it previously. Surely something like that couldn’t have had an impact.