Make sure the environment can be read and written to SD card as well.
This makes sure that first boot detection works properly too when
booting from SD card.
The patch added in #2434 is not working: IS_ENABLED requires the full
config symbol including CONFIG_ prefix.
Fix the patch to make automatic IPv6 route failover depening on IPv6
reachability probes actually work.
The deployment on dev channel should always be development. The change
came in from the main branch backmerge where the wrong merge strategy
has been used (the merge strategy "ort" along with option "ours" has
been used, instead of the "ours" merge strategy). And since the
deployment was a separate hunk, it resolved to the release branch.
This reverts commit 0ebcdcb9dc8d2471bcacf0049e93f1ad0bf12a37.
We only added verity support in HAOS 10.4. However, we currently have
an issue since HAOS 10.3 where certain Realtek network cards don't work
anymore (see issue #2630). For this systems, it won't be possible to
upgrade, even when using the console.
Only having two HAOS releases creates a rather "narrow" upgrade path
accross all boards. There could be more issues where this proves
problematic.
Currently we don't use any new feature of the verity format. Therefor
let's postpone the move to the new format for a couple of releases
for now.
This reverts commit 0ebcdcb9dc8d2471bcacf0049e93f1ad0bf12a37.
We only added verity support in HAOS 10.4. However, we currently have
an issue since HAOS 10.3 where certain Realtek network cards don't work
anymore (see issue #2630). For this systems, it won't be possible to
upgrade, even when using the console.
Only having two HAOS releases creates a rather "narrow" upgrade path
accross all boards. There could be more issues where this proves
problematic.
Currently we don't use any new feature of the verity format. Therefor
let's postpone the move to the new format for a couple of releases
for now.
With the move to Docker 23 containerd stores its metadata no longer
undernath the Docker data directory but at its default location at
/var/lib/containerd. Previously Docker passed a containerd configuration
toml file which explicitly set the metadata root underneath Docker's
data directory.
On Home Assistant OS, the new location /var/lib/containerd is on a tmpfs
file system. For unknown reasons, it seems that if containerd's root
directory is on a tmpfs this leads to significantly more syscalls and
hence CPU load.
Change the metadata location to be on the data partition again. Since
containerd is treated separately from Docker these days, use a new
root directory under /mnt/data for containerd as well. With this, the
CPU load of containerd is back to normal.
* Bump buildroot
* buildroot a1bdf74b19...f125c3e292 (1):
> package/containerd: add control for additional build tags
* Drop unnecessary containerd changes
Now that the snappshotter and the CRI plug-ins are disabled we don't
need to configure or disable them via configuration anymore. Drop the
unnecessary configs.
Move from the current plain format to the new verity bundle format. This
requires at least HAOS 10.4 to work. The Supervisor will make sure to
update to the latest minor release of the previous major release, so
updating will work in the regular use case.
* Add fsfreeze support for QEMU/KVM/Proxmox installations
Add fsfreeze scripts which calls the new Supervisor API to freeze Home
Assistant Core and add-ons which support the backup freeze scripts
(`backup_pre` and `backup_post`).
This allows to create safe snapshots with databases running.
* Fix lint issues
This enables backlight support on these hosts, which is useful if
running HASS on an old laptop or tablet and you want to (e.g.) conserve
power by controlling the backlight.
Currently `CONFIG_OVERLAY_FS_METACOPY` and
`CONFIG_OVERLAY_FS_REDIRECT_DIR` kernel options are enabled but not
preferred by Docker. The metadata copy feature is disabled by default,
and also not actively used by the overlayfs2 driver (see
2c3d1f7b4b).
So the metadata copy config is not really problematic per se. However,
it enables the redirect_dir feature. And a kernel which has the
redirect_dir feature compiled in also enables it by default. This
actually makes the overlayfs2 driver to fallback to naive diff, which
is, from what I understand, slower than the overlayfs native diff (see
also
49c3a7c4ba).
The Docker daemon is also reporting this on startup:
Not using native diff for overlay2, this may cause degraded performance
for building images: kernel has CONFIG_OVERLAY_FS_REDIRECT_DIR enabled
Currently `CONFIG_OVERLAY_FS_METACOPY` is enabled, and it also enables
`CONFIG_OVERLAY_FS_REDIRECT_DIR`. There was already a previous attempt
to disable the latter (see #2067).
Disable both configs explicitly until Docker is able to use them.
* Adjust Home Assistant versioning to prepare for new release strategy
With OS 11 we'll create rc pre-releases which will get directly pushed
to the beta channel. In contrast, release builds will get directly
pushed to the stable channel.
Similar to Home Assistant Core we'll create bump commits for all stable
and beta releases. This makes sure that the source code matches the
built binaries for all releases.
The development build will get a generated version. To avoid issues
with the new rc builds the dev build version will get injected on source
level now.
* Apply suggestions from code review
* Download latest stable Supervisor after device wipe
Currently we download the latest tag after a device wipe, which gives us
the latest Supervisor (which quite likely can be a development version).
Use the stable version file instead to get the tag to be used to
download the Supervisor.
* Delete potentially corrupted updater info
This essentially reverts #2380, making sure that Home Assistant OS uses
systemd's latest network naming scheme.
We stick to a certain naming scheme to make sure NetworkManager still
applies the network configuration (which is matched by network interface
name by default).
With Supervisor [PR #4476](https://github.com/home-assistant/supervisor/pull/4476)
NetworkManager uses udev path by default. With this we can safely enable
the new interface naming and NetworkManager will still apply the
configuration based on udev path correctly.
Pull in the swapfile creation service haos-swapfile.service when
swap.target is reached. This makes sure the service is started even when
other targets are used (e.g. rescue.target).
* Delete Bluetooth device cache regularly
Delete stale Bluetooth devices from the BlueZ device cache every week.
This makes sure that the overlay partition doesn't run out of inodes
which has happened in real world scenarios where many new Bluetooth
devices are discovered.
BlueZ maintains these files on a best effort base. So removing them
while BlueZ is running should be safe.
An alternative considered was to lower BlueZ GATT caching (e.g. by
using Cache=yes instead of always, to cache only paired devices).
However, this would hurt performance and battery lifetime of Bluetooth
devices due to additional unnecessary GATT attributes reads. This is in
particular true for Bluetooth 5.1 devices which support the Database
Hash charactristic. Caching has also helped reliability with
intermittent connections (see
https://github.com/bluez/bluez/issues/191).
More importantly, besides the GATT attribute cache the same files are
also used to cache the device names as well. This is independent of the
above mentioned GATT cache configuration (see device_store_cached_name
in BlueZ). So disabling the GATT caching alone wouldn't solve the
particular problem we are facing.
See also: https://github.com/home-assistant/supervisor/issues/4490
* Use access timestamp instead of modification timestamp
The modification timestamp gets updated regularly (on each connect) it
seems. However, using access timestamp might be more accurate, as it
seems to preserves slightly more cache files. This additional devices
might be devices we don't regularly connect but are still around (and
therefor we shouldn't reread the GATT attributes regularly).
So deleting cache entries with access time older than 7 days. Which
essentially deletes all the entries of devices which haven't been seen
the last 7 days.
Separate fetching the current release and loading the container image
into separate build steps. This allows to manually later the version
json file for testing.
Enable fully preemptible kernel (low-latency desktop) configuration for
Home Assistant. Home Assistant can be considered as a soft real-time
system, where a lower latency is preferred over throughput.
A few tests using the rt_test development add-on didn't show measurable
improvements, but this could be due to rather synthetic test.
Currently some platform use voluntary preemptible kernel, and some fully
preemptible. So besides improving latency, this also aims to synchronize
the settings across all platforms.
Also make sure that debugging is not enable as it can have high runtime
overhead according to Kconfig.
The BR2_GCC_ENABLE_LTO config used to enable LTO on compiler level. That
config symbol doesn't exist anymore. Instead, LTO is enabled by default
with GCC.
However, there is a new flag named BR2_ENABLE_LTO which enables LTO in
packages. So far it doesn't look like that packages we are using support
the flag, but that might get added in the feature. Opt-in already today.
