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.
Home Assistant Green uses a SPI NOR flash storage. One can use dd to
write to the SPI NOR flash, but this is problematic if a unit has bad
blocks. Add MTD tools, specifically flashcp, to enable SPI NOR
flashing support.
Update U-Boot board configuration for Home Assistant Green. This moves
all Green specific board configuration into the U-Boot source code
patches. The "sf probe" command now picks up the correct SPI bus by
default.
* Initial commit of Home Assistant Green board support
* Add Home Assistant Green boot files
* HA Green board configs
* board/nabucasa: Unsupport rtc rk808
* Use odroid-m1 as Supervisor machine for now
* Green: linux: pmic: set set PWRON_LP_OFF_TIME 12s
* green: Update U-Boot to 2023.07.02
* green: supports usb boot
* green: uboot-boot.ush use rk3566-ha-green.dtb
* green: spinor supports uboot
* green: use U-Boot provided devtype as boot device type
* green: Fix polarity of power key
The power key is low active. Add patch to avoid accidential long press
being reported to user space.
* green: uboot: eeprom: add CONFIG_ENV_OVERWRITE
* green: uboot: eerprom: add mac read
* green: fix-cpufreq null issue
* green: board aliases ethernet0
* green: uboot mac set ethernet0
* green: uboot add serial-number read
* green: Update kernel 6.1.39
* green: add green to the build matrix
* green: fix 339d13 & 9b9416 can not boot from usb
* green: changfe sd mode, change led default state
* green: uboot add board.c to read eeprom info
* green: enable uboot to read eeprom info
* green: delete boot.scr read eeprom function
* green: change spl loader uboot order:sd-emmc-spi_nor
* green: serialnum change to 18 bytes
* green: Update kernel 6.1.43
* green: use hwrng support from ODROID-M1
* green: Use latest Rockchip BL31/DDR binaries
* change led_act polarity
* green: Disable watchdog
The watchdog on Green seems to not reliably reset the system. For now
disable the driver to avoid systemd making use of it.
* green: Update kernel 6.1.44
* green: Fix Supervisor Machine
Use odroid-m1 for now as Supervisor machine (used to download the
landing page).
* green: emmc use hs200 to increase speed
* green: use green as Supervisor machine
* green: Update kernel 6.1.45
* green: add Green to the kernel documentation
---------
Co-authored-by: Zhangqun Ming <north_sea@qq.com>
Co-authored-by: syan <syan.cham@gmail.com>
Use the official rkbin repository for Rockchip binaries. Use the
binaries from an older git hash which provide the very same binaries
(by hash). This makes sure we use the same DDR version as currently used
by the Hardkernel in their SPI flash bootloader (DDR v1.09).
* Including the RTW8821ce driver module to support Wifi on the KAMRUI AK1 PRO micro PC. It is a low-cost Intel Celeron N5105 that I think should work well for Home Assistant. However, it does not use Intel radios, it needs Realtek drivers.
* also need the firmware for the rtl8821ce
