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
* buildroot 31f3962adb...7b12acaaf5 (3):
> fs/erofs: add option for multithreaded compression
> package/erofs-utils: add option for enabling multithreading support
> package/erofs-utils: bump to version 1.8.10
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
* buildroot f4f1427609...31f3962adb (4):
> package/docker-cli: bump version to v29.7.2
> package/docker-engine: bump version to v29.7.2
> package/containerd: bump version to v2.3.3
> package/runc: bump version to v1.4.3
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>
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>
* Adapt OS update test to Supervisor no longer auto-rebooting
Since Supervisor 2026.07 (home-assistant/supervisor#6982) a successful
/os/update no longer reboots the host automatically. It installs the
bundle to the other slot, marks it as the pending boot slot (exposed as
"version_pending", see home-assistant/supervisor#7006) and raises a
reboot-required repair issue, leaving the actual reboot to the user.
test_os_update still waited for an immediate "Booting `Slot " right after
`ha os update`, so when run against a 2026.07+ Supervisor it timed out and
failed (cascading into test_supervisor). This is why the QEMU test job
started failing on the dev builds built after 2026-06-30.
Adapt the test to the new flow:
- run `ha os update` and wait until the update is installed as pending
(version_pending == target), retrying only while the OTA URL is not
available yet; re-requesting an already-installed version is rejected.
- apply the pending update with `ha host reboot` and wait for the new
slot to boot.
- assert the new version is running and nothing is pending anymore.
Verified end-to-end in QEMU against the current dev image with the latest
Supervisor: the update stages to slot B (version_pending=18.1, still
booted on A), `ha host reboot` boots slot B, and afterwards version=18.1
with version_pending cleared.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test_os_update: address review feedback on the update poll loop
- Bound the retry loop and fail with the last `ha os update` output instead
of relying on the global test timeout when the update never installs.
- Tolerate a transient `ha os info` CLI failure (|| true + defensive JSON
parse), matching the pattern already used in test_init.
- Use dict.get() for the post-reboot version_pending assertion.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test_os_update: harden update poll against null data and timeout budget
- `ha os info --raw-json` returns "data": null on an error result; coerce it
to an empty dict so the version_pending lookup can't raise AttributeError.
- Lower the per-attempt timeout to 120s and the retry count to 4 so the
loop's worst case stays within the test's 600s timeout budget.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CONFIG_FEATURE_FANCY_PING (enabled in #4854, HAOS 18.2) turns `ping HOST`
into a continuous ping that never returns without an explicit count. The
offline smoke test's connectivity helper ran a bare `ping 1.1.1.1`, so on
18.2+ it blocked until the pytest timeout instead of doing a single probe,
failing test_ha_runs_offline (and cascading into the following test modules).
Detect the applet at runtime and adapt: use `ping -c 1 -W 2` when the fancy
applet is available (which bounds the run), and fall back to the minimal
one-shot `ping HOST` otherwise. Match both output styles ("HOST is alive!"
vs. ping statistics) and accept "100% packet loss" as a disconnected result.
Runtime capability detection keeps the test working on both pre- and
post-18.2 images without hard-coding version numbers.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* buildroot c1438cf214...dfa1d775aa (5):
> package/runc: bump version to v1.3.6
> package/containerd: bump version to v2.2.6
> package/docker-cli: bump version to v29.6.2
> package/docker-engine: bump version to v29.6.2
> Merge tag '2025.02.16' into 2025.02.x-haos-merge-buildroot-2025.02.16
* 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>
Jan ČermákandGitHub
Stefan AgnerandGitHub
joelmansfordandGitHub
KingKaomandGitHub
Franck NijhofandGitHub
