Steps to reproduce:
- use update manager to install updates that require a restart
- after installing the updates, update manager asks whether to restart now or later: select restart now
- realize you have unsaved work, so from the additional restart confirmation dialog that pops up, select ”cancel”
What I expect to happen
For the restart to get cancelled
What happens instead
A restart; there goes your unsaved work
Further info
I can’t remember if I’ve tried to approve the restart from that final dialog instead of cancelling it, so I don’t know if that would cause the restart to go ahead too (which would be expected), or if the buttons have their labels switched.
I’ve had this happen twice since upgrading from 24.04 to 26.04. To be clear, the symptoms were as described by Mihail in comment #12 above (and not whatever the OP reported):
loka 25 17:39:30 saegusa systemd[1]: Starting user@60579.service – User Manager for UID 60579…
loka 25 17:39:30 saegusa (systemd)[2446]: user@60579.service: Failed to determine credentials for user ’60579’: Unknown user
loka 25 17:39:30 saegusa (systemd)[2446]: user@60579.service: Failed at step USER spawning /usr/lib/systemd/systemd: Invalid argument
loka 25 17:39:30 saegusa systemd[1]: user@60579.service: Main process exited, code=exited, status=217/USER
loka 25 17:39:30 saegusa systemd[1]: user@60579.service: Failed with result ’exit-code’.
loka 25 17:39:30 saegusa systemd[1]: Failed to start user@60579.service – User Manager for UID 60579.
loka 25 17:39:30 saegusa systemd[1]: Started session-c1.scope – Session c1 of User gdm-greeter.
loka 25 17:39:30 saegusa systemd[1]: Started apache2.service – The Apache HTTP Server.
loka 25 17:39:30 saegusa /usr/libexec/gdm-wayland-session[2491]: dbus[2491]: Unable to set up transient service directory: XDG_RUNTIME_DIR ”/run/user/60579” is owned by uid 60579, not our uid 60578
loka 25 17:39:30 saegusa /usr/libexec/gdm-wayland-session[2491]: dbus-daemon[2491]: [session uid=60578 pid=2491 pidfd=5] Cannot set up inotify for ’/run/gdm3/home/gdm-greeter/.local/share/dbus-1/services’: Permission denied
The first time it happened during a normal reboot, and resolved itself after I rebooted again (using ssh to log in from another system). The second time (last night, as logged above) it happened after a reboot due to VLC causing an unrelated Xwayland crash, and no amount of rebooting ever fixed it.
I stopped nscd (`systemctl stop nscd; nscd -i passwd; nscd -i group`), after which restarting GDM (`systemctl restart gdm`) finally brought the login screen back. I then disabled nscd (`systemctl disable nscd`) to make sure it won’t mess things up again on the next reboot.
The suggestion to stop nscd came from ChatGPT, which apparently based it on a reply to an Ask Ubuntu thread about the same issue [1]. I don’t know what unwanted consequences disabling nscd potentially has, but at least I have a working desktop for now.
* [1] https://askubuntu.com/a/1570171
Both issues (”Network is unreachable” and WoL not working) were fixed for me after the latest kernel update, which was Linux 6.8.0-106.
Looks like patchset 2026-01-07 [1] should at least have the WoL issue fixed: ”net: ipv4: fix regression in local-broadcast routes” (more in [2]). Whether this helps with the other, ”Network is unreachable” issues, I wouldn’t know.
*[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137664
*[2] https://lore.kernel.org/regressions/20250822165231.4353-4-bacs@librecast.net/
So that’s what was causing all these weird network issues all of a sudden here. Looks like 6.8.0-101-generic is likewise affected.
Sending wake-on-LAN packets also broke for me coincidentally with this. That is, my NAS (now also running 6.8.0-101) could still receive WOL packets sent from a server running 6.8.0-79, but none sent from my desktop (running 6.8.0-101). After downgrading the desktop back to 6.8.0-94, WOL packets sent from it were again immediately picked up by the NAS.
This happened again, and the only common factor with the one above was Totem playing a video again (this time I wasn’t messing with the timeline, just watching).
I was editing a video in Kdenlive (in that I had the project open on my first monitor), and was simultaneously scrubbing one of the input clips on my second monitor using Totem, when the crash occurred.
Not much further info at the moment that I can think of. Just making this initial report so that I have something to refer to, should a similar crash occur again.
For me the icon is not missing, but it is replaced in the dock by what looks like perhaps a fallback: a cogwheel icon. I’m attaching a screenshot.
Hi Vinicius, thanks for looking into this!
I’ll have to postpone further testing until the next time there’s an issue, as my backups rely on the NAS (and it’s now back in operation with the nomodeset workaround). Taking it down is also physically fairly involved, as I prefer to unplug all the data drives, to spare them from repeated powercycling during testing.
However, I’m about 80 % sure I checked the journal for the failed suspends, and it just stopped there, resuming thereafter with just the boot messages from the next boot onward.
Also, I have TTY1 configured to display the journal ”live” (I’ll attach my /etc/systemd/system/getty@tty1.service.d/override.conf below), and I *did* try suspending with that TTY showing the journal (`sleep 5 && systemctl suspend` on TTY2, then switching to TTY1 before the timeout); I’ll attach a photo of that view when the suspend had resulted in this freezing issue.
Unfortunately I don’t have a cable to do debugging over a serial console.
I was able to work around this (in a test VM, after upgrading it from 20.04 to 24.04) with adapted instructions from a blogpost [1], by temporarily installing postgresql-14 from the PGDG repository for doing the 14 -> 16 upgrade:
# apt install postgresql-common
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
# apt install postgresql-14
# pg_dropcluster 16 main –stop
# pg_upgradecluster 14 main
# pg_dropcluster 14 main
# apt purge postgresql-14 postgresql-client-14
# rm /etc/apt/sources.list.d/pgdg.sources
# apt update
I have yet to try this on my actual server with actual data. Please be careful if you attempt this with a production database.
*[1] https://www.directedignorance.com/blog/upgrading-postgresql-14-to-16-on-ubuntu