On current Tumbleweed w no longer shows where users are logged in:
bruno@LT-B:~> w
12:56:41 up 9 min, 1 user, load average: 0,34, 0,37, 0,22
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
bruno - 12:47 9:35 0.02s 0.02s /usr/libexec/gnome-session-init-worker gnome
bruno@LT-B:~>
This happens on both Gnome and KDE; on Leap 16.0 the relevant TTY is still shown (for instance tty3 for the first KDE user, tty2 for the first Gnome user.
Anybody pointing me to where the change occurred?
(BTW, trying to diagnose a problem where switching to VT1 makes it impossible to switch back to any other VT, but the system looks otherwise working correctly.)
Thanks, but the problem is not how to find the relevant tty (after all there are only 6 or 7 to check) but if there was any recent major change in the way VT1 (or VTx in general) is managed.
Wondering if anything related might be at the roots of unstable-tumbleweed-last-7-days.
Some time ago, I ran into an issue with “uptime”, but “w” still worked. I reported it as a bug.
As I recall, this was only a problem if using GDM, but everything was fine with SDDM. The explanation given was that the data base “utmp” was being deprecated. I think this was because of concerns about the 32 bit times used, and the replacement was using 64-bit times.
I’m guessing that what you seeing is part of a transition to the new database.
No idea about recent, but IME, VT1 has always been quirky, latent or otherwise, not exhibited by other VTs. Thus, the only time I use VT1 for more than glancing at boot messages is when booted to single. 2-6, if not more, when not tied to a DM and/or GUI session, all behave without surprises.
I have no idea if this was already earlier, but at least since my upgrade Leap 15.6 > 16.0 (and the switch to Wayland). my main graphical screen is at VT1
henk@boven:~> w
18:31:47 up 9:43, 1 user, load average: 0.20, 0.38, 0.26
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
henk tty1 - 08:49 9:43m 0.27s 0.27s /usr/bin/startp
henk@boven:~> who
henk seat0 Jul 21 08:49
henk tty1 Jul 21 08:49
henk@boven:~>
Ten reboots without plymouth and VTs switch correctly, including VT1.
Two reboots with plymouth and two stuck on VT1 once switched to it.
This is enough for me to wait for a fixed plymouth without further digging; given that plymouth usually “lives” on VT1 makes it the perfect culprit.
library
version: inc revision to 1 now 1:1:0
internal: Use openat for files under /proc/
internal: Don’t check for sd_booted Debian #1108549
internal: Address potential race leading to segfault issues #380, #390
local: guard SIGPOLL for MacOS merge !246
.
.
.
w: Add terminal mode to show all terminal sessions issue #375
w: Use process TTY as backup for user TTY Debian #1080335
w: Use correct return value for sd_get_sessions Debian #1068904
w: Don’t check for sd_booted Debian #1108549
w: Don’t crash with pids in terminal mode issue #407
.
.
No asc file of the source tar ball
Remove patch procps-ng-4.0.5-bsc1246330.patch no upstream
Add patch glibc-2.43.patch to support glibc 2.43
.
.
.
> LANG=C.UTF-8 w
16:45:37 up 7:49, 1 user, load average: 0.17, 0.11, 0.12
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
xxx - 10:20 7:49m 0.42s 0.42s /usr/bin/startplasma-wayland
>
> LANG=C.UTF-8 w -o
16:45:55 up 7:49, 1 user, load average: 0.12, 0.10, 0.12
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
xxx - 10:20 7:49 /usr/bin/startplasma-wayland
>
> LANG=C.UTF-8 w -t
16:46:02 up 7:49, 1 user, load average: 0.11, 0.10, 0.12
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
xxx tty1 - 10:20 7:49m 0.42s 0.42s /usr/bin/startplasma-wayland
root tty2 - 08:56 7:49m 2.95s 2.95s /usr/bin/Xorg.bin -nolisten tcp -background none -seat
xxx pts/0 - 16:30 1.00s 0.07s 0.06s w -t
xxx pts/1 - 16:35 2:02 0.02s 0.02s less
>
> LANG=C.UTF-8 who
xxx seat0 2026-07-22 10:20
xxx tty1 2026-07-22 10:20
>