* Fix Docker key.json corruption check
Since /etc/docker does not get bind mounted anymore (see #2116),
key.json from the overlay partition is used directly.
* Use -e flag for jq to get useful exit code
The cgroup_enable parameter is a Raspberry Pi kernel specific kernel
parameter. Upstream based kernel do not have the parameter, and hence
do not do anything.
This gets rid of the following message during boot:
Unknown kernel command line parameters "cgroup_enable=memory", will be passed to user space.
The image name is stored in a separate field IMAGE_NAME as well. This
allows to use the container name (e.g. `hassio_supervisor`) to get logs
of all Supervisors independent of the image name (which differs for
every version).
* RaspberryPi: Update kernel 5.15.61 - 1.20220830
* Add Yellow to the Raspberry Pi kernel update script
* Bump Yellow to kernel 5.15.61 - 1.20220830
Also drop the work around for the LED polarity as the new firmware
has been fixed.
* Explicitly select no kernel module compression
Home Assistant OS uses a compressed rootfs already, no compression for
kernel modules necessary.
* Bump buildroot
* buildroot d7e4c223e5...5468d36a26 (1):
> package/rpi-firmware: bump version to 1.20220830
This is more readable than passing arguments to the daemon directly. It
also shortens the ExecStart command significantly, which is stored in
every log entry in systemd-journald.
* Retry up to 3 times
By default, HAOS used to retry 3 times. That is still true for U-Boot
based boards. Apply the same logic for GRUB2 based systems for
consistency.
This can help to remedy intermittent internet/connectivity issuese.
Altough hacky, in practise it makes sense to give the newly installed OS
another go.
* Also apply to generic-aarch64
A higher file system commit interval can help to decrease the amount of
writes. In tests, a commit interval of higher than 30s seems not to help
much in practice. Settle with 30s for now.
Add direct access to Docker's containerd instance by passing in its GRCP
socket. This can be useful to talk to the containerd GRPC API directly,
which exposes more information than the Docker API (e.g. OOM kill
events).
It seems that Docker can fail to start if there is no space left on the
device. Try to free up some space in that case by asking journald to
limit its size to 256MiB.
This should work for any storage larger than ~2.5GiB (as the journals
maximum size is 10% of the disk size). It still should leave enough
logs to diagnose problems if necessary.
Note: We could also limit the size of the journal in first place, but
that isn't sustainable: Once that space is used up, we run into the
same problem again.
By only asking journalctl to free up if necessary, we kinda (miss)use
the journal as way to "reserve" some space which we can free up at boot
if necessary.
* rpi4: Enable arm_boost=1 to unlock 1.8Ghz CPU
The official Raspberry Pi OS enables a "boosted" 1.8GHz
mode since their Debian bullseye based release [source]. This
commit brings this feature to HA OS.
This can be helpful when debugging HAOS issues. Dropbear is only started
for users which actually enabled it by configuring a SSH key, so this
change won't have an effect for most people.
* buildroot 2083b57930...9dbf8d5e86 (3):
> package/brcmfmac_sdio-firmware-rpi: bump to latest version
> package/linux-firmware: Deploy fewer Intel WiFi 22000 series variants
> package/linux-firmware: bump version to 20220815
* Fix delaying systemd-timesyncd
Setting WantedBy=time-sync.target in a service.d config file does not
clear previous assignments of WantedBy. This caused the services to still
be pulled in by the sysinit.target, causing a ordering cycle and the
system to not start essential services.
* Remove sysinit.target from Before ordering
With commit 2d3119ef2201 ("Delay Supervisor start until time has been
sychronized (#1360)") systemd-time-wait-sync.service got enabled, which
waits until systemd-timesyncd synchronizes time with a NTP server.
By default systemd-timesyncd.service and systemd-time-wait-sync.service
are pulled in by sysinit.target. This starts the services before full
network connectivity is established. The first sychronization fails and
systemd-timesyncd only retries after a ratelimit mechanism times out.
This causes a dealy of 30s during startup. While systemd-timesyncd has
a mechanism to (re)try time synchronization when network becomes
online, it seems that those only work properly when systemd-networkd
is used, see also https://github.com/systemd/systemd/issues/24298.
Simply reordering systemd-timesyncd.service after network-online.target
does not work as it causes circular dependencies (NetworkManager itself
depends ultimately on the sysinit.target).
With this change, the services are only pulled in by time-sync.target.
That allows to order the service after network-online.target. With that
the first synchronization succeeds.
This mechanism also works when a NTP server is provided through DHCP.
In that case, a the systemd-timesyncd service is started by the dispatch
script /usr/lib/NetworkManager/dispatcher.d/10-ntp before the systemd
even considers starting the service. Tests show that the default
fallback NTP is not contacted, only the DHCP provided service.
* Move Bluetooth protocol configuration to hassos.config
Enable a couple of potential useful Bluetooth protocol drivers.
Also enable Bluetooth Network Encapsulation Protocol since the BlueZ
plug-in seems to be enabled.
* Drop OverlayFS configuration not liked by Docker
