Enable the systemd-resolved stub resolver and make it available on the
hassio host network interface (172.30.32.1). This allows to use
systemd-resolved directly from all containers.
Note that this makes /etc/resolv.conf point to the stub resolver running
at 127.0.0.53 by default. This stub resolver isn't reachable from within
containers. However, Docker does regnize this situation [1] and falls back
to the alternate path at /run/systemd/resolve/resolv.conf, which is what
/etc/resolv.conf is today. So this should not affect the initial
/etc/resolv.conf in containers in practise.
This will however bind to port 53 and affect add-on potentially attempt
to use that port. Add-ons should not bind to 127.0.0.53 or the hassio
host network (172.30.32.1).
[1] https://github.com/moby/moby/blob/v28.0.4/libnetwork/internal/resolvconf/resolvconf_path.go#L51C32-L51C45
When creating OVA image, the CPU is slacking at the end of the build because it
is creating three ZIP archives, each one on a single CPU only. As we're
creating only single-entry archives, we can use pigz to use all cores.
The actual speedup on my machine (16C/32T) reflects the number of cores - it
takes around 2 seconds instead of 1 minute.
Since
127c420335
change in package/systemd, this option is patched by systemd build because
userspace FW loading has never been supported with Systemd. This should have no
runtime effect, just clear the warning about disabled option.
* package/vcgencmd: add tool for RPi VideoCore commands
This tool is used by rpi-eeprom-update and is fairly lightweight binary without
dependencies. Use it as-is from raspberry/utils repo.
* package/rpi-eeprom: change package to install EEPROM userspace scripts
* configs: enable rpi-eeprom for rpi4, rpi4-64, rpi5-64 and yellow
On Pi5 and Yellow also enable flashrom so the firmware can be installed
directly without recovery being involved. On Yellow/CM4 this can't be done
without config.txt changes though (SPI and pinmuxing needs to be enabled) but
the image is shared there and users may eventually use the tools if they want,
so install BCM2711 on Yellow too. The "officially recommended" method is
rpiboot though, which is also documented in Yellow docs.
Because we use custom compatible strings in Yellow DTS's, the firmware loader
first attempts to load a firmware with this compatible in its name. Because it
doesn't exists, it shows error like this one before falling back to a more
generic one:
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,5-compute-module-ha-yellow.bin failed with error -2
While these errors are mostly harmless, add symlinks with our compatible in the
name to suppress them. Instead of patching upstream
package/brcmfmac_sdio-firmware-rpi which installs the firmware files, add them
to yellow overlay to make maintenance easier.
Latest RPi firmware package contains module options that supposedly improve
stability, with details described in [1].
Since the feature_disable mask also disables the dump_obss feature, this change
would also mitigate `brcmf_set_channel: set chanspec ... fail` messages still
seen in some environments even after #3719.
Fixes#3367
[1] 2788cb549a
* Fix U-Boot config to access all RAM on 16 GB CM5
U-Boot defconfig used for Yellow checks only 4 DRAM banks, however, CM5 with 16
GB has the memory spread across 8 banks. Add a patch (submitted upstream) to
the defconfig to get access to the whole RAM.
Fixes#3989
* Add Upstream tag with link to uboot patchwork
* Update RPi kernel to 6.12.20
Update to latest stable RPi kernel and remove unnecessary 6.6.y kernel config
fragments.
* Refresh RPi and Yellow patches
Rebase all patches on 6.12.20, remove patches that are already present
upstream.
* Update Yellow device trees for 6.12.20
Upstream changes broke our downstream device trees. While the CM4 fix was
trivial, there were more changes in the CM5 device tree due to adaptation to
upstream code. To simplify future maintenance, DTS was refactored to reuse CM5
DTS include and override only what's necessary.
* Bump buildroot to update to matching package/rpi-firmware
* buildroot ead21eb6d2...cd82256125 (1):
> package/rpi-firmware: bump version to f49a396 (1.20250326)
* Update Buildroot base to v2025.02
Packages updated:
* Added host-blake3 1.5.4
* Added host-go-src
* Added host-libxcrypt 4.4.38
* Added host-tar 1.35
* Added host-xxhash 0.8.3
* Added libtalloc 2.4.2
* Added libxcrypt 4.4.38
* apparmor updated from 3.1.2 to 3.1.7
* busybox updated from 1.36.1 to 1.37.0
* cifs-utils updated from 6.15 to 7.1
* containerd updated from 1.7.26 to 2.0.2
* dbus-broker updated from 35 to 36
* dropbear updated from 2024.85 to 2024.86
* e2fsprogs updated from 1.47.0 to 1.47.2
* expat updated from 2.6.4 to 2.7.0
* gcc-final updated from 12.4.0 to 13.3.0
* glibc updated from 2.38-81-gc8cb4d2b86ece572793e31a3422ea29e88d77df5 to 2.41-5-gcb7f20653724029be89224ed3a35d627cc5b4163
* gptfdisk updated from 1.0.9 to 1.0.10
* host-binutils updated from 2.40 to 2.43.1
* host-ccache updated from 4.8.2 to 4.10.2
* host-cmake updated from 3.28.3 to 3.31.5
* host-dtc updated from 1.7.0 to 1.7.2
* host-e2fsprogs updated from 1.47.0 to 1.47.2
* host-elfutils updated from 0.189 to 0.192
* host-expat updated from 2.6.4 to 2.7.0
* host-fakeroot updated from 1.32.1 to 1.36
* host-gawk updated from 5.3.0 to 5.3.1
* host-gcc-final updated from 12.4.0 to 13.3.0
* host-gcc-initial updated from 12.4.0 to 13.3.0
* host-genimage updated from 17 to 18
* host-go updated from 1.22.12 to unknown
* host-gptfdisk updated from 1.0.9 to 1.0.10
* host-kmod updated from 31 to 33
* host-libcap updated from 2.69 to 2.73
* host-libffi updated from 3.4.4 to 3.4.6
* host-libglib2 updated from 2.76.1 to 2.82.5
* host-libopenssl updated from 3.2.4 to 3.4.1
* host-libtirpc updated from 1.3.4 to 1.3.6
* host-libxml2 updated from 2.12.9 to 2.13.6
* host-lz4 updated from 1.9.4 to 1.10.0
* host-lzip updated from 1.23 to 1.25
* host-meson updated from 1.3.1 to 1.7.0
* host-mpc updated from 1.2.1 to 1.3.1
* host-mtools updated from 4.0.43 to 4.0.47
* host-nfs-utils updated from 2.6.4 to 2.8.2
* host-pcre2 updated from 10.42 to 10.44
* host-pkgconf updated from 1.6.3 to 2.3.0
* host-python3 updated from 3.11.11 to 3.12.9
* host-python-flit-core updated from 3.9.0 to 3.10.1
* host-python-jinja2 updated from 3.1.2 to 3.1.5
* host-python-markupsafe updated from 2.1.3 to 3.0.2
* host-python-packaging updated from 23.2 to 24.2
* host-python-pypa-build updated from 1.0.3 to 1.2.2
* host-python-pyproject-hooks updated from 1.0.0 to 1.2.0
* host-python-setuptools updated from 69.0.3 to 75.8.0
* host-python-wheel updated from 0.40.0 to 0.45.1
* host-rauc updated from 1.11.3 to 1.13
* host-sqlite updated from 3.44.2 to 3.48.0
* host-systemd updated from 254.13 to 256.7
* host-util-linux updated from 2.39.3 to 2.40.2
* host-xz updated from 5.4.5 to 5.6.4
* host-zstd updated from 1.5.5 to 1.5.7
* iproute2 updated from 6.7.0 to 6.13.0
* iptables updated from 1.8.9 to 1.8.11
* json-c updated from 0.17 to 0.18
* kmod updated from 31 to 33
* libapparmor updated from 3.1.2 to 3.1.7
* libblockdev updated from 3.1.1 to 3.3.0
* libbytesize updated from 2.7 to 2.10
* libcap-ng updated from 0.8.4 to 0.8.5
* libcap updated from 2.69 to 2.73
* libdnet updated from 1.16.4 to 1.18.0
* libffi updated from 3.4.4 to 3.4.6
* libglib2 updated from 2.76.1 to 2.82.5
* libgudev updated from 237 to 238
* libmicrohttpd updated from 0.9.77 to 1.0.1
* libnftnl updated from 1.2.6 to 1.2.7
* libnl updated from 3.9.0 to 3.11.0
* libnvme updated from 1.7.1 to 1.11.1
* libopenssl updated from 3.2.4 to 3.4.1
* libtirpc updated from 1.3.4 to 1.3.6
* libunistring updated from 1.1 to 1.3
* libusb updated from 1.0.26 to 1.0.27
* lvm2 updated from 2.03.14 to 2.03.27
* nettle updated from 3.9.1 to 3.10.1
* network-manager updated from 1.44.2 to 1.50.2
* nfs-utils updated from 2.6.4 to 2.8.2
* pcre2 updated from 10.42 to 10.44
* procps-ng updated from 4.0.4 to 4.0.5
* rauc updated from 1.11.3 to 1.13
* rpcbind updated from 1.2.6 to 1.2.7
* rtl8821cu updated from 1597dfeda6cefd2e603fc7020ceca226d05fb108 to 96c65c58b544241178638e810b333dcc9aa26b91
* sqlite updated from 3.44.2 to 3.48.0
* systemd updated from 254.13 to 256.7
* util-linux-libs updated from 2.39.3 to 2.40.2
* util-linux updated from 2.39.3 to 2.40.2
* wireless-regdb updated from 2023.09.01 to 2024.10.07
* wpa_supplicant updated from 2.10 to 2.11
* patches/genimage: drop upstreamed patches
* patches/systemd: drop merged patch
* patches/network-manager: drop upstreamed patch
* Add BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_* to defconfigs
As the reported MemTotal can fluctuate a bit on some systems, e.g. because the
reserved memory changes between kernel version or other factors affect it like
VRAM, the swap file can be recreated unnecessarily between boots. Allow for
some fluctuation (up to +-32MB) before the swapfile is recreated.
This was a problem already before the recent haos-swapfile changes, however,
before it checked if the existing swapfile isn't smaller than the desired
value. If the MemTotal fluctuated there, the swapfile size eventually settled
on the highest value seen and it wasn't recreated anymore. With this change,
things should be stable even more.
As pointed out in [1] by @cdce8p, the RTL8125D has an internal PHY that also
needs some changes to be backported.
Also, move the patches to more targeted directories is it would be otherwise
applied to RPi 6.6 kernel with failures. We can move it back to the top-level
patches directory once RPi moves to kernel 6.12.
[1] https://github.com/home-assistant/operating-system/issues/3880#issuecomment-2790105503
As we enabled SI/CIK support to fix crashes on bunch of AMD SoCs in #3957, the
amdgpu driver still crashes on some hardware. It seems to be some GX-217GA SoCs
or even GX-425GA in Fujitsu thin clients (even though the same SoC is fine on
T620).
To get to the state before update to kernel 6.12, disable amdgpu for these
platforms again (as it couldn't work properly there before OS 15.0) and just
backport the patch that fixes the crashes during probing when the driver isn't
compiled with SI/CIK support.
Fixes#4012
* Backport RTL8125D (rev C, XID 688) support
Apply mainline patch adding support for NIC present e.g. on ASUS NUC 14
Essential.
Fixes#3880
* Update buildroot to add RTL8125D firmware
* buildroot 4cd211162d...5379c358bf (1):
> linux-firmware: add RTL8125D firmware
Update of OpenSSL in OS 12.2 from 1.1.1 to 3.2 changed the output of `openssl
sha256` command. It seems that some hypervisors don't like this and fail if
it's not plain "SHA256".
Fixes#3654
Firmware change that set initial_turbo to 60 from the previous 0 has broken
initialization of some SD cards in U-Boot. Adjust the value in config.txt on OS
update if the value is not already set by the user, and put it to the default
config.txt.
The config.txt also contains a short comment explaining the purpose. The
purpose of it is also to make it easier to revert this change in the future if
the problem is fixed in the firmware or U-Boot.
Fixes#3965
One of the reason for failures after update to OS 15.0 was missing support for
the kernel PIO driver in EEPROM firmware. Backport upstream patches from
raspberrypi/linux#6645 and raspberrypi/linux#6642 that handle this situation
more gracefully. These patches could be dropped after the next RPi kernel
release.
Refs #3943
Update generic_raw_uart package to the latest sources available coming with
direct kernel 6.12.x compatibility dropping the intermediate patches
accordingly. In addition, the eq3_char_loop patchset was updated to reflect the
same changes performed.
When Intel GPUs are used in passthrough, the i915 is probed too early and fails
to load firmware which is in the rootfs mounted later. The CONFIG_DRM_I915=y
comes from x86_64_defconfig, by changing it to module (like we do for
generic-x86-64), the driver becomes only available after the rootfs is mounted
and firmware is loaded correctly.
Fixes#3949
It seems that kernel 6.12 handles device probing less gracefully when these
options are not enabled and causes crash on some AMD SoCs, e.g.:
*ERROR* Invalid callback to read register 0x58184
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4050
Refs #3944
U-Boot update in #3878 changed the layout of patch folders for Hardkernel
targets with the goal to make it less confusing. However, it missed adding the
top-level hardkernel patches directory to all hardkernel targets and only
remove it from some of them in [1].
Revert to state before #3878 by adding the hardkernel folder to c2/c4/n2. In
the future, the patches from this folder should be split per target and if any
patches remain in it, they should be applied for all hardkernel boards.
[1] 2716b564c2Fixes#3936
In some cases, the wipe service may be called due to a race condition for the
second time during the boot, very likely failing because the filesystems are
already mounted. This can not be reproduced on OVA but can be fairly easy
triggered e.g. on RPi. As we want the service to be executed exactly only once,
we can do what's suggested in [1] and set the RemainAfterExit=yes. That should
ensure the unit is not ever started for the second time.
[1] https://www.github.com/systemd/systemd/issues/29367
Update to latest version of the driver and matching firmware. The most common
application for it - Frigate - currently has 4.19.0 in stable but 4.20.0 is
staged in dev. As it's easier to select OS version than a version of the
add-on, it makes sense to stay ahead in HAOS. This also means Frigate needs to
be updated to the matching version (as staying on an arbitrary older patch
revision doesn't make much sense either).
Use simple shell script to perform device wipe instead of calling OS Agent to
do that through the UDisks2 API. While it might have been a good idea to use
high level interface for that back then, it turns out it causes more issues
than the benefits it could bring.
Main problem currently is that the OS Agent needs to read sysctl variables, but
those are only set after mounting the overlay partition. But at the same time,
the overlay partition can't be mounted if we want to wipe it - this creates a
dependency cycle through the haos-agent.service.
To get rid of the cycle and simplify things, use a shell script doing basically
the same what the OS Agent does. Since the wipe functionality only makes sense
to be implemented on HAOS targets (not on Supervised), there's little point of
having it in higher layer of abstraction that OS Agent provides.
It should be also checked if changes from #1291 are needed anymore, as the
driving factor for those have been probably the wipe feature in OS Agent too,
but at this point they seem to be harmless.
