The haos-expand.service ("HAOS data resizing") is a Type=oneshot unit
without an explicit timeout, so it inherited systemd's
DefaultTimeoutStartSec (90s). On slow or previously used disks the data
partition resize can take longer than that, causing the service to be
killed and mnt-data.mount to fail with "Dependency failed for HAOS data
resizing", leaving the system unusable.
Aborting the resize serves no purpose: if it fails the installation is
broken anyway. Set TimeoutStartSec=infinity so the resize runs for as
long as it needs instead of failing the boot.
Fixes#3365
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Enable CONFIG_DRM_ACCEL_IVPU on the generic-x86-64 and OVA boards so the
Intel NPU (Neural Processing Unit) found on Core Ultra CPUs (Meteor Lake
and later, including Panther Lake) is exposed as /dev/accel/accel0. This
lets add-ons such as Frigate use OpenVINO with hardware-accelerated
inference on the NPU.
Also select the Intel NPU firmware (intel/vpu/vpu_*.bin), which already
ships in linux-firmware 20260410 including the Panther Lake (vpu_50xx)
blob.
The driver is x86_64-only, so it is added to the per-board configs rather
than the shared device-support-pci.config which is also used by aarch64
boards.
Fixes#4783
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The kernel bump to 6.18 means newer Intel Wi-Fi 7 devices (BZ/GL/SC/DR
families, e.g. the BE200) are no longer handled by the iwlmvm op-mode.
Their firmware now requires the new iwlmld driver, and without it the
iwlwifi core aborts the probe with:
IWLMLD needs to be compiled to support this firmware
probe with driver iwlwifi failed with error -22
Enable CONFIG_IWLMLD so these devices bind again. The matching firmware
(iwlwifi-gl-*) already ships via linux-firmware.
Fixes#4784
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Enable usbip on all targets
Enable the usbip userland tools (BR2_PACKAGE_USBIP), already provided by
the pinned Buildroot (package/usbip), to attach remote USB devices over
the network. The USBIP kernel modules are already enabled via
device-support.config.
This is the OS-side prerequisite for driving USB/IP from os-agent
(home-assistant/os-agent#265).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Fix configs ordering using savedefconfig
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Jan Čermák <sairon@sairon.cz>
(cherry picked from commit c8b9d5919b)
After #4762, NFS_V4 was set as module in ODROIDs, Green and VIM3
kernels. This is because their defconfigs set the upper NFS_FS symbol to
module. Set it to built-in in these defconfigs as well (for other
targets this is handled by defconfigs from the kernel) and remove
redundant options we set in the haos fragment.
(cherry picked from commit e2a0c9bb3b)
* Add sanity checks for correct release channel to the build workflow
There's currently nothing preventing us from publishing RC build to the
stable channel if the GH release is configured incorrectly. Since we
have the meta file which dictates where the deployment should go, use
this as a sanity check and reject the workflow if the expected
configuration doesn't match.
* Improve the check to validate version string as well
(cherry picked from commit b4977ed0a9)
* buildroot 89ddb15854...78450fa882 (3):
> package/runc: fix regression with kernel without user namespace
> Revert "package/runc: fix regression with kernel without user namespace"
> Merge tag '2025.02.15' into 2025.02.x-haos
* Enable usbip on all targets
Enable the usbip userland tools (BR2_PACKAGE_USBIP), already provided by
the pinned Buildroot (package/usbip), to attach remote USB devices over
the network. The USBIP kernel modules are already enabled via
device-support.config.
This is the OS-side prerequisite for driving USB/IP from os-agent
(home-assistant/os-agent#265).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Fix configs ordering using savedefconfig
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Jan Čermák <sairon@sairon.cz>
After #4762, NFS_V4 was set as module in ODROIDs, Green and VIM3
kernels. This is because their defconfigs set the upper NFS_FS symbol to
module. Set it to built-in in these defconfigs as well (for other
targets this is handled by defconfigs from the kernel) and remove
redundant options we set in the haos fragment.
* Add sanity checks for correct release channel to the build workflow
There's currently nothing preventing us from publishing RC build to the
stable channel if the GH release is configured incorrectly. Since we
have the meta file which dictates where the deployment should go, use
this as a sanity check and reject the workflow if the expected
configuration doesn't match.
* Improve the check to validate version string as well
Borrow shrinking used in home-assistant/operating-system-full-images for
reducing the data partition size to only fit its contents. Currently the
data partition is intentionally overprovisioned to comfortably fit all
docker images in the hassio build. This results in unnecessarily large
image which takes longer to flash, as all the zeroes at the end of the
filesystem need to be written to the SD card.
For OVA and aarch64 VM formats, the image is resized before creating the
VM images - this also makes all generic-aarch64 images sized to 32GB,
unlike 6GB which inherently needed resizing before use. Some juggling
extra juggling is needed in the aarch64 post-image step, as we want to
preserve the raw image (e.g. for generic aarch64 boards) but it's
desirable to keep it minimal as well, as it's meant to be flashed to
real hardware storage.
Not all defconfigs enable NFS v4.1/v4.2 by default, most importantly
it's not enabled for x86_64 (on the other hand, it is enabled on RPi,
Rockchip and Amlogic). Explicitly enable NFS_V4 and its minor versions
in the common config fragment to ensure it's available everywhere.
It can now be removed from the Rochckip fragment, while removing the
migration option there for good (as Kconfig says it's very
experimental).
Fixes#4742
Add certificates with new PKI chain to replace the old one. Until May
14th 2028, bundles signed with the old certs will be accepted as well.
The transition to the new authority using bundles signed by the new
certs is ensured by the intermediate certificate signed by the old CA.
This, and the old CA certificates can be removed from the keyring after
their expiry.
The keyrings no longer contain CRLs, but the validity of the
certificates will be shortened to 4 years, as discussed in the linked
issue.
Closes#4743
The rule using 33% of RAM for default swapfile size had flaws both for
low and high RAM systems - for the former the swap was too small to
provide any buffer for OOM situations, for the latter it created
unnecessarily big swapfile.
Clamp the swapfile size to 1-4 GB. This means the file will somewhat
grow on systems with 1 or 2 GB of RAM, but this should be within bounds
of what's reported by HA as low storage. For systems with >12 GB of RAM,
the swap file wouldn't be created larger than 4 GB (in fact, will be
recreated if bigger). The configured size is still respected.
Closes#4481
Enable the JMicron JMC25x Gigabit Ethernet driver (CONFIG_JME) in the
kernel configuration.
This controller (specifically the JMC251) is very common on various
budget mini PCs (often used as Home Assistant nodes) but currently lacks
native driver support in Home Assistant OS out of the box. Adding these
flags restores native network connectivity for these devices.
* Add CI check for sufficient validity of the OTA signing certificate
To ensure that we don't miss expiration of the signing certificate, add
a CI check that checks its validity and validity of the full chain of
trust, ensuring CA doesn't expire either. Currently set to 25 months,
which should be enough to allow migration of existing devices to new CA
and allow some wiggle room for upgrades and downgrades.
Refs #4743
* Find real issuer when walking the chain
* Add number of certs checked to the suceess message
Enable Intel Xe driver as a module and the related linux-firmware
option for generic-x86-64 and ova.
The bloat in generic-x86-64 image is 1.2MiB, which is acceptable.
Closes#4611
In #4279 we enabled PSI globally. However, Raspberry Pi config enables
it along with CONFIG_PSI_DEFAULT_DISABLED, which requires adding a
cmdline option to expose PSI metrics. Add a global disable for this
option to enable PSI on all targets unconditionally.
Fixes#4616
* Harmonize systemd unit and helper-script prefixes to haos (#4725)
Rename the hassos-prefixed systemd units and their ExecStart helper
binaries to a consistent haos- prefix, and update all in-repo
references. Normalize the affected unit Description= strings as well.
Units renamed in this commit are not referred externally (except for
syslog identifiers used in Supervisor Host logs), so no other changes
should be needed.
* Rename hassos-config to haos-config with alias
Rename the hassos-config.service unit and its binary to the haos-
prefix. This unit is restarted by Supervisor in os/manager.py, so add
Alias= to avoid the need to try both variants there.
* Rename hassos-cli binary to haos-cli
* Change HassOS to HAOS in unit descriptions and comments
* Rename hassos->haos in Buildroot makefiles, scripts and configs
* Rename bootargs_hassos to bootargs_haos in U-Boot scripts
* Rename external Buildroot tree HASSOS to HAOS
Set external.desc name to HAOS and rename all BR2_EXTERNAL_HASSOS_PATH
references to BR2_EXTERNAL_HAOS_PATH accordingly.
* Rename hassos.conf service drop-ins to haos.conf
* Rename hassos.config kernel fragment to haos.config
* Rename hassos-blobs repo in package/bluetooth-rtl8723
The repo was renamed somewhere in the past and it now relies on an
internal GitHub redirect. Change the URL to match the new repo name.
When the update command returns no response, which may happen after the
shutdown reordering implemented as part of #4642, the OS update test
hangs waiting for this response. To fix it, fire away the OS update
command and wait either for message about missing OTA info or for early
boot output.
Since switching to systemd-resolved we've announced Home Assistant
Operating System as a workstation through _workstation._tcp DNS-SD. This
most likely came in to preserve what avahi announced by default.
However, the service has not a clear definition what it means and there
is no need for the service announcement really. The host name gets
announced even without a service announcement. This commit removes the
service announcement file from the rootfs.
* RaspberryPi: Update kernel to 6.18.32 - e165a3e0c5c6729d077c30c6d720c029d688d99d
* Update rpi-firmware to 1.20260521
* buildroot 1c0db348e3...c80dabe55e (1):
> package/rpi-firmware: update to 09267f5 (1.20260521)
* Use 6.18.y kernel config fragments, remove now unused 6.12.y
* Refresh patches and removed merged backports
* Update Yellow patches
Fix collision in the Makefile and add difference in phy1 fragment which
was added upstream in e6f13c8f14d9b776363ddd4966065eac3a8f7bb9:
ARM: dts: bcm2711: enable PHY link energy detect powerdown via DT
* Disable rtl8812au-aircrack-ng in Yellow defconfig
Yellow was the only one still including it and it doesn't build on 6.18.
* Drop removed symbols from RPi kernel config fragment
Give Supervisor enough time to gracefully stop Home Assistant Core, apps
and plugins when the host shuts down. The unit is already ordered
After=docker.service, so on a host reboot or power off it is stopped
before Docker tears containers down.
Supervisor should handle the SIGTERM from "docker stop" by running its
managed shutdown within 420 seconds, after that point it would be killed
by Docker, and ultimately 30 seconds later by Systemd.
Also, drop the delay after SIGTERM for ha-cli added in #2507. Once
Systemd shutdown is invoked, the ha-cli is no longer restarted.
Refs #4642, refs #4584
On CM4, rpi-eeprom-update only prints warning if the env variable
enabling self-update isn't set. In that case, also print bootloader info
so we can propagate it further.
Also, add patch making findBootFS faster, avoiding scan of all block
devices.
Refs #4631
Add firmware for MT7920, used by mt7921e and btmtk drivers. Note that
this card is also referred as MT7961_1a but the marked name is MT7920
(see [1]).
* buildroot 584f1d7531...1c0db348e3 (1):
> package/linux-firmware: add WiFi and BT firmware for MT7920
[1] https://lists.infradead.org/pipermail/linux-mediatek/2024-November/085899.htmlCloses#4460
Stefan AgnerandClaude Opus 4.8
dependabot[bot]
Jan Čermák
Pascal Vizeli
Jan Čermák
MaxPowerFood
James