[EN] New SDDM -- NOT Kernel 6.3.9-1 -- Another new behavior

[dibl]

There are a couple of reports on the DE side of "Ooops" events with this new kernel. This morning I observed another new behavior, and because I saw it on two different desktop systems, I thought it should be reported here.

After booting the system to the KDE/Plasma desktop, and checking the news and forum in the browser, I downloaded all available updates and logged out. Normally, I can use Ctrl-Alt-F2 to open TTY2 and log in as root there, then use systemctl to change to runlevel 1 and install the upgrades. This morning Ctrl-Alt-F2 was dead -- no response of any kind. Ctrl-Alt-F3 worked correctly, and of course that is just as functional to change to runlevel 1, so I thought maybe there was an F-lock or keyboard issue, and finished updating that system. However, when I went to update the second system, Ctrl-Alt-F2 was dead on that one also. Again, Ctrl-Alt-F3 worked as expected, and I was able to finish with updates.

On both systems, after I was logged in as root to TTY 1, then TTY 2 worked as expected and offered me the login prompt. So possibly there is some change in the transition to the graphical.target (it might be systemd and not a kernel issue ....).

Both of these desktops use Intel CPUs and Nvidia graphics, but the motherboards and other components are not the same. Here is one of them:

System:
  Kernel: 6.3.9-1-siduction-amd64 arch: x86_64 bits: 64 Desktop: KDE Plasma
    v: 5.27.5 Distro: siduction 22.1.2 Masters_of_War - kde - (202303151559)
Machine:
  Type: Desktop Mobo: ASUSTeK model: ROG STRIX X299-E GAMING v: Rev 1.xx
    serial: <superuser required> UEFI: American Megatrends v: 1401
    date: 05/21/2018
CPU:
  Info: quad core model: Intel Core i7-7740X bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 4274 min/max: 800/4500 cores: 1: 4502 2: 3489 3: 4300
    4: 4503 5: 4502 6: 4300 7: 4300 8: 4300
Graphics:
  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nvidia v: 525.105.17
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia
    resolution: 1: 1920x1200~60Hz 2: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 NVIDIA 525.105.17 renderer: NVIDIA GeForce GTX 1060
    6GB/PCIe/SSE2
Audio:
  Device-1: Intel 200 Series PCH HD Audio driver: snd_hda_intel
  Device-2: NVIDIA GP106 High Definition Audio driver: snd_hda_intel
  API: ALSA v: k6.3.9-1-siduction-amd64 status: kernel-api
  Server-1: PipeWire v: 0.3.71 status: active
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: br0 state: up speed: 1000 Mbps duplex: unknown mac: <filter>
Drives:
  Local Storage: total: 4.1 TiB used: 841.78 GiB (20.0%)
  ID-1: /dev/nvme0n1 vendor: Kingston model: OM8PCP3512F-AB size: 476.94 GiB
  ID-2: /dev/sda vendor: Western Digital model: WD2003FZEX-00SRLA0
    size: 1.82 TiB
  ID-3: /dev/sdb vendor: Western Digital model: WD2003FZEX-00SRLA0
    size: 1.82 TiB
