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.
Still an issue in Matheria 7.2.2.4 (server version 32.0.5).
This also manifests a bit differently when using the lock screen player: resuming playback after the call actually skips back to to the start of a previously played track instead of resuming the current one (from where you were when the call came in). The player even shows the current track title, despite playing a different one.
Steps to reproduce this variant:
- have a directory with two audio files, 1.m4a and 2.m4a
- start to play 2.m4u
- lock the screen
- call the phone (just have it ring, then hang up)
- resume playback from the lock screen
Expected behaviour
Playback of 2.m4a resumes from where it was when the call came in
Actual behaviour
The player beings to play 1.m4a from the start (but claims to play 2.m4a)
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.
4.7.1 was released three weeks ago, but as I’m writing this, prebuilt binaries have yet to appear on the release page. Maybe the build jobs have failed?
I’m still getting federated posts from updating old ones on my blog (with the plugin now at version 7.5.0). Not every time, but something like four out of maybe two dozen that I edited today (from 2018) have so far appeared on Mastodon.
Should I open a new report? I noticed the merged PR (above) mentions the block editor, whereas I’m using the classic editor.
What
A checkbox on the settings page to optionally disable federating updates of existing posts.
Why
Previously:
If you edit an old post, that is not yet on mastodon, then it is technically an Update Activity but it shows up on Mastodon after the Update, so Mastodon seem to handle Updates without the updated timestamp as an Create.
I edit old posts (from before installing this plugin) every now and then, and find it pretty awkward when this causes those posts to show up on Mastodon as if they were new — more so than not federating updates at all. That’s why I’d like to have that option: to be able to disable federating updates altogether.
Only federating updates for posts that have already shown up on Mastodon would be a better solution, but also a bit more complex I believe. (It’d require some way to keep track of this status, as also mentioned in the issue that the quote above is from.)
How
No response
Okay, this was a conflict between the new integration and the third party integration I had been using up until now. I did uninstall the old integration before trying to setup the new one, but apparently that wasn’t enough; I also had to manually purge all references to sleep_as_android (both old and new) from .storage/core.entity_registry. Only after that (and core restart) the setup showed the webhook URL as expected.
The problem
The setup instructions say ”You will be presented a URL during the setup process.” I see no URL during the setup process (nor is it available anywhere after setup).
Steps to reproduce:
Select Settings > Devices & services > Add integration > Sleep as Android
What I expect to happen:
To ”be presented a URL during the setup process.”
What actually happens:


What version of Home Assistant Core has the issue?
core-2025.9.1
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Sleep as Android
Link to integration documentation on our website
https://www.home-assistant.io/integrations/sleep_as_android/
Diagnostics information
config_entry-sleep_as_android-01K5BG3KZKPF229RQSVK9BYAYC.json
Example YAML snippet
Anything in the logs that might be useful for us?
I’ve tried enabling debug logging for the integration, but it produces no output at all.
Additional information
No response