Stefan Agner

Closing as this is resolved by https://github.com/home-assistant/operating-system/pull/2194. The problematic patch has also been lined up to the stable kernel updates (`Revert "usb: dwc3: disable USB core PHY management"`).

Yes, this is still a problem, but it is a bug in VMWare Workstation 16. Unfortunately, I was unable to report the bug because I am not a VMware customer....

There is a newer issue with more details, see #2182. Ideally you post your case there as well, along with information what Netgear router and which firmware version you are...

Hardware initialization/firmware is something handled by the kernel. What would be interesting is if the same error appears on a different distribution (e.g. Arch Linux with the LTS kernel installated)....

Going back to modifiable daemon.json is the wrong solution, and also kinda pain at this point. What we discussed is to limit the scope of the default network to `172.17.234.0/24`...

It is not only the Docker bridge, it's also the custom network which uses a `172.17` prefix. Ideally we make both configurable, but that is a bit more involved.

HAOS 9.5 uses two smaller subnets in `172.30.x.x` range (see #2246). This should help at least some folks which have Class B range overlap with their router/ISP.

Closing as this is addressed with https://github.com/home-assistant/supervisor/pull/4589.

It seems that this is resolved with QEMU 8.1.0. There are still many `mremap` syscalls, but the same commands above complete when using https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/qemu-arm-8.1.3-r1.apk.

It seems that this is a duplicate of #1798? I see the same seqence of `mremap` as reported in https://github.com/nodejs/docker-node/issues/1798#issuecomment-1666243017 when using `strace` with the reproducer from https://github.com/nodejs/docker-node/issues/1946#issuecomment-1811716910.