Squash all the patches to a single file per DTS without making any other
changes. The long patch series makes it harder to understand how the DTS
looks like without applying them all. We still have the repo history and
in-file comments if we need to understand individual changes.
This backports patch currently waiting for a merge upstream that fixes
issue we saw with CM5 on Yellow, where the SD card init took over 120
seconds. We added a workaround in #3700 lowering this roughly to 20
seconds, but this is no longer needed, so revert this patch as well.
Standard pciutils are required by rpi-eeprom-update. The Busybox version
is missing the -d flag, failing to show VL805 version. Enable pciutils
to fix it, to avoid adding HAOS-specific patch to rpi-eeprom-update.
Previously the watchdog timeout was set to "default", which makes
systemd adopt whatever timeout the underlying hardware driver
advertises. In practice this means very different behavior across
platforms: common x86-64 watchdogs (iTCO_wdt, i6300esb on virtual
systems) default to around 30 seconds, while the Raspberry Pi BCM2835
watchdog uses 15 seconds.
These short timeouts have proven too aggressive in the presence of
stalled network storage. PID1 enters the kernel through paths that can
park it in D-state on a dead NFS mount: mount_enter_mounting() calls
chase()/open_tree(), is_dir()/mkdir_p_label() on bind mount sources,
and mkdir_p_label()/unit_warn_if_dir_nonempty() on destinations all
end up in nfs_lookup/nfs_getattr/nfs_readdir, waiting for an RPC major
timeout. While PID1 is blocked it cannot ping the watchdog, and the
system reboots even though the underlying issue is a network storage
stall, not a kernel hang. Reported upstream as
https://github.com/systemd/systemd/issues/42050.
Set RuntimeWatchdogSec to 5 minutes to align all platforms on a
single, conservative value that tolerates NFS/CIFS RPC timeouts while
still recovering from genuine PID1 hangs.
A note on hardware limits: some watchdog drivers expose a
max_hw_heartbeat_ms instead of max_timeout. In that case the watchdog
core in drivers/watchdog/watchdog_dev.c arms a kernel timer that pings
the hardware in the background and multiplexes a longer userspace
timeout on top, so a 300s request is accepted even when the silicon
counter cannot represent it. The BCM2835 watchdog used on all
Raspberry Pi variants is exactly this case: the PM_WDOG_TIME_SET
register caps at ~16s of hardware heartbeat, but the driver migrated
to the max_hw_heartbeat_ms path in v6.8 (commit f33f5b1fd1be
"watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling", Dec 2023), so
WDIOC_SETTIMEOUT(300) is honored — the core re-pings the chip every
~15s automatically and only stops once userspace has been silent for
the full 300s. Drivers that still use max_timeout directly will reject
300s with -EINVAL and systemd falls back to the driver's own value;
this is no worse than the previous "default" behavior.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Rebase fileenv on U-Boot v2026.04
* Update Green U-Boot to v2026.04, refresh patches
* Update U-Boot to v2026.04 on meson-based ODROIDs
* Update U-Boot to v2026.04 on Raspberry Pi
0013-configs-rpi-set-NR_DRAM_BANKS-to-8-to-accommodate-RA.patch was
merged upstream.
* Update Yellow U-Boot to v2026.04
* Update U-Boot to v2026.04 on Rockchip-based ODROIDs
* Update VIM3 U-Boot to v2026.04
* Fix cec issues on the Raspberry Pi 4 by switching from the legacy fkms to kms
The linux kernel didn't create /dev/cec0 and /dev/cec1 even though the hardware supports hdmi-cec. Fkms is not being updated anymore:
https://forums.raspberrypi.com/viewtopic.php?t=332742
* Disable firmware KMS setup in config.txt
Disable firmware KMS setup to use kernel defaults.
Restores IPv6 forwarding that was dropped in d918dace. With ipv6=true,
dockerd enables net.ipv6.conf.all.forwarding at startup (and sets the
IPv6 FORWARD chain policy to DROP), matching IPv4 behavior. Fixes the
regression worked around in supervisor#6720 (issue #4630).
Note: Supervisor since
https://github.com/home-assistant/supervisor/pull/6720 (shipped with
Supervisor 2026.04.0) already enables IPv6 explicitly on the hassio
bridge by default, so this OS-level change is not strictly required to
restore IPv6 forwarding. It is still the right thing to do - letting
Docker take control of IPv6 forwarding (just like IPv4) is what the
original commit intended, and it ensures correct behavior independent
of Supervisor's defaults.
Backport patches required for clean application of
8b88d99341f139e23bdeb1027a2a3ae10d341d82 (mainline
f3d603dc3bdcf9ae47cc21e0daec706d7a5) to Raspberry Pi patchset. Can be
dropped after we update RPi either to v6.12.85+ or v6.18.y.
It seems that USB autosuspend interacting badly with dwc2 on Meson-GXBB:
with nothing plugged into the GL852G's downstream ports at boot, the hub
idle-suspends, and dwc2 on this SoC doesn't reliably wake on a downstream
port-status-change. Devices present at boot enumerate before autosuspend
kicks in.
Fix by disabling USB autosuspend on this particular board.
* Update generic-aarch64 to Linux 6.18
* Update green to Linux 6.18
Patches refreshed with --zero-commit flag and rockchip defconfig
regenerated using savedefconfig from 6.12 version.
* Update Rockchip-based ODROIDs (M1, M1S) to Linux 6.18
* Update Amlogic/meson ODROIDs to Linux 6.18
Refresh patches with --zero-commit, regenerate defconfig and move all
patches from top-level odroid directory to patches-meson, as they're
essentially used and applied only for these SoCs.
* Update VIM3 to Linux 6.18
Defconfig regenerated using savedefconfig (without fragments).
* Update documented kernel version for updated boards
* Remove Rockchip base config for 6.12
* Update Linux to 6.18 for x86 targets
Update ova and generic_86_64 to Linux 6.18.22. Rebase the IPv6
reachability probe patch (which still applies on 6.12 with offsets) and
update config fragments.
The rtl8812au-aircrack-ng stays disabled as it no longer builds and is
deprecated by upstream rtw88 which supports those cards.
The fragemnts stay mostly the same with this diff:
--- ../v6.12.y/docker.config 2025-03-18 15:05:42.161955925 +0100
+++ docker.config 2026-04-16 15:01:30.346942217 +0200
@@ -45,3 +44,0 @@
-CONFIG_IP6_NF_FILTER=y
-CONFIG_IP6_NF_MANGLE=y
-CONFIG_IP6_NF_NAT=y
@@ -48,0 +46,3 @@
+CONFIG_NETFILTER_XT_NAT=y
+CONFIG_NETFILTER_XT_TARGET_REDIRECT=y
+CONFIG_NETFILTER_XT_TARGET_MASQUERADE=y
@@ -56,4 +55,0 @@
-CONFIG_IP_NF_FILTER=y
-CONFIG_IP_NF_NAT=y
-CONFIG_IP_NF_TARGET_MASQUERADE=y
-CONFIG_IP_NF_TARGET_REDIRECT=y
--- ../v6.12.y/hassos.config 2026-01-16 13:49:13.879830313 +0100
+++ hassos.config 2026-04-16 15:08:29.248341382 +0200
@@ -30,2 +29,0 @@
-CONFIG_ZSWAP_ZPOOL_DEFAULT_ZSMALLOC=y
-CONFIG_ZSMALLOC=y
The IP_NF/IP6_NF depend on IP_NF_IPTABLES_LEGACY which is now by default
disabled. Since we use iptables-nft, those should not be needed, but
missing NETFILTER_XT options have been enabled to replace some of them.
ZSMALLOC is now enabled by default with ZSWAP and the ZSWAP option was
removed in related change in 2ccd9fecd9163f168761d4398564c81554f636ef.
CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO is a direct replacement of
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE as suggested in linux commit
44d46b76c3a4b514a0cc9dab147ed430e5c1d699
> mm: add build-time option for hotplug memory default online type
> ...
> Existing users of CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y should use
> CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO.
* Fix build of the gasket driver with Linux 6.18
Backport patch from an unmerged PR to fix build with 6.18.
* Update package/rtl88x2bu to fix 6.18 build
Update the OOT driver to the latest version to fix build.
* Update Buildroot's package/rtl8821cu to fix build
* buildroot c4b580fde8...bc2fe6e38c (4):
> package/rtl8821cu: bump to version 2025-12-14
> package/rtl8821cu: fix build failure with Linux 6.17
> package/rtl8821cu: fix build failure with Linux 6.16
> package/rtl8821cu: bump to version 2025-05-08
* Replace rtl8812au-aircrack-ng by upstream kernel drivers
The drivers also need firmware - for 8812/8821 the firmware files are
already present, for 8814 the firmare needs linux-firmware update to
20250410 or newer which will install it using the wildcard pattern.
This adds two patches with fixes/improvements for the Docker engine
- `0001-daemon-respect-explicit-AppArmor-profile-on-privileg.patch`:
Makes sure that AppArmor rules are always loaded, also on reboot. This
is a long standing bug in Docker and affects Supervisor which is a
privileged container with an AppArmor profile.
Upstream PR: https://github.com/moby/moby/pull/52215
- `0002-bridge-protect-bridge-subnet-from-direct-external-ac.patch`:
Makes sure that the whole network (including gateway IP) of any Docker
bridge network in NAT mode is firewalled from access from the outside.
This essentially implements on Docker level what Supervisor applies on
startup with https://github.com/home-assistant/supervisor/pull/6650.
Upstream PR: https://github.com/moby/moby/pull/52224.
(cherry picked from commit 50c1efdb3a)
This adds two patches with fixes/improvements for the Docker engine
- `0001-daemon-respect-explicit-AppArmor-profile-on-privileg.patch`:
Makes sure that AppArmor rules are always loaded, also on reboot. This
is a long standing bug in Docker and affects Supervisor which is a
privileged container with an AppArmor profile.
Upstream PR: https://github.com/moby/moby/pull/52215
- `0002-bridge-protect-bridge-subnet-from-direct-external-ac.patch`:
Makes sure that the whole network (including gateway IP) of any Docker
bridge network in NAT mode is firewalled from access from the outside.
This essentially implements on Docker level what Supervisor applies on
startup with https://github.com/home-assistant/supervisor/pull/6650.
Upstream PR: https://github.com/moby/moby/pull/52224.
Afer builder changes, ARM images are now correctly published with their
platform, and when skopeo is used to inspect/pull the image on x86 without any
other flags, it fails with:
Error parsing manifest for image: Error choosing image instance: no image found in image index for architecture amd64, variant "", OS linux
Pass the correct arch in skopeo operations to fix that.
* Bumped to latest version
* Changed to HTTPS download source
* Updated build dependencies (mirroring package/qemu)
* Added path to host Python (same as package/qemu)
* Removed meson flag (no longer needed)
* Added --disable-linux-io-uring (new in v10)
* Replaced old --disable-user by per-OS flags
* Removed duplicated flags
* Sorted flags alphabetically for easier maintenance
Fixes#4336
Update the patch adjusting findBootFS for HAOS. Make sure that the hardware
survey is performed before that so we know if we can/should use flashrom on
Pi 5 with NVMe.
Fixes#4574
* RaspberryPi: Update kernel to 6.12.75 - 89050b1059997d38d55462b323b099a6436dc10d
Raspberry devs now don't seem to care about updating any of the repositories
following a kernel release anymore so the hash for the latest release was
determined from the source package of the latest APT release.
* Update rpi-firmware
* buildroot d9cb724f06...be34a81850 (1):
> package/rpi-firmware: update to eb3ee43 (for 6.12.75)
* Add patch fixing serial in U-Boot, refresh patches
Change in DTS includes shadowed previous patch adding U-Boot-specific
compatible string for UARTs. Make sure that AMBA UARTs in device trees also
contain compatibles consumed by U-Boot as fallback.
Also, refresh RPi patches with --zero-commit.
Remove net.ipv6.conf.all.forwarding=1 from 60-otbr-ip-forward.conf
and rely on Docker to enable IPv6 forwarding instead, just as we
already rely on it for IPv4 forwarding (needed for NAT64 in OTBR).
When this sysctl was added (d9ec60316), Docker did not enable IPv6 by
default. Since Docker 27 (April 2024), IPv6 support — including
ip6tables — is enabled by default, and Docker enables IPv6 forwarding
at startup just like it does for IPv4.
Importantly, when Docker enables forwarding itself (rather than finding
it already on), it also sets the FORWARD chain policy to DROP as a
safety measure, Pre-enabling the sysctl prevents this, leaving the IPv6
FORWARD chain at ACCEPT. By removing our sysctl, we get the same
protective DROP policy for IPv6 that we already benefit from for IPv4.
Supervisor takes a logind delay inhibitor lock on startup and releases it
after gracefully stopping all add-ons, Home Assistant Core, and plugins in
the correct order. The default 5s window is far too short — Core alone can
take 40+ seconds to stop. 300s gives enough headroom for a clean shutdown.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
The retry when fetching containers from the registry didn't work because the
script was executed with `set -e`. Capture the error code also for non-zero
exit status.
Also use while loop instead of recursion and back off exponentially - start
with 5s and multiply by 3 (i.e. 5s, 15s, 45s - waiting in total up to 1 minute
for the registry to recover).
Backport NetworkManager patch (backported alsso in upstream to v1.56.0) to
restrict connectivity check lookups to per-link DNS. This reduces the number of
DNS queries performed by NetworkManager itself.
Note that Supervisor has its own connectivity check routine which is
independent on this one, so user may still see more requests in a 10 minute
interval.
Closes#4560
Set wifi.powersave to 2 (disabled) in NetworkManager settings by default for
all connections. Since HAOS is generally used on servers, powersaving doesn't
bring any obvious benefit and is often cause of problems and higher network
latency. If needed, nmcli can be used to override the new default.
Refs #3832
For some messages, RAUC uses GLib's structured logging API, which doesn't add
the SYSLOG_IDENTIFIER implicitly, like the convenience messages do. Backport a
patch submitted upstream which add this field to all messages, making all RAUC
logging available when rauc identifier is queried.
Jan Čermák
Stefan Agner
zekiz774
Jan Čermák
Jens Maus
Klara