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
QuoteNormally, 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.
Quote... 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?
* Drop patch 03_vt7-minimum-vt.diff and switch back to upstream default of
spawning greeter on VT1.
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
I can confirm the behavior. But to me it looks like Alt-F2 has taken over the function of Alt-F7. Strange...
Your finding
* 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!
Quote from: samoht on 2023/06/27, 14:14:31
Quote... 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.
Quote... 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
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)?!?!
That all has nothing to so, with the kernel, the change is in sddm 0.20.
QuoteMaybe we should look there (and change the topic)
Definitly!
Quote from: towo on 2023/06/28, 13:16:33
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.
Would be nice if there was a way to get back the old behavior of sddm, whether in config or startup options.
Quote... 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 (https://github.com/sddm/sddm/releases/tag/v0.20.0)
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?
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.
cat /lib/systemd/system/sddm.service
[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
# Change this if you want to start sddm in a different tty
Conflicts=getty@tty1.service getty@tty7.service
After=getty@tty1.service getty@tty7.service
After=systemd-user-sessions.service systemd-logind.service
# Workaround entropy starvation
After=haveged.service
# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service
[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStart=/usr/bin/sddm
Restart=always
RestartSec=1s
EnvironmentFile=-/etc/default/locale
[Install]
Alias=display-manager.service
But be careful with the axe, ...
Quote from: hendrikL on 2023/06/29, 13:30:14
cat /lib/systemd/system/sddm.service
[Unit]
Description=Simple Desktop Display Manager
Documentation=man:sddm(1) man:sddm.conf(5)
# Change this if you want to start sddm in a different tty
Conflicts=getty@tty1.service getty@tty7.service
After=getty@tty1.service getty@tty7.service
After=systemd-user-sessions.service systemd-logind.service
# Workaround entropy starvation
After=haveged.service
# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service
[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStart=/usr/bin/sddm
Restart=always
RestartSec=1s
EnvironmentFile=-/etc/default/locale
[Install]
Alias=display-manager.service
But be careful with the axe, ...
Ugh that gets messy with that axe...
More interesting for me is, why the hack on vt2 i see the graphical login, greyed out, and i am not able to do there something!
Ok it is blocked by xorg, if I read following correct,
sddm.service - Simple Desktop Display Manager
Loaded: loaded (/lib/systemd/system/sddm.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-06-29 14:19:52 CEST; 18min ago
Docs: man:sddm(1)
man:sddm.conf(5)
Main PID: 765 (sddm)
Tasks: 7 (limit: 14181)
Memory: 131.8M
CPU: 827ms
CGroup: /system.slice/sddm.service
├─765 /usr/bin/sddm
└─843 /usr/lib/xorg/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_reMTJv -noreset -displayfd 16
...
I am asking me, why, if the sddm authentication is on vt2, the graphical target is, after successful login, on the next vt (vt3) or if I want on vt7 and not vt2,
So I have a graphical artefact on vt2 when I am working with the GUI, this little thing I do not understand.
First try:
# Change this if you want to start sddm in a different tty
#Conflicts=getty@tty1.service getty@tty7.service
#After=getty@tty1.service getty@tty7.service
Conflicts=getty@tty1.service
After=getty@tty6.service
My idea was to recover my well known behavior
* systemd output on tty1 -> reached by Ctrl-Alt-F1
* tty2-tty6 for login on console -> reached by Ctrl-Alt-F2-6
* to jump back to graphical interface with Alt-F7
But no luck:
* systemd output still on tty1 -> as expected
* SDDM still "sits" on tty2 -> boo
* tty3-tty6 free -> better than nothing
* to jump back to graphical interface with Alt-F2 -> boo
Any better idea?
not this way.
if you want tty1 (vt1) "free" remove conflict and after getty@tty1.service. Then you have vt1 to work on if you want. and if you want the graphical target on vt7 remove that too, but if that is useful? Maybe it is the best way to shoot yourself in the foot.
I DON'T RECOMMEND TO DO THAT!
I made some tests with wayland.
If you have DisplayServer=wayland in the sddm.conf (see man sddm.conf),
it is the best choice to let it as it is or you have to start your graphical session with startx, startplasma-wayland, startplasma-x11 (sddm didn't start), what else going wrong I don't know.
@
I am thinking, that in an installed system, the closest thing you can do to achieve
QuoteMy idea was to recover my well known behavior
* systemd output on tty1 -> reached by Ctrl-Alt-F1
* tty2-tty6 for login on console -> reached by Ctrl-Alt-F2-6
* to jump back to graphical interface with Alt-F7
would be to actually start 6 ttys at boot-time by via:
QuoteTo add another pre-activated getty, enable and start getty@ttyX.service.
for X in 1 to 6.
For this, it is not even necessary to modify any sddm-setting, it should automatically use tty7/the next tty.
If you do not get a greeter-window, it may be necessary to increase the value of NAutoVTs in /etc/systemd/logind.conf, I did not try it, thus do not know about this. It may also be, that sddm "keeps" tty7 and your graphical desktop becomes tty8.
Hi all
Today I noticed the same changes happening in my Tumbleweed install. (KDE + sddm)
tty7 --> tty2 and the need to use tty3 instead of tty2 for updates.
At this point I see no reason to be concerned over the changes. I'm just going to have to get used to using tty3. I'm not having any problems with the changes, and, those boot freezes and shutdown problems that some of us blamed on kernel oops seemed to have resolved themselves. Unless some other problems arise ... If it works, don't fix it. :-)
Tom
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hallo zusammen
heute habe ich die gleichen Änderungen bei meiner Tumbleweed-Installation (KDE + sddm) festgestellt
tty7 --> tty2 und die Notwendigkeit, tty3 anstelle von tty2 für Updates zu verwenden.
Zum jetzigen Zeitpunkt sehe ich keinen Grund, mir wegen der Änderungen Sorgen zu machen. Ich werde mich einfach an die Verwendung von tty3 gewöhnen müssen. Ich habe keine Probleme mit den Änderungen, und die Probleme beim Booten und Herunterfahren, die einige von uns auf Kernel-Oops zurückführten, scheinen sich von selbst gelöst zu haben. Es sei denn, es treten andere Probleme auf ... Wenn es funktioniert, sollte man es nicht reparieren :-)
Tom
I agree with @GoinEasy9 that there is currently no reason for me to change the situation. ,,Raider is now called Twix - nothing else changes'' And tty7 is now tty2. I can live with it, as I'm sure most users can.
Ich halte es wie @GoinEasy9. Aktuell gibt es für mich keinen Grund, an der Situation etwas zu ändern. ,,Raider heißt jetzt Twix – sonst ändert sich nix'' bzw. tty7 ist jetzt tty2. Ich kann damit leben, wie sicher auch die meisten Anwender auch.
edlin
I can live with this change and I find it not really a big deal. Wonder what's the rationale behind this particular change.