This release makes the agent only load AppArmor profiles whose name
matches the profile file name. Profiles are enumerated with
`apparmor_parser --names` before load/unload, and any profile which is
not the file's base name or a child profile/hat of it is rejected. This
prevents an add-on supplied apparmor.txt from redefining unrelated
profiles such as docker-default or hassio-supervisor.
Full changelog:
* https://github.com/home-assistant/os-agent/releases/tag/1.14.0
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
containerd fsyncs its metadata database when committing a snapshot, but
never syncs the unpacked layer data itself. On an unclean shutdown
within the writeback window after an image pull this leaves layers with
zero-byte files (correct names/modes/mtimes, no data) while the
snapshot stays durably recorded as valid. Because existing snapshots
are never re-verified or re-unpacked, such corruption even survives
deleting and re-pulling the image, and with shared base layers it can
only be recovered by wiping the Docker storage entirely.
This is the failure signature behind a growing number of reports of
broken plugins/add-ons/Core after power loss (e.g. 0-byte coredns in
home-assistant/plugin-dns#207, supervisor#6476/#6835, #4913).
Enable the containerd diff-service sync_fs option (containerd >= 2.0,
containerd/containerd#10284): the daemon then issues one syncfs(2) per
applied layer, making unpacked data as durable as the metadata that
references it. It applies to all clients of the daemon, including
dockerd with the containerd image store.
Verified in QEMU on haos 18.3.dev (Docker 29.6.2, containerd 2.2.6):
* With completely stock settings, a power cut <1s after `docker pull`
of the DNS plugin image corrupts the image 2 out of 2 runs: one run
zeroed /usr/bin/coredns entirely, the other zeroed the s6 scripts
and left coredns truncated (20021248 of 25919650 bytes) - matching
the two damage profiles reported in plugin-dns#207.
* Deterministic A/B with kernel background writeback suppressed, so
survival can only come from the stack syncing explicitly: without
this option 1215 zero-byte files including a 0-byte coredns failing
with "exec format error"; with sync_fs the image survives intact
(152 kB dirty at the power cut vs 76 MB).
* strace on containerd confirms 0 syncfs calls per image load before,
one per layer after - which also confirms dockerd pulls route
through the containerd daemon's diff service where this option
takes effect.
* Cost of loading+unpacking the 2 GB Core image: 41.6s -> 42.2s on a
fast disk, 226s -> 230s (+1.9%) on a 30 MB/s / 250 IOPS throttled
disk. Note QEMU throttling does not model SD-card sync latency, so
the real-world cost on the slowest cards may be somewhat higher, but
it stays bounded at one syncfs per layer.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The persistent timesyncd configuration is a single bind-mounted file
over /etc/systemd/timesyncd.conf. The NTP configuration through OS Agent
(home-assistant/os-agent#207) attempted to do atomic updates, but a
temporary file cannot be created next to it in the read-only
/etc/systemd, and replacing the file in the overlay directly changes the
inode, so the bind mount keeps pointing to the old content. Also, a
persisted copy of the whole file means changes to the shipped defaults
never reach existing installations.
Bind-mount the /etc/systemd/timesyncd.conf.d directory from the overlay
instead and keep the shipped timesyncd.conf read-only. Configuration is
layered as drop-ins, from lowest priority to higher:
* 10-ntp.conf (in /run): NTP servers from DHCP
* 20-custom.conf: timesyncd.conf imported from the CONFIG partition
* 50-os-agent.conf: NTP servers set through the OS Agent D-Bus API
On upgrade, settings from the previously persisted timesyncd.conf other
than the shipped defaults are moved to 20-custom.conf. This migration
can be removed later (with #4986). 50-os-agent.conf should be only
managed by OS Agent, so we don't need to care about user's edits.
Finally, if needed, drop-ins with higher priorities can be added for
complex customizations.
Refs home-assistant/supervisor#6278
Supervisor pairs every network mount with a systemd .automount unit,
so the kernel automounter is a hard requirement for network storage.
Today the option is only enabled as a side effect: Buildroot's systemd
package force-enables CONFIG_AUTOFS_FS through its kernel config
fixups. That works — it even overrode the explicit disable the
Raspberry Pi config carried until 11.2 — but nothing in our configs
states the dependency, and the fixup skips symbols already set to =m,
which leaves the Rockchip boards (Green, ODROID-M1/M1S) with autofs as
a module while every other board has it built in.
Set the option in the shared fragment to document the requirement and
build it in everywhere.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Corrupted Docker image layers cannot be always fixed by removing and
re-pulling a single image, because layers are shared between images. The
only (easy) way to recover is wiping all of Docker's storage which is
currently cumbersome and requires OS shell access.
Add service triggered by /mnt/data/docker/.wipe-scheduled flag file
which wipes the Docker directory by atomically renaming it and deleting
synchronously. If this is interrupted, docker-prepare script removes the
leftovers before Docker is started on every boot.
It should be noted that docker-prepare also forces the switch to
containerd snapshotter after the wipe.
Refs home-assistant/supervisor#6555
The rootfstype parameter was removed in HAOS 13.0 when the root
filesystem switched from SquashFS to EROFS in #3456, because during the
transition one slot could still contain a SquashFS rootfs. The enforced
upgrade path now only allows upgrading from 15.2 or newer, so after an
update both slots are guaranteed to contain an EROFS rootfs and the
parameter can be added back. Specifying rootfstype avoids probing other
filesystem types when mounting the rootfs.
For U-Boot boards add rootfstype=erofs to the boot scripts and to the
grub.cfg on UEFI targets. On Raspberry Pi 5 the cmdline.txt on the boot
partition persists across updates, so adjust it in a targeted migration
in the RAUC hook. The migration replaces the obsolete removal of
rootfstype=squashfs, which is already handled on all systems the update
can be installed from.
Move the F2FS configuration to the shared haos.config kernel fragment
so it is enabled on every board. Until now only the Rockchip boards
(built-in) and Khadas VIM3 (module) had F2FS support. Build it in with
security xattrs enabled, so Docker layers containing files with
security.* attributes work on an F2FS data disk, and with compression
support to keep feature parity with the Rockchip kernels.
Remove the F2FS options from the Rockchip and Khadas VIM kernel configs
superseded by the shared fragment. CONFIG_F2FS_CHECK_FS previously
enabled on Rockchip is intentionally not carried over, as it is a
development option adding runtime consistency checks.
Refs #4969
Some recent features (e.g. #4809, #4816, #4837) increased the rootfs
bloat between 18.0 and 18.1, bringing the rootfs size on OVA and
generic-x86-64 just 0.5 MiB below the 256 MiB cap, blocking us from
adding new features that require space in the rootfs. To gain some
space, also start compressing large daemon binaries using the LZMA
algorithm. The selected binaries are normally invoked only once per
boot, so the runtime cost of the more expensive decompression is
minimal.
The same compression hints are now used for OVA, where it brings us
around 45 MiB in the rootfs partition image
On CM5 Lite, kernel keeps polling the mmc0 interface indefinitely as it
doesn't indicate the non-removable property while it has no SD card
slot. Patch the BCM2712 Yellow device tree to poll only once.
Fixes#4961
Apply patch implementing HW flow control in BCM2835's mini UART and
indicate the RTS/CTS is wired in Yellow's device tree to enable using
the flow control for the Bluetooth interface. This greatly improves
stability of the Bluetooth interface, which started to be unstable with
kernel update to 6.18 in OS 18.0 and newer.
Fixes#4898
U-Boot's default bootm_size (512 MiB) makes booti relocate the FDT to
just below 0x20000000. This is fragmenting the linux,cma alloc-range
(first 768 MiB on BCM2711) so the default 512 MiB CMA allocation can't
be made and falls back to 8 MiB. The framebuffer console then fails to
allocate and HDMI output stays blank on displays larger than 1920x1080.
Set fdt_high to the firmware-provided FDT address so U-Boot places its
copy right below it, above the CMA alloc-range.
Fixes#4924
Add patches reordering uartX nodes in the device tree to be less
confusing and remove the hardware flow control indication property for
UART0 which is not in effect, but invalid.
On Intel N150 panel PCs, HAOS already binds Intel LPSS + DesignWare I2C
so ACPI device GDIX1002 appears on the bus, but no input device is
created because i2c-hid-acpi does not match GDIX1002 (no PNP0C50 CID)
and CONFIG_TOUCHSCREEN_GOODIX is disabled.
Enable the Goodix driver as a module so GDIX1002 can bind.
Co-authored-by: angelolsantos <angelolsantos@users.noreply.github.com>
SENSORS_APPLESMC depends on X86 && ACPI, so requesting it in the shared
device-support.config fragment has no effect on non-x86 boards and
causes a config check warning on generic-aarch64:
SENSORS_APPLESMC=m requested, actual = n
Move it to the generic-x86-64 board kernel config next to the other
x86-only hwmon drivers. The Apple SMC is only present on bare-metal
Intel Macs, which use the generic-x86-64 image.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Dropbear has no ordering relationship to haos-supervisor.service or
docker.service, so systemd schedules all three stop jobs in the same
batch and runs them concurrently. Dropbear exits within milliseconds
while the Supervisor gets up to 450s to stop containers, which means an
SSH session is dropped right when the interesting part of shutdown
starts. That makes it needlessly hard to debug slow shutdowns.
Order Dropbear before both units. Since stop order is the reverse of
start order, systemd now stops it only once the Supervisor and Docker are
gone. This is an ordering-only dependency: if Dropbear fails, is masked
or is skipped by its ConditionFileNotEmpty=, the ordering counts as
satisfied and both units start as before. It adds no boot latency
either, as docker.service already waits for the overlay partition that
Dropbear needs for /etc/dropbear.
Verified on a generic-x86-64 VM: an SSH session now survives the full
22.4s Supervisor teardown, and systemd stops Dropbear last, 3ms after
docker.service is gone.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The HA CLI unit (and the serial getty drop-in) pulled in
haos-supervisor.service via Wants=. Since #4326 the CLI unit is
configured to never reach its start limit (RestartSec=100ms,
RestartMaxDelaySec=3s, StartLimitIntervalSec=3s), so it restarts
indefinitely - and every restart starts the Supervisor again.
This makes it impossible to stop the Supervisor for debugging: stopping
haos-supervisor.service and removing the containers terminates
hassio_cli, which makes ha-cli@tty1.service exit and restart, which
immediately starts the Supervisor back up.
The Wants= is not needed: haos-supervisor.service is
WantedBy=multi-user.target and gets started on boot regardless. Drop it
and keep only the After= ordering.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The APC Easy UPS On-Line SRV series uses a MaxLinear/Exar USB-UART bridge
(04e2:1410) for its USB interface. Without xr_serial it binds to cdc_acm
and NUT cannot communicate with it. The same UPS works on Linux where
xr_serial is available.
The driver is already in mainline, so this is a config-only change
alongside the USB-serial drivers already enabled here.
* Enable Intel RAPL / powercap on generic-x86-64
Enable the powercap framework and the Intel RAPL driver so that CPU and
package energy counters are exposed via /sys/class/powercap. This allows
Home Assistant to monitor the power consumption of the host it runs on
(e.g. via a command_line sensor reading energy_uj) without external
hardware. The intel_rapl_msr driver also covers modern AMD (Zen) CPUs.
energy_uj has been root-readable only since kernel 5.10, so this does not
reintroduce the PLATYPUS side-channel concern.
Closes#4907
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Update buildroot-external/board/pc/generic-x86-64/kernel.config
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Enable Intel LPSS DesignWare I2C for integrated touchscreens
CONFIG_I2C_HID_ACPI alone cannot bind Goodix (and similar) panels on
Intel N-series machines because the Serial IO I2C controller
(PCI 00:15.x) never comes up without MFD_INTEL_LPSS_PCI and
I2C_DESIGNWARE_*. Also enable PINCTRL_ALDERLAKE for Twin Lake / ADL-N
pinmux (e.g. Intel N150 panel PCs).
Co-authored-by: Cursor <cursoragent@cursor.com>
* Apply suggestion from @agners
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Apply suggestion from @agners
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: angelolsantos <3864987+angelolsantos@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Stefan Agner <stefan@agner.ch>
Some Intel systems expose their internal NVMe storage through Intel
Volume Management Device. Without the VMD driver, HAOS cannot discover
the root device and stops at unknown-block(0,0).
Enable CONFIG_VMD in the generic x86-64 kernel configuration. Build the
driver into the kernel because it is needed before the root filesystem
can be mounted.
Related to #3494
Co-authored-by: andreabosman16 <22190719+andreabosman16@users.noreply.github.com>
Co-authored-by: Codex <noreply@openai.com>
The Crucial X9 portable SSD (Micron, USB ID 0634:5605) suffers from
constant UAS command aborts and device resets under sustained writes on
Raspberry Pi, eventually remounting the filesystem read-only. Add the
IGNORE_UAS quirk so the device falls back to the usb-storage (BOT)
driver, matching the existing quirk entries for similarly affected
bridges.
Fixes#4787
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The Tailscale add-on uses CONNMARK rules (via iptables-nft) as part of
its rp_filter workaround. Since xt_connmark is not available, the
add-on logs warnings like:
Warning: Extension CONNMARK revision 0 not supported, missing kernel module?
router: warning: failed to add connmark rules (rp_filter workaround may not work)
Enable CONFIG_NETFILTER_XT_CONNMARK, which provides both the CONNMARK
target and the connmark match (CONFIG_NETFILTER_XT_TARGET_CONNMARK and
CONFIG_NETFILTER_XT_MATCH_CONNMARK are just backwards-compat aliases
for it). Native nftables connection mark support is handled by nft_ct,
which is already enabled.
Fixes#4887
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The RAUC custom bootloader backend for the Raspberry Pi 5 firmware
tryboot mechanism reported the committed boot slot (rauc.slot in
cmdline.txt) as primary even while an installed update was staged for
tryboot. Since Supervisor recovers an installed-but-not-yet-activated
OS update by comparing RAUC's primary boot slot with the booted one
(home-assistant/supervisor#7006, home-assistant/supervisor#7022), such
updates were invisible to it on RPi 5 once Supervisor restarted in the
window between install and activation reboot.
Report the staged slot as primary as long as the tryboot reboot is
armed (/run/systemd/reboot-param). Since /run is volatile and the
firmware attempts a tryboot exactly once, a staged tryboot found
without an armed reboot parameter has missed its attempt (power cut
before the activation reboot, or the tryboot failed and the firmware
fell back to the default slot): drop the staged files and mark the
staged slot bad instead of leaving them around forever. Marking the
committed slot active (or the staged slot bad) now also cancels a
staged tryboot, matching the GRUB and U-Boot backend semantics.
Also fix committing the tryboot state: the firmware's tryboot flag
stays set for the entire boot, so the existence of cmdline-tryboot.txt
cannot indicate a pending commit. Installing an update in the same
boot the system tryboot'ed into (routine for back-to-back updates)
made every subsequent mark-good fail with "tryboot doesn't reflect
the expected boot slot". Commit only when the booted slot is not the
default boot slot yet.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Restore cfg->f_max to 100 MHz (revert upstream 8fa0db1) in hopes the
100->40 MHz reduction in U-Boot 2026.04 is what soft-bricks certain
eMMC modules on ODROID-N2 after the HAOS 18 update (#4788). The f_max
HACK (0001) only caps the *first* init attempt to 24 MHz; modules that
fail at 24 MHz fall back to cfg->f_max, so this ceiling governs them.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Since kernel 6.18, the stmmac driver no longer disconnects and
reconnects the PHY when the MTU is changed on a running interface
(upstream commit db299a0c09e9 ("net: stmmac: move PHY handling out of
__stmmac_open()/release()")). The interface reopen now performs the
MAC's DMA software reset while the PHY is suspended. PHYs are allowed
to stop their receive clock while powered down, and the DMA reset
requires a running receive clock, so on affected boards -- e.g. the
Home Assistant Green (RK3566 with RTL8211F-VD PHY) -- a runtime MTU
change kills networking entirely:
rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma
rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed
rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed
rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change
In the field this is triggered by NetworkManager applying an MTU while
activating the connection, leaving affected Green systems without
network after updating to HAOS 18.x.
Add a patch which resumes a suspended PHY when opening the interface,
before the hardware setup, as the driver already does on system
resume. Verified on a Home Assistant Green: `ip link set end0 mtu
1400` reliably reproduced the failure before and now completes with
the link renegotiating as on 6.12.
Fixes#4858
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Make Supervisor startup resilient to transient network failures
When the Supervisor image is missing and no local updater information is
available (e.g. on first boot after a factory reset/data wipe), the start
script fetches the current stable version from version.home-assistant.io.
This fetch can fail transiently: since #3669 the boot waits at most 15s
for time synchronization, so the script may run with an unsynced clock
(making TLS validation fail), or before the network is fully functional.
Today such a failure makes the script exit within ~400ms (via jq -e exit
code 4 under set -e). Combined with RestartSec=5s and StartLimitBurst=3,
three quick failures trip the start rate limit within ~15 seconds and the
unit stays failed until reboot - even if NTP syncs moments later, leaving
the device at the emergency console (as seen in #4863).
Make this path more robust:
- Let curl retry the version fetch (5 retries, 10s apart). Use
--retry-all-errors so DNS/TLS failures are retried as well, not just
transient HTTP errors.
- Increase the service start rate limit from 3 to 5 attempts per 30
minutes, so a slightly longer network/time-sync hiccup at boot doesn't
permanently disable the unit.
- Skip "docker image rm" in the startup-marker recovery path when there
are no Supervisor images at all, avoiding a spurious usage error.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix AppArmor profile download never retried after first failure
The haos-apparmor script only downloads the Supervisor AppArmor profile
when the profile directory is missing - but it creates the directory
before attempting the download. If the first download fails (e.g. no
DNS/network on first boot after a data wipe), every subsequent boot
skips the download because the directory exists, and the unit exits
successfully without loading any profile. The Supervisor container is
then created with --security-opt apparmor=hassio-supervisor and fails
to start forever with:
apparmor failed to apply profile: write .../attr/apparmor/exec:
no such file or directory
(observed in #4863 after the reporter fixed their DNS setup).
Key the download on the profile file instead of the directory, download
to a temporary file that is moved into place only on success, and let
curl retry transient failures like in the Supervisor version fetch.
Also fail the unit loudly when the download does not succeed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Apply suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Use upper case for STABLE_JSON variable
Match the naming convention of the other variables in the script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Following on from enabling CONFIG_SHOW_USAGE=y.
Rationale: make it easier to debug the host OS.
Size increase of libbusybox.so: +32 KB over CONFIG_SHOW_USAGE=y
baseline.
We could enable COMPRESS_USAGE to bring it down to +8KB over
CONFIG_SHOW_USAGE=y baseline, but I'm not sure it's worth optimizing?
If we want to compress, it's probably fine: just a slight CPU hit when
asking for CPU usage, which is probably fine for interactive use.
This lets us run `which`
I've found myself wanting this a bunch while trying to figure out, well,
which binary I'm running. I can walk $PATH myself, but it's no fun.
libbusybox.so size impact: +0 bytes (that is, it's less than the
4KB-padded text section we already have).
Jan Čermák
Stefan AgnerandClaude Fable 5.1
Jan Čermák
dlxmaxanddlxmax
angelolsantosandangelolsantos
joelmansford
KingKaom
Mark Hansen