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.

Kiitoksia. Editoin osoitteen pois tuosta aloituspostauksesta, jottei siihen ainakaan enempää botteja tarttuisi.

Vaikka viestin muokkaushistoriastapa nuo sen kuitenkin löytävät.

Seurailen iNaturalistin uusia havaintoja atom-syötteiden kautta syötteenlukijalla. Nämä kuitenkin lakkasivat tässä jokunen päivä sitten toimimasta, kun inaturalist.laji.fi vastaa nyt noutoyrityksiin 403 Forbidden. Tämän näkee myös vaikkapa wgetillä:

$ /usr/bin/wget 'https://inaturalist.laji.fi/observations.atom?verifiable=true&d1=2021-08-01&place_id=7020&taxon_id=26036'
--2026-02-22 10:21:39--  https://inaturalist.laji.fi/observations.atom?verifiable=true&d1=2021-08-01&place_id=7020&taxon_id=26036
Resolving inaturalist.laji.fi (inaturalist.laji.fi)... 172.66.151.8, 104.20.24.172, 2606:4700:10::6814:18ac, ...
Connecting to inaturalist.laji.fi (inaturalist.laji.fi)|172.66.151.8|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2026-02-22 10:21:39 ERROR 403: Forbidden.

Selaimella samat syötteet saa kyllä noudettua, mutta syötteiden koko pointtihan on siinä, ettei sivuja tarvi tarkistella toistuvasti selaimella.

Ensiapuna vaihdoin osoitteiden domainin inaturalist.laji.fistä inaturalist.orgiin, joka edelleen tarjoilee nuo syötteetkin kuten ennen. Tällöin kuitenkin postausten (havaintojen) linkitkin osoittavat sinne inaturalist.orgiin, ja käyttäisin mieluummin laji.fi-instanssia, joka on hieman paremmin tänne Suomen oloihin räätälöity.

You’re fortunate to have come across the snake, as they’re usually pretty shy up there. That’s why they also don’t pose much of a risk when encountered: perhaps 9/10 will rather slither away at the earliest opportunity rather than stand their ground. Then again, had this one decided to stay, at least you’ll have less voles and mice rummaging around in your garden. :)

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:

1. have a directory with two audio files, 1.m4a and 2.m4a
2. start to play 2.m4u
3. lock the screen
4. call the phone (just have it ring, then hang up)
5. 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)

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.

So we’re running different kernels, even curiouser and curiouser. :)

You’re right that the one you currently have probably has been the only one it’s had since installing (judging from 6.14’s publishing history).

Could you check to see which updates, if any, you’ve installed just prior to the lockups starting? The log files should be under /var/log/apt/ as history.log (the most recent), then history.1.gz (next newest) etc. The .log files are plain text. The .gz ones are compressed, so have to be decompressed first, or, if you’re comfortable with the command line, you can use zless to view them directly.

To me this does look like a kernel issue, but if any non-kernel updates are the trigger, you could perhaps work around the issue by downgrading the package(s), if you can pinpoint which one(s) started the issue.

Right, I’m on (the non-HWE) 6.8 series:

Linux saegusa 6.8.0-90-generic #91-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 18 14:14:30 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

According to /var/log/apt/history.log*, I installed it freshly back in December (2025-12-12), and journalctl shows I’d rebooted the next day (the 13th), so have been running it ever since.

Since this is so rare an occurrence on my system, hopefully @anonymousdormouse has the ability to try older/newer kernels with their easily repeatable trigger.

Actually, had this only occurred this week, I might have put my money on it being caused by the “biggest ‘solar radiation storm’ in 23 years”. But, alas, I did have that one incident on the 11th.