My laptop (a Dell Latitude 5400, running Ubuntu 26.04) is also affected by this. /usr/libexec/geoclue-2.0/demos/where-am-i is able to get my location, yet go-hass-agent always reports the same error it does for OP:
1:17PM DEBUG Location updated.
1:17PM DEBUG Invalid sensor data. error="contains field errors\ninvalid field Name (value(\"\")) failed validation for required: Key: 'Sensor.Name' Error:Field validation for 'Name' failed on the 'required' tag\ninvalid field State (value(\"<nil>\")) failed validation for required: Key: 'Sensor.State' Error:Field validation for 'State' failed on the 'required' tag\ninvalid field Type (value(\"\")) failed validation for required: Key: 'Sensor.Type' Error:Field validation for 'Type' failed on the 'required' tag\ninvalid field UniqueID (value(\"\")) failed validation for required: Key: 'Sensor.UniqueID' Error:Field validation for 'UniqueID' failed on the 'required' tag
The device tracker’s state in HA remains ”Unknown”.
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
My build environment is an Ubuntu 24.04 VM.
Turns out I wasn’t running npm install in my build script, but that also apparently isn’t the issue: building after an npm install results in an equally broken (i.e. iconless) build as without it.
I’ll attach an output log from the npm install part. It at least mentions postinstall.sh.
npm-install.log
Reproducible for me in Ubuntu 24.04, Firefox 150.0 from Mozilla’s PPA, with a small difference: new tab button does seem to work, which is useful, since without it wouldn’t be possible to open about:config the workaround of toggling widget.wayland.fractional-scale.enabled.
This looks like #2851 on the COSMIC issue tracker, affecting Firefox. They’ve also reported it upstream.
The COSMIC issue has been closed as having been fixed by 150.0, but there’s at least one dissenter.
Anyway, I’m using a regular Gnome desktop on Ubuntu 24.04, with Wayland, Librewolf 150.0, and funnily enough, for me this only appeared with 150.0 and not before. So now I am affected.
The workaround of toggling widget.wayland.fractional-scale.enabled mentioned in the COSMIC issue seems to work (i.e. after the menus have died, open about:config, toggle the setting from default trueto false, then immediately back to true).
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.
Yeah, seems to be fixed: I tested in an Ubuntu 24.04 vm with WezTerm 20240203-110809-5046fc22 and couldn’t reproduce the issue.
(I first tried the nightly, which from the repository was 20260117-154428-05343b38, but that one was missing all window decorations entirely, and so couldn’t be resized at all.)
I’ll close the issue and unsubscribe, as I’m not using WezTerm currently myself. Others can reopen it if still affected.
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.
Thanks. I had hoped for either some correlation with my history.log, or something connected to drawing/rendering the desktop, but nothing jumps out from those, alas. The nvidia/libnvidia-* ones from the 23rd would be the obvious suspect, except you had already posted about the problems (above) when those packages were getting installed.
The apparmor denials for Firefox seem to be a known issue. I don’t use Firefox (and back when I did, I used the Mozilla PPA version instead of the snap), but I suspect they’re not related to the freeze. At least not unless you’re running particularly low on memory.