Both issues (”Network is unreachable” and WoL not working) were fixed for me after installing 6.8.0-106
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.
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.
I noticed that for the specific case of picking an element from the end using just the size of the array itself, the above is a somewhat contrived example; a plain -1 would work just as well. But I can change the example script as below, and the difference between outputs still holds:
#!/bin/bash
array=(
"a"
"b"
"c"
)
i=3
value="${array[i - 1]}"
printf "%s\n" "${value}"
With the same arguments given, output differs between 3.12.0 and 3.13.0, as demonstrated in the example below. I didn’t see this mentioned directly in the release notes, so I was wondering if this is an intentional change or a bug. I don’t mind the change per se, but just wanted to be sure that it’s permanent before I adjust all my existing scripts to conform to the newer way shfmt prefers this.
$ cat asdf
#!/bin/bash
array=(
"a"
"b"
"c"
)
value="${array[${#array[@]} - 1]}"
printf "%s\n" "${value}"
$ /usr/local/bin/archive/shfmt/shfmt_v3.12.0_linux_amd64 -i 4 -ci -l -d asdf # no output
$ /usr/local/bin/archive/shfmt/shfmt_v3.13.0_linux_amd64 -i 4 -ci -l -d asdf
asdf
diff asdf.orig asdf
--- asdf.orig
+++ asdf
@@ -6,6 +6,6 @@
"c"
)
-value="${array[${#array[@]} - 1]}"
+value="${array[${#array[@]}-1]}"
printf "%s\n" "${value}"
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.
Playback of 2.m4a resumes from where it was when the call came in
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?