* Avoid race condition when fetching containers during build
So far only a single builder was active for each architecture. This
toghether with the naming scheme to include architecture/machine name
made sure that an image could only be fetched or used by a single
builder.
However, since most systems are now aarch64, multiple runners are now
active for a single architecture. This makes it necessary to lock
fetching/coping of container images to avoid race conditions.
Use rtl8812au driver provided by buildroot. This uses a newer verison of
the v5.6.4.2 branch which works with newer kernel and seems to be the
recommended branch.
Note: It seems that our buildroot package currently fails to properly
deploy the 88XXau.ko kernel module. Instead of fixing our version, just
move to the buildroot version.
* Bump to Buildroot 2021.08.1
Move to Buildroot 2021.08.1 using the 2021.08.x-haos branch. Some
patches on the previous branch 2021.02.x-haos have been applied upstream
meanwhile. Others required rather trivial rebasing.
This latest Buildroot release brings new versions of the following
components:
- glibc 2.33
- systemd 249.3
- Networkmanager 1.32.2
- BlueZ 5.60
- Docker 20.10.8
The patch "Fix dhcp client" seems not to be necessary anymore. The
directory /var/lib/dhcp seems not in use when NetworkManager invokes
dhclient. It seems the leases which are typically stored in that
directory are managed inside NetworkManager.
* buildroot 2021.08.1..2021.08.x-haos (6)
> package/rpi-firmware: bump version to 1.20210805
> package/rpi-wifi-firmware: bump version to 883b726
> package/linux-firmware: add rtl8761b/rtl8761bu firmware
> package/docker-proxy: bump version to 64b7a4574d14
> package/rpi-firmware: Allow to deploy multiple firmware files
> network-manager: wpa_supplicant
* Bump Raspberry Pi Bluetooth helper scripts
With the update to Buildroot 2021.08.1, the bthelper fails with an error
org.bluez.Error.Busy when trying to power off the device. Presumably this
is a race condition which surfaced due to a change in Bluez 5.60:
348feb005a
Oct 11 14:32:21 homeassistant systemd[1]: Reached target Bluetooth Support.
...
Oct 11 14:32:21 homeassistant bluetoothd[412]: Bluetooth management interface 1.18 initialized
Oct 11 14:32:21 homeassistant systemd[1]: Started Raspberry Pi bluetooth helper.
Oct 11 14:32:21 homeassistant bthelper[417]: Raspberry Pi BDADDR already set
Oct 11 14:32:21 homeassistant bthelper[426]: [58B blob data]
Oct 11 14:32:21 homeassistant bthelper[426]: [59B blob data]
Oct 11 14:32:21 homeassistant bthelper[426]: Failed to set power off: org.bluez.Error.Busy
Oct 11 14:32:21 homeassistant systemd[1]: bthelper@hci0.service: Main process exited, code=exited, status=1/FAILURE
Oct 11 14:32:21 homeassistant systemd[1]: bthelper@hci0.service: Failed with result 'exit-code'.
The latest version of the pi-bluetooth package introduced a sleep before
powering off the device, however, presumably for a different reason:
ae2efdeee8 (diff-609c8a23261988c47afd40be9b012feb1d167de8761c1301e44e1864635c19e3)
Anyways, this latest version seems to also fix the above mentioned race
condition.
Sometimes the first command after starting the Docker daemon container
fails, presumably because the container did not start yet. Wait until
the Docker daemon is ready.
* Use skopeo to download container images
Separate container download from image build. This will allow to share
the downloaded images between multiple builds.
We won't store the Supervisor container with the version tag, just with
the latest tag. This allows to simplify the procedure a bit. It seems
there is no downside to this approach.
* Use official Docker in Docker images to build data partition
Instead of building our own Debian based image let's use the official
Docker in Docker image. This avoids building an image for the hassio
data partition and speeds up build as well.
This calls mount commands using sudo to mount the data partition as part
of the buildroot build now. This is not much different from before as
mount has been called as root inside the container, essentially equates
to the same "isolation" level.
* Use image digest as part of the file name
The landing page has no version information in the tag. To avoid
potentially source caching issues, use the digest as part of the file
name.
Add buildroot utils/check-package check to the pr-checks.yml workflow.
It checks for common errors/mistakes when creating own buildroot
packages. Also fixed all warnings this utility output for our existing packages.
* Enable some useful kernel configurations
* Add xe-guest-utilities for better Xen support
Add guest utilities and make sure the Xen guest daemon gets started
when running under Xen virtualization.
* add eq3_char_loop package (eQ-3 char loopback kernel module)
* add generic_raw_uart package (low-latency raw UART kernel driver)
* add rpi-rf-mod package
* add device tree overlay support for RPI-RF-MOD/HM-MOD-RPI-PCB on Raspberry Pi
* enable GPIOLIB and GPIO_SYSFS required for RPI-RF-MOD/HM-MOD-RPI-PCB support.
* add basic RPI-RF-MOD/HM-MOD-RPI-PCB support for ASUS Tinker Board
* add device tree overlay support for ASUS Tinker Board and add
haos-config.txt loading support to U-Boot boot script
The latest version of OS Agent sets haos.wipe=1 as kernel argument to
trigger a device wipe. Let systemd pickup this kernel command line
argument and start haos-wipe.service.
This rather complex architecture allows to add other triggers in the
future, e.g. a button read in the boot loader.
* Disable systemd-logind support for udisks2
Currently udisks2 uses systemd-logind to prevent the system from
rebooting or similar operations while udisks operations are ongoing.
Unfortunately this stops us from using udisks2 during early boot since
systemd-logind is not ready at this point. Make the dependency
configureable so we can opt-out of using systemd-logind.
* Make dbus.service/socket and udisks2.service/socket available early
Disable default dependencies. This avoids those services to be ordered
after sysinit.target, and makes them available before local-fs.target
is reached. All mounts like mnt-data.mount are ordered before
local-fs.target, so breaking this dependency allows to use D-Bus before
mounting local file systems.
This seems fine when using the system bus directly from /run (instead of
/var/run, which is anyway a symlink to /run normally). It seems that
udisks misses /var/lib/udisks2 but it seems not to be required for the
features used so far.
* Add udisks2 package
Add latest release of udisks2 as a package. Also disable polkit to avoid
excessive dependencies.
* Add udisks2 and os-agent to Home Assistant OS
* Bump OS Agent to latest version with udisks support
This matches the 1.2-4+rpt8 release of Raspberry Pi OS' bluez-firmware
package. It addresses mainly addresses Spectra fix for CYW43455
(CVE-2020-10370).
Also update the Bluetooth start scripts with CM4 support and some
minor improvements.
* Improve ASUS Tinker Board support for 5.10
Remove patches which are unnecessary. Revert DMA for UART as it seems to
cause more problems (its also what Armbian is doing). With that
Bluetooth firmware seems to load without errors when loaded before the
bluetooth daemon is running!
Note: It seems that the board overheats quite quickly. With Armbian,
without load, that seems not to be a big deal, but HAOS does quite a
bunch at startup, leading the CPU to reach the 90°C trip point. Maybe it
was related to the rather closed shelf I have the ASUS Tinker board
running, but only after using a fan the board behaved for me.
* Use hardware flow control explicitly
The rtk_hciattach program uses hardware flow control by default (judging
from tty settings after starting the program). Just to be sure,
explicitly request 115200 and hardware flow control.
* Add Realtek RTL8812AU out-of-tree driver
This adds support for Realtek RTL8812AU devices such as the Hardkernel
WiFi Module 5A (with the RTL8811AU chipset, supported by this driver as
well). This patch uses Realtek driver 5.9.3.2 which has been made to
compile up to Linux 5.10.
Note: This driver does not seem to support 5GHz networks! But it seems
the only driver which supports the RTL8811AU chipset and also works with
recent mainline drivers...
* Enable RTL8812AU driver for Hardkernel modules
The WiFi Module 5A comes with a RTL8811AU chipset. Enable the driver for
all Hardkernel modules.
* Add 2020-10-28 beta EEPROM
This improves boot from USB and speeds up boot times.
also includes sd card v1 boot reliability.
see https://github.com/raspberrypi/rpi-eeprom/pull/246
Also add HDMI_DELAY=0 so HDMI display is always visible
for easier debugging.
* Use double quote to prevent globbing and exit with error in case
directory doesn't exit in hassos-hook.sh
* echo flags are undefined in POSIX, use bash instead in
bluetooth-rtl8723
* Update buildroot-patches for 2020.11-rc1 buildroot
* Update buildroot to 2020.11-rc1
Signed-off-by: Stefan Agner <stefan@agner.ch>
* Don't rely on sfdisk --list-free output
The --list-free (-F) argument does not allow machine readable mode. And
it seems that the output format changes over time (different spacing,
using size postfixes instead of raw blocks).
Use sfdisk json output and calculate free partition space ourselfs. This
works for 2.35 and 2.36 and is more robust since we rely on output which
is meant for scripts to parse.
* Migrate defconfigs for Buildroot 2020.11-rc1
In particular, rename BR2_TARGET_UBOOT_BOOT_SCRIPT(_SOURCE) to
BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT(_SOURCE).
* Rebase/remove systemd patches for systemd 246
* Drop apparmor/libapparmor from buildroot-external
* hassos-persists: use /run as directory for lockfiles
The U-Boot tools use /var/lock by default which is not created any more
by systemd by default (it is under tmpfiles legacy.conf, which we no
longer install).
* Disable systemd-update-done.service
The service is not suited for pure read-only systems. In particular the
service needs to be able to write a file in /etc and /var. Remove the
service. Note: This is a static service and cannot be removed using
systemd-preset.
* Disable apparmor.service for now
The service loads all default profiles. Some might actually cause
problems. E.g. the profile for ping seems not to match our setup for
/etc/resolv.conf:
[85503.634653] audit: type=1400 audit(1605286002.684:236): apparmor="DENIED" operation="open" profile="ping" name="/run/resolv.conf" pid=27585 comm="ping" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
The landingpage container is a minimal webserver with built-in zeroconf
annoucement. Preinstall the machine specific landingpage container to
make sure it will show up right after startup.
The proposed changed is to run the qemu guest agent for QEMU hypervisor. QEMU hypervisor and KVM hypervisor are using the same guest agent.
systemd allow detecting the difference between the two hypervisors. The change is using OR trigger, meaning it will trigger if one of the "ConditionVirtualization" rules is true.