Partition:
  ID-1: / size: 62.44 GiB used: 11.4 GiB (18.3%) fs: ext4 dev: /dev/nvme0n1p4
  ID-2: /boot size: 1007.9 MiB used: 108.2 MiB (10.7%) fs: ext2
    dev: /dev/nvme0n1p3
  ID-3: /boot/efi size: 511 MiB used: 152 KiB (0.0%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 370.45 GiB used: 74.16 GiB (20.0%) fs: ext4
    dev: /dev/nvme0n1p5
Swap:
  ID-1: swap-1 type: partition size: 34 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p2
Sensors:
  System Temperatures: cpu: 34.0 C mobo: N/A gpu: nvidia temp: 35 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 0%
Info:
  Processes: 294 Uptime: 6m Memory: available: 31.27 GiB used: 3.3 GiB (10.6%)
  Shell: Bash inxi: 3.3.27

[samoht]

Normally, I can use Ctrl-Alt-F2 to open TTY2 and log in as root there, then use systemctl to change to runlevel 1 and install the upgrades. This morning Ctrl-Alt-F2 was dead -- no response of any kind. Ctrl-Alt-F3 worked correctly

@dibl, I completely corfirm this behaviour.

... after I was logged in as root to TTY 1 ...

How did you do that? 
I cannot login to TTY1, TTY2, TTY5.

Maybe, the new sddm release is the reason?

Code: [Select]

 * Drop patch 03_vt7-minimum-vt.diff and switch back to upstream default of
    spawning greeter on VT1.

[edlin]

WTF - I have the same situation here. Currently I can't get to TTY2 with Ctrl-Alt-F2!
I have never experienced this before.I can't reboot at the moment to explore more, but the behaviour is not normal.

edlin 

[orinoco]

I can confirm the behavior. But to me it looks like Alt-F2 has taken over the function of Alt-F7. Strange...

[ro_sid]

Your finding

Code: [Select]

* Drop patch 03_vt7-minimum-vt.diff and switch back to upstream default of
    spawning greeter on VT1.might explain this already, and if so, it has nothing to do with the kernel.

I first experienced this (and hate(d) it) on Ubuntu, namely:

• VT1/"F1": (graphical) screen for the display manager/greeter
• VT2/"F2": graphical desktop login, becomes unusable if not exited completely - this is, what you might have experienced, just before the update.
• VT3-.../"F3-...": No greeter/login prompt here, until you "select" that vt, e.g. by alt-ctrl F3. Have a look with "ps", where getty logins are already started. Probably none "behind" vt3.

In the "old" way (vt7), all consoles/gettys from vt1 to vt6 where started already. I liked this a lot better, because if there is a problem, a new getty (to log in to) will/might not be started - too late!

[dibl]

... after I was logged in as root to TTY 1 ...

How did you do that?
I cannot login to TTY1, TTY2, TTY5.

Before today, TTY1 was not directly available from sddm or the desktop. But, if I did Ctrl-Alt-F2, log in as root and issue "systemctl isolate multi-user.target && exit", then Ctrl-Alt-F1 gave me TTY1 and that is where I ran the full-upgrade.

[samoht]

... I did Ctrl-Alt-F2, log in as root and issue "systemctl isolate multi-user.target && exit", then Ctrl-Alt-F1 gave me TTY1 and that is where I ran the full-upgrade.

Thanks, @dibl, I have not tried launching TTY1 for a long time.

In runlevel 3 TTY1, ..., TTY6 are still accessible

[orinoco]

Correct me if I'm wrong. I remember the old days where /etc/inittab was responsible for tty. I lost grip since systemd. Maybe we should look there (and change the topic)?!?!

[towo]

That all has nothing to so, with the kernel, the change is in sddm 0.20.

[samoht]

Maybe we should look there (and change the topic)

Definitly!

[dibl]

That all has nothing to so, with the kernel, the change is in sddm 0.20.

Got it -- thank you towo -- Title fixed on OP.

[DeepDayze]

Would be nice if there was a way to get back the old behavior of sddm, whether in config or startup options.

[samoht]

... way to get back the old behavior of sddm ...

Maybe there is a knowledgeable person here who understands this changelog (search for TTY)

https://github.com/sddm/sddm/releases/tag/v0.20.0

[ro_sid]

At this time, I have no "installed" siduction installation, but am using siduction by starting the iso-image and "dist-upgrade" it to the latest state. Thus a modification/configuration will not "work" for me - too late in the process after start-up.

But I did find out the following:

• According to the changelog, MinimumVT is gone! It was held active by Debian with a patch, that was now removed.
  Thus this will not/should not work any more. At least not by configuration. I do not now, if the Debian-patch could be re-applied, but it would mean "our own" sddm-binary, if so.
  
• On the other hand in the Link given by @samoht there is a line:
  Introduce SDDM_INITIAL_VT as the TTY to reach out to
  

Someone willing to try and play with SDDM_INITIAL_VT in the configuration?

[eriefisher]

I gave up on SDDM long ago in favour of LightDM. I get why it's used with the KDE desktop but I've always found it buggy and troublesome. LightDM has always been rock solid for me and since I don't use KDE It's a no brainer.