* 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
When there's a problem with connectivity, it may result in obscure errors later
in the testing. Add checks testing three scenarions:
* connectivity in host - both using curl and nmcli
* connectivity in Supervisor container (uses docker0 as default via)
* connectivity in CLI container (uses hassio as default via)
Also make sure that Supervisor upgrade isn't attempted when the version
information is missing.
To avoid necroposting to old issues that's usually left unnoticed, add workflow
for locking issues similar to the one that Core has.
The PR locking limit can be increased as the traffic is much lower compared to
Core. Issues before 2025 have been locked manually via the API.
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
Update Docker and its dependencies to versions packaged in last bugfix release.
* buildroot 3914f8cad5...4cd211162d (4):
> package/runc: bump version to v1.2.6
> package/docker-cli: bump version to v28.0.4
> package/docker-engine: bump version to v28.0.4
> package/containerd: bump version to v1.7.26
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
We check that landing page is working when the network is down but we don't
check it in the happy path. Add its test to make it more obvious when the
just landing page is broken.
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
(cherry picked from commit 24640c11aeb89290f7a1ecfd0c8c6527f8523e27)
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
Add missing patch and update for latest runc version to fix losing device
permissions when new devices are added in runtime.
* buildroot b079a02a9a...3914f8cad5 (2):
> package/runc: add patch for extended default allowed devices in v1.2.4
> package/runc: add missing patch to fix device permissions update
Fixes#3915
(cherry picked from commit 04debe2f539c4275fd68fe4d38fee3f8b8bab84b)
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).
(cherry picked from commit 173a4388fe7ee2f26c277b6c2dccdcab1b9f0a58)
* Add test checking journal logs for dependency cycles
* Run some test cases to get their output also when full init fails
* Remove high timeouts from the times when GHA couldn't use KVM
* Enable logging durations for future optimizations
(cherry picked from commit 4a1d2b75b94483efc749e88aab95fa639aa2bb0a)
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.
(cherry picked from commit 6c4f32a8c0cb48ba203d48068a773a5b3895ccfc)
Update to latest version that fixes start order in haos-agent.service. Without
that, OS Agent reports incorrect swappiness after boot.
(cherry picked from commit 36d905720a12742b4d46f3a0a6b0ca4628ed3f1d)
As discussed in #3885, now that fixed Supervisor is in stable, we can test that
no AppArmor denied events are logged during CI tests.
(cherry picked from commit 610ced0162aa1c76915a0cc2adf16d93c858358e)
Add missing patch and update for latest runc version to fix losing device
permissions when new devices are added in runtime.
* buildroot b079a02a9a...3914f8cad5 (2):
> package/runc: add patch for extended default allowed devices in v1.2.4
> package/runc: add missing patch to fix device permissions update
Fixes#3915
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).
* Add test checking journal logs for dependency cycles
* Run some test cases to get their output also when full init fails
* Remove high timeouts from the times when GHA couldn't use KVM
* Enable logging durations for future optimizations
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.
Cherry-pick bumps up to v5.79 and sync other changes and fixes with latest
upstream state.
* buildroot b4df362187...7d5c3b5e70 (10):
> package/bluez5_utils: tidy up the init script
> package/bluez5_utils: install datafiles with correct permissions
> package/bluez5_utils: fix dbusconfdir
> package/bluez5_utils{, -headers}: bump version to 5.79
> package/bluez5_utils: enable asha/bass when building audio plugins
> package/{bluez5_utils, bluez5_utils-headers}: bump to version 5.78
> bluez5_utils: disable asha profile
> package/{bluez5_utils, bluez5_utils-headers}: bump to version 5.77
> package/bluez5_utils: disable datafiles
> package/bluez5_utils: fix sixaxis build without tools
Update Docker to latest version and containerd to latest version from the 1.7
line. Runc updated to v1.2.5 with rebased patchset from the outstanding PR.
* buildroot 257ddc70ce...b4df362187 (4):
> package/runc: bump version to v1.2.5
> package/docker-cli: bump version to v28.0.1
> package/docker-engine: bump version to v28.0.1
> package/containerd: bump version to v1.7.25
Mainly the amdgpu updates cause an increase of generic-x86-64 image size by
~12MB but there's still enough of space in the rootfs after recent cleanup.
* buildroot c5a1cbcf73...257ddc70ce (9):
> package/linux-firmware: bump Intel BZ firmware version to 92
> package/linux-firmware: bump version to 20250211
> package/linux-firmware: bump version to 20241210
> package/linux-firmware: fix build failures to due RTL8723 file changes
> package/linux-firmware: bump version to 20240909
> package/linux-firmware: bump to version 20240709
> package/linux-firmware: improve help text for Realtek 88xx Bluetooth firmware
> package/linux-firmware: install all rtl88 Bluetooth binary blobs
> package/linux-firmware: RTL_88XX_BT: install all firmware
Disable downstream option for linux-firmware compression. With #3877 it's not
needed for x86 anymore and other boards don't need it. Eventually the higher
EROFS compression for firmwares and modules can be enabled for other targets as
well.
Patch added in #3843 is not necessary anymore, as the missing reset names have
been added to DTS includes of the 6.12.y branch as patch
6c9cd0a70ccea8a505471062a85de5626ad07cec (released in v6.12.14).
When RPi is booted in the tryboot state and the set-state operation is called
for the second time, the tryboot files don't exists anymore and the handler
exits with an error code, printing an error in the Supervisor logs. Fix
handling of this case and add few more checks to make the handler a bit more
robust/traceable.
As we don't have the info utility in HAOS, it's worthless to preserve info
pages. While there are currently some files in /share/info (coming from GRUB2
tools install), /usr/share/info was added pre-emptively.
Because the OTA hooks interact with GRUB environment using grub-editenv, we
have BR2_TARGET_GRUB2_INSTALL_TOOLS enabled. However, that brings massive bloat
of files that are never used in HAOS, as it also installs many other binaries,
GRUB modules and translations.
As it's not possible to configure what gets installed in grub2 package, remove
the undesired files in the post-build function. This brings savings of ~8.5MB
of space in the root partition.
Use auditd so logs from AppArmor and other audit events are processed by that
instead of printed to the Systemd journal. This will reduce the log spam from
BPF usually present in host logs and still preserve the audit logs for
debugging.
The default configs seems to be sane for our purpose, rotating up to 5 files of
8MiB each. The difference is that /var/log/audit will be now on tmpfs but given
how AppArmor is used on typical HA setup, we don't need to preserve the logs
over reboots.
Removal of the e2scrub binary is not needed anymore, as it's not installed and
only BR2_PACKAGE_E2FSPROGS_E2IMAGE is enabled. Moreover, it's been probably
wrong since the very beginning, as the TARGET_DIR prefix was missing, possibly
leading to removal of the binary from the host/builder.
Allow configuration of the swap size via /etc/default/haos-swapfile file. By
setting the SWAPSIZE variable in this file, swapfile get recreated on the next
reboot to the defined size. Size can be either in bytes or with optional units
(B/K/M/G, accepting some variations but always interpreted as power of 10). The
size is then rounded to 4k block size. If no override is defined or the value
can't be parsed, it falls back to previously used 33% of system RAM.
Fixes#968
* Refresh fileenv patch for U-Boot 2025.01
* Update Tinker to U-Boot 2025.01
Needs minor patch adjustment, also fixed patch numbering.
* Update ODROID-N2 to U-Boot 2025.01, move eMMC patch
Move the patch for eMMC so it's applied only for N2 specifically and update it
for 2025.01.
* Update ODROID-C/XU to U-Boot 2025.01
No changes in patches necessary after moving the N2 patch.
* Update RPi boards to U-Boot 2025.01
Changes needed in bcmstb PCIe driver due to upstream refactoring, rest only
refreshed. All patches now target the same version, so we can drop one of the
series.
* Update VIM3 to U-Boot 2025.01
No patches here, just version bump.
* Update Green to U-Boot 2025.01
Updated and refreshed patches, added a patch to disable OF_UPSTREAM which is
now needed.
* Update ODROID-M1 to U-Boot 2025.01
Drop patch that has been mostly merged upstream. The change is that HS400 would
stay enabled but let's get back to what upstream does.
* Update ODROID-M1 to U-Boot 2025.01
Drop all patches as M1S support should be now merged to U-Boot and DTS taken
from upstream.
* Disable DFU and mkeficapsule to fix build
mkeficapsule requires gnutls to be built first but it's not among dependencies.
Since we don't need the tool, we can disable it.
DFU is also not used on HAOS and it implies EFI_LOADER that we already disable.
Moreover, that also sets SET_DFU_ALT_INFO and leads to linker failure on some
platforms where it's not implemented.
* fixup! Update Green to U-Boot 2025.01
There were more changes needed in the Green config to use correct memory layout
due to upstream changes, otherwise we'll have malloc failures in U-Boot proper.
* Move N2 eMMC patch to more generic patches-meson
To stay on the safe side, move the eMMC hack to more generic folder that's used
for all targets using the meson_gx eMMC driver (i.e. C2, C4 and N2). This is
still better than keeping it in hardkernel/patches which is applied only to
some hardkernel boards (like it was before bump to U-Boot 20205.01).
Instead of using per-file ZSTD compression, compress firmware (and newly also
kernel modules) using LZMA within EROFS image. LZMA was picked because ZSTD
support in EROFS is still experimental and due to some limitations in the
implementation, the compression takes significantly more time.
This change gives us more control over compression of the files and with the
proposed settings, saves a bit of the space (~10 MiB) in the resulting image.
In theory, even higher savings could be achieved through compressing other
runtime binaries, but this would need to be thoroughly tested whether it
doesn't have any detrimental effects. For firmware and modules, the overhead
should be minimal, as they are usually touched only once per boot and are
rather small before decompression.
* buildroot 74994c4f32...92fab35fed (6):
> fs/erofs: add custom compression option with optional compress-hints file
> package/erofs-utils: bump to version 1.8.5
> package/erofs-utils: bump to version 1.8.3
> package/erofs-utils: bump to version 1.8.2
> package/erofs-utils: bump to version 1.8.1
> package/erofs-utils: add libdeflate and zlib optional dependencies
* buildroot 014c3fad50...74994c4f32 (2):
> package/linux-firmware: update Intel iwlwifi firmware versions for Linux 6.12
> package/linux-firmware: bump version to 20240513
* RaspberryPi: Update kernel to 6.6.74 - stable_20250127
* Bump buildroot to update rpi-firmware
* buildroot 71cba6c610...014c3fad50 (1):
> package/rpi-firmware: bump to version 1.20250127 for kernel 6.6.74
* Update patch for disabling CQE on CM5
The bool has been changed to a cell, adding the possibility to change the value
via sd_cqe dt_param both on CM5 and Pi5. Set it to disabled by default on CM5.
Because of refactoring/code quality improvements in upstream, IPv6 reachability
patch no longer applied on 6.12 kernel. We added two versions of the patch to
address this initially, however, this requires updating of the patch directory
name on every kernel bump. Backport the patch causing collision instead to RPi
kernel, so we can carry only one version of the patch.
This also requires swapping of the patching order - now we first apply
board-specific patches, then the global ones. Unless there are collisions,
these operations should be idempontent, so at this point it shouldn't have any
side-effects.
* Remove USB stack patches working around obsoleted Z-Wave devices issues
In #3224 we've introduced a patch reverting some changes in the USB stack that
was supposed to work around issues with some USB devices. Later discussions
revealed these devices are obsoleted by the manufacturer and there is no
official way of fixing those in newer Linux kernels. However, carrying the
patches makes us diverge from upstream and can eventually trigger other
problems not present upstream we'll have to handle.
Drop these patches now to be part of the upcoming OS 15 release, rather than
needing to drop them later in any of the patch revisions later.
* Also remove the patch from board/raspberrypi patches
* Upgrade Rockchip platforms to Linux 6.12
Upgrade all Rockchip boards to latest 6.12. Patches for M1S can be dropped, its
DTS has been merged. Same goes for the Rockchip TRNG, it only had to be enabled
in the Green DTS. Patch for broken combphy has been updated for 6.12.y.
* Remove deprecated and nonsense symbols from Rockchip defconfig
Many symbols have been removed between 6.6 and 6.12. Most of them have no use
in Rockchip defconfig, or should be set by other kernel fragments anyway.
Remove all of them, with the exception of USB_ONBOARD_HUB (which was renamed to
USB_ONBOARD_DEV) and FSCACHE (which was changed from tristate to bool).
* Update generic-aarch64 to Linux 6.12
* Update Amlogic-based ODROID boards to Linux 6.12
Removed couple of deprecated/unrelated kernel options.
* Update VIM3 to Linux 6.12
Cleaned up symbols unrelated/deprecated in 6.12 from defconfig.
* Update ODROID-XU4 to Linux 6.12
The usual defconfigs suspects had to been removed and the regulator patch for
ethernet needed a minor update after refactoring in upstream.
* Update Tinker to Linux 6.12
Needed defconfig cleanup for 6.12, otherwise no changes.
* Update x86 and OVA to latest 6.12 release
This way the extra patches directory can be removed too.
* Remove 6.6.73 patches
* Refresh all linux patch series against 6.12.11 sources
* Reenable HW RNG on M1S to speed up boot
The TRNG on RK3566 supposedly [1] has low quality, that's why it's disabled in
upstream for this SoC. We had it enabled in the past and without it, the boot
is delayed by quite a lot. Enable it again for now and investigate the RNG
issues later.
[1] https://patchew.org/linux/cover.1722355365.git.daniel@makrotopia.org/
* Also remove CACHEFILES module from Rockchip config
It was only enabled for Rockchip and Tinker, and to my knowledge there is no
cachefiles daemon or anything other in the userspace that's using it.
* Remove unused 6.6.y fragments
Since we only have 6.6.y for Raspberry Pi now, it doesn't need the Rockchip and
wireless PCI fragments.
Revert the patch changing phy reset behavior, requiring also changes in the
device tree that are missing in the stable backport. The issue was reported to
the regressions mailing list and hopefully future patch release should contain
a proper fix.
The patch is added to the patches-rockchip directory, potentially affecting
Green as well, although the broken peripherals are not used there.
Fixes#3837, fixes#3841
Probably since home-assistant/supervisor#5276 introduced in Supervisor
2024.9.0, RAUC bootloader handler for tryboot can set the tryboot flag also
when the tryboot file is not present, causing the Pi to become stuck in
bootloader, trying to load the tryboot file.
This happens when the device is already in the tryboot state, in that case the
tryboot files and flag are created by set-primary and in turn the files are
removed in set-state, while the flag is persisted, causing the bootloader to
attempt loading non-existing file.
To avoid unnecessary juggling with tryboot/config files, only create them and
set the flag if the boot slot is different than the current one. Also, make
sure that the flag is reboot parameter is cleared when the tryboot files are
removed by the handler.
Fixes#3740
* Linux: Update kernel to 6.12.6
* Linux 6.12
* https://github.com/home-assistant/operating-system/pull/3767#discussion_r1899169881
* https://github.com/home-assistant/operating-system/pull/3767#discussion_r1899170543
* Add patch descriptions, kernel ver conditionals
Signed-off-by: Nick Venenga <nick@venenga.com>
* Remove extra zram compression algos
* Undo fragment files config change
...for platforms that didn't receive kernel updates
* Sort Dockerfile apt packages
* Add Upstream refs to patches
* Re-enable TC
* Restore v6.6.y kernel fragments
* Update buildroot to rebased branch
* Apply 6.12 migration only to generic-x86-64
* package/eq3_char_loop: port patch from RaspberryMatic by @jens-maus
* package/generic_raw_uart: port patch from RaspberryMatic by @jens-maus
* Restore buildroot-external/board/pc/patches/linux
It's used in ova and generic-aarch64 defconfigs. Keep the path removed from
generic-x86-64 defconfig.
* Split linux patches to be version-specific
The IPv6 reachability patch needs different context on 6.6.y and 6.12.y -
introduce version-specific linux directories. To avoid the need for extra
directory for version used in RPi, copy those patches to its patches directory.
* Replace removed Intel Skylake audio driver with Intel AVS
The Skylake driver was removed and should be now replaced either by Intel HD
Audio or Intel AVS. Remove the old options and enable AVS.
SND_SOC_INTEL_SKYLAKE=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:63)
SND_SOC_INTEL_SKL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:64)
SND_SOC_INTEL_APL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:65)
SND_SOC_INTEL_KBL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:66)
SND_SOC_INTEL_GLK=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:67)
SND_SOC_INTEL_CNL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:68)
SND_SOC_INTEL_CFL=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:69)
SND_SOC_INTEL_CML_H=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:70)
SND_SOC_INTEL_CML_LP=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:71)
SND_SOC_INTEL_SKYLAKE_FAMILY=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:72)
SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=y not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:73)
SND_SOC_INTEL_SKYLAKE_COMMON=m not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:74)
-> a882f4d750
SND_SOC_INTEL_SST=m requested, actual = n (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:58)
-> 970d299b0a
* Remove I2C_COMPAT option
I2C_COMPAT=y not found (defined in /build/buildroot-external/board/pc/generic-x86-64/kernel.config:163)
-> 7e722083fc
* Correctly disable module compression after Kconfig change
The Kconfig structure was changed, there's now a top-level bool:
c7ff693fa2
---------
Signed-off-by: Nick Venenga <nick@venenga.com>
Co-authored-by: Jan Čermák <sairon@sairon.cz>
On Kria KD240 slg7xl45106 device is handling reset for USB hub which is
providing access to SD card (USB/SD converter). Access to this device is
done via i2c which needs to be also enabled in the kernel as built-in
driver not as module when rootfs is mounted.
Also change ZYNQ_GPIO to be built-in driver because i2c is using gpio for
bus recovery that's why it should be also enabled to probe i2c driver
properly.
v6.6 kernel doesn't have support for usb5744 driver that's why disable it
but add TODO to enable it once v6.12 upgrade is done.
Build of pam_lastlog.so was disabled by updating to v1.5.3 [1] yet the line
wasn't removed from the login modules. In upstream this was resolved by adding
a config option for turning the lastlog module and dynamic disabling of the
line including it. These changes neither a fix removing the config line were
not applied to 2024.02, so cherry-pick them here to fix the issue.
* buildroot ff563b383d...3784884466 (2):
> package/linux-pam: adjust login pam file for lastlog
> package/linux-pam: add menuconfig option to build pam_lastlog.so
Fixes#3789
[1] https://github.com/linux-pam/linux-pam/releases/tag/v1.5.3
(cherry picked from commit af7b36e1007981ccd04c75d60ee24e487d836a04)
* Enable USB-SD convertor on AMD/Xilinx Kria KD240 platform
Kria KD240 board is using SD card but SD is connected via onboard USB HUB.
USB controller is DWC3 with Xilinx glue logic. Both of these options are
enabled but board is using slg7xl45106 for driving usb-hub reset (PCA9570
driver) and USB3.0 requires initialization via PHY_XILINX_ZYNQMP driver.
All options should be enabled (=y) and can't be kernel modules because
provide access to rootfs.
* Add a note for config symbol change in 6.12
Changed in mainline commit 31e7f6c015d9eb35e77ae9868801c53ab0ff19ac
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
(cherry picked from commit 64ee53579b32fae80f02d15b88d1ef4016abc2c0)
* buildroot 00e8f09356...ff563b383d (1):
> Merge tag '2024.02.10' into 2024.02.x-haos
(cherry picked from commit a7cdebf03217c7d6b44ff64ab2aa93a7a7fc0237)
I have only tested that it fails for unreleased 6.6.72 kernel but haven't
tested the happy path and missed that it also failed because the types were
different. Stupid me.
* Move rauc.db to boot partition
The RAUC metadata file contains information that is tightly related to the
system and kernel partitions. With the possibility to migrate data disk, the
rauc.db can contain bogus information when moved to a different system. Removal
of the file on "device wipe" is also not desirable, because the information
about slot status is lost.
Relocate the rauc.db to the boot partition after a system upgrade (as this
can't be handled by RAUC hooks, because it needs to be executed after all slots
and metadata is written) and adjust the script for recreating it. The downside
is that its content in /mnt/data would be recreated if the boot slot is changed
or system downgraded but this should be handled quite gracefully.
Also remove the raucdb-first-boot service which is no longer necessary
with the file not present in the data partition.
* Fix shellcheck and mount path
Build of pam_lastlog.so was disabled by updating to v1.5.3 [1] yet the line
wasn't removed from the login modules. In upstream this was resolved by adding
a config option for turning the lastlog module and dynamic disabling of the
line including it. These changes neither a fix removing the config line were
not applied to 2024.02, so cherry-pick them here to fix the issue.
* buildroot ff563b383d...3784884466 (2):
> package/linux-pam: adjust login pam file for lastlog
> package/linux-pam: add menuconfig option to build pam_lastlog.so
Fixes#3789
[1] https://github.com/linux-pam/linux-pam/releases/tag/v1.5.3
Add test that the kernel isn't tainted at the end of the basic and supervisor
test suites, allowing us to catch e.g. kernel warnings that may left unnoticed
if dmesg isn't checked. There is no other source of tainting, so the value
should be always zero.
* Enable USB-SD convertor on AMD/Xilinx Kria KD240 platform
Kria KD240 board is using SD card but SD is connected via onboard USB HUB.
USB controller is DWC3 with Xilinx glue logic. Both of these options are
enabled but board is using slg7xl45106 for driving usb-hub reset (PCA9570
driver) and USB3.0 requires initialization via PHY_XILINX_ZYNQMP driver.
All options should be enabled (=y) and can't be kernel modules because
provide access to rootfs.
* Add a note for config symbol change in 6.12
Changed in mainline commit 31e7f6c015d9eb35e77ae9868801c53ab0ff19ac
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
Similarly to #3803, artifact index update fails because the R2 doesn't
like the new awscli. The regression apparently comes from 1.37.0 as
well, so pin to version older than that.
The /etc/usb_modeswitch.d is present and empty but it can't be written to allow
user modification. Bind-mount it like other /etc folders to make it possible to
adjust usb_modeswitch config.
Fixes#3785
Zynq GPIO driver is used on AMD/Xilinx Kria platform for ETH phy reset.
Macb and PHY drivers are already enabled.
1 wire IP can be used for reading sensors via PMOD connector.
Similarly to #3705, enabled CQE triggers I/O freezes usually on the first boot
when the swapfile is being created. While we disabled it for Yellow, with #3782
the issue started to appear on generic CM5 targets with the rpi5-64 image.
In the meantime it was discovered that there seems to be some relation with the
ext4lazyinit task, which happens as a result of data partition resize, yet it's
still unclear if the pattern of the access triggered by the concurrent FS
initialization is somehow responsible, or if another factor comes in play.
Disabling CQE yet makes the issue go away and serves as an acceptable
workaround.
RPi 5 images container only device tree for Pi 5 Model B. Add the other
remaining BCM2712 device trees to enable running on CM5 and other variants
supported upstream.
Fixes#3766
With "cgroup: Use kernel command line to disable memory cgroup" merged to RPi
kernel as 86099de [1], the device tree now contains "cgroup_disable=memory"
parameter. The parameters are parsed in the order defined in the cmdline and
with the previous order, the memory CG ends up disabled. Switching the order
fixes that and makes the order similar to what we get with standard bootloader
and parameters in cmdline.txt only.
The possible downside is that it won't be possible to override parameters from
hardcoded bootargs_hassos using cmdline.txt anymore, however, it's unlikely any
of these parameters will need to be adjusted by users.
Fixes#3765
[1] 86099deff5
The z3fold allocator was deprecated with the reasoning explained in [1] and
this patch was backported to stable 6.6.y as well. We enable zsmalloc in shared
hassos.config and the enabled option in the Tinker config was probably just
some remnant from the past.
[1] https://lore.kernel.org/linux-mm/20240904233343.933462-1-yosryahmed@google.com/
The TCPMSS target module for iptables was enabled in some kernel defconfigs but
not for all targets. It is used e.g. in default config of @bigmoby's WireGuard
Client add-on. Enable it globally in the HAOS kernel config to make sure it's
always present.
Fixes#3730
If data disk is adopted on Yellow using the mechanism added in #3686, it
contains RAUC version information that is very likely invalid. In such case,
remove the file on first boot and have it recreated by the raucdb-update
service.
Hailo modules are usable also in other generic targets, so enable them also on
generic x86 and ARM targets. Runtime tested only on x86-64 (Beelink with Intel
N100).
The PCIe card from the RPi AI Kit (and probably other M.2 cards using the
Hailo-8 chip) can be used on Yellow - the driver initializes correctly and
creates a /dev/hailo0 device on Yellow both with CM4 and CM5.
* Add HA Yellow image to RPi Imager index update action
Update the action to also bump HA Yellow image added in
home-assistant/version#402.
* Sync image name with the current JSON PR
Instead of using in-tree module on RPi 5, build it as a module from the
original sources. This will give us better control over the version used and
will also allow us for easier way to add the module to other platforms.
This also makes 017d172 unnecessary anymore.
* buildroot c65b0306bb...b2077df873 (1):
> package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e
Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API
which uses the DUMP_OBSS feature for channel selection. If it's not preset, it
results in drivers reporting errors, e.g.:
brcmf_set_channel: set chanspec 0xd099 fail, reason -52
The RPi OS firmware was updated but the package we use for this firmware
contains an old version that lacks this support. Update to latest version
synced from RPi upstream to fix the issues. The root cause is explained in [1]
by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the
errors go away.
[1] https://github.com/raspberrypi/linux/issues/6049#issuecomment-2485431104Fixes#3367
With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
(cherry picked from commit 9d643edb54d25be404b1cc92b64f1eddf48e6a86)
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
(cherry picked from commit c514d6b4825e4d72a0f3bfac26a5d3a203390e08)
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
(cherry picked from commit 489de0b2fb06aa6477c2c4ad34d4b9440e5a21ae)
With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
(cherry picked from commit d57e50776499f209e013efa0db6cb3c7f46f51c3)
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
(cherry picked from commit b288cd212ae82d78de707009d61265d9d950497c)
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
(cherry picked from commit 98ac7f017089f28d7f231eed1a51533dfa62a475)
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
Add Hailo-8 firmware binary for Rasperry Pi AI accelerators. The version needs
to be determined from the Git history of the kernel sources, as the driver
source code is included in the RPi downstream kernel and the version string
can't be found in the code directly.
Fixes#3663
* Add Makefile variable for Supervisor channel
Allow to set the release channel pre-installed Home Assistant components
like Supervisor and add-on are fetched from. This channel is then also
used at runtime.
* Use choice instead of string variable
* Fix channel in Supervisor updater.json config
* Add newlines
As stated in the docs [1], post-install hook is not executed if the slot
already has an install hook defined. Merge the post-install hook with the
install hook to fix CM5 migration for Yellow.
[1] https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
The timeout of 90s was introduced before it was ensured that the timesync
systemd unit starts after network is online. Now with that, it makes less sense
to wait that long - if network is unreachable at the point the time
synchronization starts, and the server fails to reply on the first sync, the
polling interval is exponentially increased and the benefit of waiting for more
attempts is doubtful.
Since another synchronization attempt is done after network changes its state,
we should rely on that instead of having the 90 seconds interval as a waiting
period for plugging the network cable. Worst case, there are other mechanisms
that should set the time to a reasonably accurate value, making the NTP sync
less importart for most of the cases.
* Move RPi U-Boot patches to version-specific directory
We will need to use different series for 2024.10 which would be used as the
base for CM5 support.
* Remove common.h include from the fileenv cmd
It doesn't seem to be used and common.h has been removed in newer U-Boot.
* Use U-Boot 2024.10 with BCM2712 PCIe patches for Yellow
Use rebased patchset from v2024.01 with the first patch removed. Add patches
needed for PCIe initialization and use rpi_arm64_defconfig as the base config
for both CM4 and CM5.
* Add device tree for CM5 on HA Yellow and adjust config
Add device tree definition based on the CM5 device tree with BCM2712D0 changes
applied, and add nodes required for the on-board peripherals of Yellow.
Currently the difference in serial numbering still requires either changes in
this device tree, or userspace changes to create correct symlinks to make HA
configuration directly compatible with CM4 on Yellow.
* Add config.txt migration for conditional device_tree options
* Fix typos and minor issues found by CodeRabbit
* RaspberryPi: Update kernel to 6.6.51 - stable_20241008
* Update rpi-firmware to version for kernel 6.6.51
* buildroot 2ffac68a74...19027bc796 (1):
> package/rpi-firmware: bump to version 1.20241008 for kernel 6.6.51
Guest agent doesn't start because if HyperV Enlightenments are enabled, the
virtualization gets detected incorrectly. Backport Systemd patch that fixes the
detection, allowing the guest-agent service to meet its dependencies.
This patch should be no longer needed after update of Systemd to v256, or in
case the patch gets eventually backported to the v254 stable branch.
Fixes#3565
* Relocate HAOS Systemd drop-ins to /usr/lib/systemd
With some exceptions, Systemd drop-ins overriding default unit configuration
have been placed to `/etc/systemd/system`. This is meant for user overrides of
those, or per `man 5 systemd.unit` for "system unites created by the
administrator". Relocate all of these to `/usr/lib/systemd` which should be
used as path for units "installed by the distribution package manager" which is
closer to what we're trying to achieve.
This will make it easier to detect changes to unit files once we enable the
possibility to edit the content of /etc.
* Patch systemd-timesyncd.service instead of replacing it fully
If the system fails to boot, some kernel messages may not be shown before the
system fully boots. Enable the debug option for rescue shell options to have an
easy way to see those without modifying GRUB options. This will increase log
verbosity and turn on debug logging for Systemd as well [1].
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.html#debug
Bump labgrid to latest release. None of the changes require adjustments in the
tests. Remove pytest from requirements.txt, it's not needed anymore, so let pip
to resolve the correct (latest) version from labgrid's dependencies. With these
new dependencies, previous DeprecationWarnings on Python 3.12 are gone now.
* Update Docker to v27.2.0
Update Docker and containerd to latest supported version.
* buildroot a2c10a16a0...c68e03d96b (3):
> package/containerd: bump version to v1.7.21
> package/docker-cli: bump version to v27.2.0
> package/docker-engine: bump version to v27.2.0
* package/hassio: update DinD container to v27.2
If an attempt to access R2 artifacts is made before the files exist, the 404
reply gets cached and it's not possible to access the file after it's been
created without purging the cache, essentially doing a cache poisoning for
future build artifacts. To avoid it, list all files that have been created by
the build and call the purge cache API.
As there's a limit for number of files that can be purged in a single API call
[1], the GNU split utility is used to split intermediary list of files to
chunks of 30 URLs, which is then converted to a JSON array and passed to the
curl command.
[1] https://developers.cloudflare.com/api/operations/zone-purge#purge-cached-content-by-url
HP t520 have been reported to have the same issues as Atom boards with bad UEFI
firmware that doesn't work well with the new EFI loader used since GRUB 2.12.
Apply the patch to use legacy loader for its CPU ID as well.
Fixes#3557
Fix AX210 firmware files, this time for real. In #3549 we still had only
ucode and pnvm files for AX211, AX210 was still missing the pnvm file,
because its ucode was provided through IWLWIFI_22000 without appropriate
pnvm file. Both AX210 and AX211 firmwares are now installed with
IWLWIFI_6E which includes both pnvm and ucode files.
Also some firmwares which are not used by the current kernel can be
removed, because the kernel always only loads the most recent one.
* buildroot 01188d9c38...a2c10a16a0 (2):
> Revert "package/linux-firmware: exclude some files from compression"
> package/linux-firmware: fix AX210 support, stick to latest supported ucode API, reorganize the split
Fixes#3477
Since updating to Buildroot 2024.02, the iwlwifi loads a different version of
firmware for Intel AX cards (reported on AX210) which also needs the pnvm file.
However, unlike firmwares, the load method is different and the driver can't
load a compressed file. Disable compression for all .pnvm files to fix this.
* buildroot baa16784d2...55be56d521 (1):
> package/linux-firmware: exclude some files from compression
Fixes#3477
(cherry picked from commit d3a43a4ca4fcdcb4b0ba9a6017c3340773011166)
Since updating to Buildroot 2024.02, the iwlwifi loads a different version of
firmware for Intel AX cards (reported on AX210) which also needs the pnvm file.
However, unlike firmwares, the load method is different and the driver can't
load a compressed file. Disable compression for all .pnvm files to fix this.
* buildroot baa16784d2...55be56d521 (1):
> package/linux-firmware: exclude some files from compression
Fixes#3477
With #3523 as inspiration, it might be useful to wait for buttons to be
released, e.g. in case when they become stuck. Also indicate the button
operation (wipe, boot files removal, UMS) has been handled by turning on the
yellow LED.
* Improve LED naming in U-Boot DTS
Port Stefan's patch from Linux patchset to U-Boot.
* Implement device wipe using the hardware button on Green
Unlike Yellow, Green doesn't have a way to easily wipe the device, e.g. if the
user forgets the password - in that case the only option is to use a microSD
card and reflash the system. Fortunately, Green has a hardware button wired to
the PMIC chip which exposes the button state in one of the registers. Read this
value in U-Boot and decide if cmdline flag for device wipe should be set - same
as we do on Yellow.
Also enable LED driver and command in U-Boot. In the current implementation, if
the button is held for ~5 seconds when plugging in the device (this time
includes DDR training, SPL, etc.), the yellow LED turns solid to indicate wipe
is about the start. When the Linux kernel starts, the kernel LED driver takes
over and starts blinking in heartbeat pattern. Because it takes a while to load
the kernel, the LED stays solid for 2-3 seconds, which should be enough to
recognize it was acknowledged.
* Wait for button to be released before wiping
Enable NTFS and exFAT drivers, as they're not in defconfigs of all platforms and may be useful when mounting removable drives.
Fixes#2723
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
With default console on HDMI (tty0), we lost the console on the serial port. It
may be useful for debugging, let's enable it for new installs with the same
speed as bootloader (to avoid the need for baud rate switching).
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in
the original patch series we took inspiration from that HS200 works more
reliably, so enable it in Green's defconfig by amending the patch.
(cherry picked from commit 0452965fb04a86712fa1b6f58f9788abb1a8c937)
Apply the same patch we applied in #3412 for Green. At that time I thought the
patch was already applied upstream for M1 and haven't checked, but it turns out
it wasn't true. Apply it here before we get U-Boot with that patch series [1]
included.
[1] https://patchwork.ozlabs.org/project/uboot/cover/20240204205312.2342868-1-jonas@kwiboo.se/
(cherry picked from commit d6fa83a0d38d8716a283e8c0df5f5ef6bc622c9d)
While mksquashfs uses this value by default, Genimage's default is 4K. This is
far too low value and results in slower kernel load, especially on embedded
boards with a flash drive. Explicitly set it to 128K to generate same images as
in pre-genimage builds.
(cherry picked from commit edba18f6c41539f18e53f285b2c6cbecd509eab9)
We previously reverted the bump because we were unsure where the eMMC issues
are coming from. Now we know some of them were caused by incompatible eMMCs
then never worked from the beggining, and attempt to fix them (by changing the
frequency) caused some other side effects. Bump U-Boot back to the version used
generally and continue from there.
(cherry picked from commit 50a0062ee64972a7387f8eae549becea38018722)
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in
the original patch series we took inspiration from that HS200 works more
reliably, so enable it in Green's defconfig by amending the patch.
While mksquashfs uses this value by default, Genimage's default is 4K. This is
far too low value and results in slower kernel load, especially on embedded
boards with a flash drive. Explicitly set it to 128K to generate same images as
in pre-genimage builds.
We previously reverted the bump because we were unsure where the eMMC issues
are coming from. Now we know some of them were caused by incompatible eMMCs
then never worked from the beggining, and attempt to fix them (by changing the
frequency) caused some other side effects. Bump U-Boot back to the version used
generally and continue from there.
* add Documentation category
* add Dependencies (to easily filter them out if not needed in changelog)
* adjust the order a bit to have user-facing changes first
* Test landing page is reachable without internet connection
Add test that checks user is able to access the landing page even when HAOS has
no internet connection. We still need some sort of outgoing connectivity, so
outgoing connection attempts don't end up with "network is unreachable". To
simulate this, restricted network is created for the QEMU instance used in the
test, and when everything is started, unresponsive default gateway is added.
This intents to test regression that was fixed by
home-assistant/supervisor#5204, Supervisor 2024.7.0+ is thus needed for this
test to pass.
* Bump requirements for tests
* Use GRUB2 legacy loader only on some Intel Atom boards specifically
Previous revert of GRUB2 change that introduced usage of the generic EFI loader
for all x86 boards in #3324 caused regressions, the one confirmed is #3348.
This commit adds a specific patch that identifies the broken platforms based
on SMBIOS data gathered in #3305 and falls back to the legacy loader there.
Tested on Intel D525MW (falls back) and QEMU (no fallback).
* Enable GRUB's smbios module
Having smbios command in GRUB can help in future debugging, e.g. to add more
CPUs that should use the linux loader fallback.
Genimage sets the first usable LBA to the offset of the first partition. While
it shouldn't be an issue in theory, Windows may do some nasty things with the
GPT header afterwards which breaks the Raspberry Pi bootloader, manifesting as
Before purpose of this behavior is clarified in [1], add a downstream patch
that sets the first usable LBA back to 34, which was the value that was used
before migrating to Genimage in #3388. Since changing this value (hopefully)
doesn't have any other consequences, and the images now should be closer to
pre-genimage builds, no more side-effects are expected from this change.
[1] https://www.github.com/pengutronix/genimage/issues/262Fixes#3437
Rockchip config fragment had EROFS compression explicitly disabled. Remove that
option and also remove the EROFS one, as it's already set in common config.
Reduce verbosity from deactivated Docker mounts, triggered by the Docker
healthcheck. These messages do not carry any value for us and logs supplied by
users are often spammed mostly with these. Moreover, they sometimes cause
confusion that something is wrong, see for example #3021.
Unfortunately, it's not possible to use LogFilterPatterns= here, because it's
not applied to these messages, as explicitly said in the docs:
Filtering is based on the unit for which LogFilterPatterns= is defined
meaning log messages coming from systemd(1) about the unit are not taken
into account.
runc 1.2.0 supposedly should fix this, but it's unclear when it would be
available, so let's stick to this solution (reducing verbosity from debug to
notice for all units `run-docker-*.mount`) for the time being.
* Use name.sh functions for paths in genimage
Paths for images generated outside of genimage were not used in genimage
definitions. Use them as the single source of truth.
Images generated by genimage itself (e.g. kernel.img) don't need to use those
functions, so remove the unused ones.
* Use EROFS instead of SquashFS for root FS
* Enabled EROFS in common kernel fragment
* RootFS image switched to EROFS with options to get decent compression
* rootfstype removed from kernel command line
* Get size of correct FS image in GH build summary
While not as bad as in 87a6c84, because the grubenv already exists in the
image, RAUC still complains about missing ORDER on the very first boot on
aarch64. Populate the environment in the same way as we do for other GRUB
platforms.
With upgrade path enforced in standard HAOS upgrade procedure, we don't need to
keep some old code anymore. This means that upgrade from some very old HAOS
version (pre-8.0) to HAOS 13+ will fail in the install-check hook but this is
rather desirable.
RAUC currently doesn't know the version of the booted slot when booted for the
first time or after wiping the data partition. As a result `ha os info` is
missing this information too.
As there's no built-in mechanism for generating these data by RAUC itself, add
a oneshot service that checks if the boot slot information is contained in the
rauc.db and if not, then generate it.
RAUC seems to cope quite well even with bogus data contained in rauc.db but in
any case, a test has been added to check that everything works as expected.
On the very first boot, grubenv doesn't exist and loading and saving it
silently fails. However, it is later created by the hassos-persists script and
the missing information are added by grub.cfg on the next boot. As the
consequence, when RAUC tries to get information from grubenv on the first boot,
ORDER variable is missing and the slot is reported as bad.
Fixes#3376
We still face occasional build errors when fetching from the Docker registry
fails and is not retried with the Skopeo's built-in retry mechanism that was
enabled in #1866. This happens on some network failures, or when premature EOF
is returned when fetching the HTTP data. Seems we're not the only ones having
such issues [1].
To workaround this, add a generic retry shell function that simply retries when
the command ends with a non-zero status, no matter what was the actual cause of
the error.
[1] https://www.github.com/containers/common/issues/654
Very often we have to ask for further details about the hardware that HAOS is
running on. Add a required field that asks for these details - in the end it
should't complicate the form a lot and might result in faster turnaround of
resolving the issues.
Also adjust the question about the upgrade and swap the order (people often
don't care and keep the pre-selected value).
When Green starts, there is an error indicating the MMC write failed when
saving the bootstate:
storing env...
MMC write: dev # 0, block # 1214464, count 64 ... mmc write failed 0 blocks written: ERROR
This results in the boot count not being updated properly if the boot fails.
Seems to be a known issue for this platform, disabling the DDR52 mode (which is
the same what upstream does for other RK356x boards [1]) fixes the issues and
the bootstate is updated correctly.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20240204205312.2342868-2-jonas@kwiboo.se/
As we don't have proper solution for #3319 and #3351 yet, revert to
previous U-Boot which was proven working. This is intended as a
workaround but as there's nothing in the latest U-Boot that will be
really missed on N2, we can stay on the older version for the time
being.
This also means reverting the "40 MHz hack" back to the 24 MHz one.
Since this patch only applies to N2 (meson gx), it can stay along the
common hardkernel uboot patches.
The compression is necessary for successful generic-x86-64 build.
* buildroot 770f939463...b9520eedc6 (1):
> package/linux-firmware: fix compression after bad merge
* Bump buildroot to 2024.02.3
* buildroot 691077e577...770f939463 (1):
> Merge tag '2024.02.3' into 2024.02.x-haos
* package/hassio: update dind to version 26.0 used in current buildroot
* Use Genimage for declarative image layout instead of s[fg]disk and dd
* Change partition type to hybrid for M1, M1S and Green
This is what it really is, so just make sure only one "fix" function is
called.
* Change efi BOOT_SYS to gpt
There is no reason to have separate efi and boot sys, since all boards
that use efi also use grub as the loader.
* Change BOOT_SYS to more explanatory PARTITION_TABLE_TYPE
* Add units to DISK_SIZE
* Add forced-primary patch and use it in MBR images
* Avoid disabling SC2155, remove old comments
The preferred console (which is used for printing the systemd boot log)
is the last one specified in the cmdline boot arguments. Make sure it is
always tty0, i.e. the first graphical console.
In some places tty1 was used - change it to tty0 which is commonly used,
and in HAOS points to tty1 anyway.
The only exception is the Yellow, which doesn't have an HDMI port, so
the serial console is used as the preferred one instead.
For ASUS Tinker, use a versioned cmdline.txt file instead of in-place
generating it in the post-build hook.
* RaspberryPi: Update kernel to 6.6.31 - stable_20240529
* Unify Linux patches after RPi update to non-conflicting 6.6.31
* Bump buildroot to update rpi-firmware
* buildroot 9af2384782...691077e577 (1):
> package/rpi-firmware: bump to version 1.20240529 for kernel 6.6.31
* Reintroduce IPv6 reachability probe patch for RPi lost after refactoring
In #3384 we moved the patches around, which results in version-specific
patches not applied for RPi linux-custom build. Copy the missing IPv6
reachability probe patch to the RPi patches directory.
* Only copy IPv6 reachability probe patch to top-level linux patches
Instead of copying the patch to RPi directory and renumbering the
patches, only copy it upper level so it's applied for all linux versions
other than 6.6.31.
* Linux: Update kernel to 6.6.31
* https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.31
* Update patch workarounding Z-Wave.me USB issues
Linux commit 480c3abbba36628dab063b9ca218bb28090e5b46 changed code that
is reverted by the patch. Use a version-specific patch directory again
for upstream Linux patches before RPi kernel is updated to 6.6.31+.
ODROID M1, M1S and Green historically used git repo as the source. Now
that we use the same version for all boards, use always use distribution
tarball for consistency and more efficient caching.
Cherry-picked downstream-only patch lost in Buildroot 2024.02 bump.
* buildroot 34e790c5da...9af2384782 (1):
> package/openvmtools: bump version to 12.3.0
Fixes#3366
RPi 5 config uses BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS which builds
the device tree overlays from the Linux tree when building the kernel.
The overlays directory also contains overlay_map.dtb which is necessary
to correctly map overlays without RPi version suffix to the
platform-specific ones. Without this, some peripherals may not work
correctly on Pi 5 without any obvious error messages in the kernel log
because an incorrect (Pi 4) overlay is used as the default.
Fixes#3321
* buildroot cc0481f40e...0a64bfe8f1 (1):
> Install overlay_map.dtb when using in-tree DT overlays
(cherry picked from commit fce19b784615261ddc0c710cb6866a95e3e817ce)
Enable libkcapi in generic kernel config. The bloat is minimal and the
options are enabled on most distributions. These modules are also needed
for Bluetooth Mesh and adding them fixes compatibility with some HCI USB
adapters.
Fixes#3322
(cherry picked from commit 67315f86d49ae117766491c366c68845ffa68548)
RPi 5 config uses BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS which builds
the device tree overlays from the Linux tree when building the kernel.
The overlays directory also contains overlay_map.dtb which is necessary
to correctly map overlays without RPi version suffix to the
platform-specific ones. Without this, some peripherals may not work
correctly on Pi 5 without any obvious error messages in the kernel log
because an incorrect (Pi 4) overlay is used as the default.
Fixes#3321
* buildroot cc0481f40e...0a64bfe8f1 (1):
> Install overlay_map.dtb when using in-tree DT overlays
Enable libkcapi in generic kernel config. The bloat is minimal and the
options are enabled on most distributions. These modules are also needed
for Bluetooth Mesh and adding them fixes compatibility with some HCI USB
adapters.
Fixes#3322
This fixes "Warning: your password will expire in 0 days." message
shown on tty login since Buildroot bump in HAOS 12.2.
* buildroot 9f5750121a...d29893dd98 (1):
> package/linux-pam: bump to version 1.6.1
GRUB 2.12 release contains a change of the loader [1] used for loading
the kernel on x86_64 platform. This change was identified to cause boot
failure on some old Intel Atom boards with the NM10 chipset, and
possibly some others. Revert this patch before we get a more proper fix
for the issue.
[1] https://git.savannah.gnu.org/cgit/grub.git/commit/?id=cfbfae1aef0694b416aa199291cfef7596cdfc20Fixes#3305
It seems that forcing 24MHz clocks is problematic for newer 32GB
Kingston based eMMC modules on ODROID-N2(+). Use what downstream
U-Boot is using as f_max, which is 40MHz.
Fixes: #3227
With #3281 we hit the maximum length of the quirks parameter. Since
cmdline.txt changes are not applied on OS update, only new installs of
12.2 are affected, effectively disabling all quirks until this patch
lands in future OS release.
Fixes#3308
Make sure all Raspberry Pi devices using the BCM2837 SoC (or the SiP
version RP3A0 of it) are deployed. This especially makes sure that
we only deploy the downstream device trees (named bcm2710*) and deploy
device trees for the CM3 as well as the Zero 2 and Zero 2 W consistently
for 32-bit and 64-bit.
* RaspberryPi: Update kernel to 6.6.20 - 6f16847710cc0502450788b9f12f0a14d3429668
Used version specified in RPi OS release notes [1].
[1] https://downloads.raspberrypi.org/raspios_arm64/release_notes.txt
* Update RPi Buildroot defconfigs for v6.6.y kernel
* Update RPi kernel patches for v6.6.y kernel
* Amended old patches to accomodate for new DTS paths
* Removed 6.6.25 patches -> moved to the common folder
* Added patch to fix Yellow DTS compilation
* Bump buildroot to update rpi-firmware
* buildroot b45d671fe3...9f5750121a (1):
> package/rpi-firmware: bump to version for (untagged) kernel v6.6.20
* Remove kernel v6.1.y config fragments, as they're not needed anymore
* Only run HA CLI interactively if stdout is a terminal
Flags for running HA CLI commands in an interactive shell added in #3238
cause the command to fail if the process is not running in a terminal.
This is needed for example for the fsfreeze hook, otherwise the command
fails, as seen in this trace when the hook is executed:
-----------
+ '[' thaw '=' freeze ]
+ '[' thaw '=' thaw ]
+ echo 'File system thaw requested, thawing Home Assistant'
File system thaw requested, thawing Home Assistant
+ ha backups thaw
the input device is not a TTY
------------
However, for example on Proxmox this message is not logged anywhere and
the hook just fails silently (i.e. it doesn't cause the backup to fail).
Fixes#3251
* Use -i also when not running in a terminal
CP15 barrier instruction emulation only exists on arm64 architecture.
Avoid sysctl writing an error to the journal when the setting doesn't
exist by prepending a dash.
@ -10,8 +10,8 @@ ODROID-M1S can boot HAOS directly from an SD card, as it has higher priority tha
HAOS can be installed directly to the eMMC using a special boot image, to do that:
1. Download [`ODROID-M1S_EMMC2UMS.img`][1]
2. Use balenaEtcher or another tool to flash the UMS utility onto an SD card.
1. Download the _UMS Utility_ image: [`ODROID-M1S_EMMC2UMS.img`][1]. The _UMS Utility_ is a special image that switches ODROID-M1S to USB Mass Storage device.
2. Use balenaEtcher or another tool to flash the _UMS utility_ onto an SD card.
3. Plug-in that SD card to your ODROID-M1S and boot it. Connect your PC to the Micro USB OTG port.
4. The eMMC will show as a drive on your PC and you can directly flash the HAOS image with balenaEther.
@ -4,6 +4,8 @@ Home Assistant Operating System (formerly HassOS) is a Linux based operating sys
Home Assistant Operating System uses Docker as its container engine. By default it deploys the Home Assistant Supervisor as a container. Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers. Home Assistant Operating System is **not** based on a regular Linux distribution like Ubuntu. It is built using [Buildroot](https://buildroot.org/) and it is optimized to run Home Assistant. It targets single board compute (SBC) devices like the Raspberry Pi or ODROID but also supports x86-64 systems with UEFI.
[](https://www.openhomefoundation.org/)
## Features
- Lightweight and memory-efficient
@ -38,7 +40,7 @@ The Home Assistant Operating System documentation can be found on the [Home Assi
### Components
- **Bootloader:**
- [Barebox](https://barebox.org/) for devices that support UEFI
- [GRUB](https://www.gnu.org/software/grub/) for devices that support UEFI
- [U-Boot](https://www.denx.de/wiki/U-Boot) for devices that don't support UEFI
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
