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 2d3119ef22 ("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
* Bump buildroot
* buildroot 0397d9c8f0...2ba3394abf (1):
> package/docker-engine: use kernel modules for extra network drivers
* Make IPv6 SIT tunnel driver a kernel module
This is what distributions seem to be doing too.
Currently systemd-timesyncd tries to connect to the NTP server quite
early at boot-up. At this time the network connection has not been
established yet. This causes resolving the NTP server to fail and
a rate limit kicks in which makes systemd-timesyncd wait for 30s until
the next attempt.
Lowering the retry attempt to 10s makes systemd-timesyncd connecting
shortly after.
Note: The rate limit is 10 attempts per 10s. Because the attempts are
immediately exhausted lowering connection retry attempt below 10s
adds no benefit.
See also: https://github.com/systemd/systemd/issues/24298
* buildroot 97287bbebf...0397d9c8f0 (5):
> package/docker-proxy: bump version to f6ccccb1c082
> package/containerd: security bump to 1.6.6
> package/docker-engine: bump to version 20.10.17
> package/docker-cli: bump to version 20.10.17
> package/runc: bump to version 1.1.3
* Load container images descending by size
Loading container images using docker load seems to require more space
at load time (which gets freed after loading). Loading the largest
container first avoids running out of space.
* Bump buildroot
* buildroot 99b62b8bd3...97287bbebf (3):
> package/dbus-broker: bump to release 32
> package/dbus-broker: new package
> Merge pull request #3 from home-assistant/2022.02.x-haos-cgroup-v2
* Use dbus-broker as default D-Bus broker
The dbus-broker (Linux D-Bus Message Broker) aims to be a high
performance and reliable D-Bus broker which can be used as a drop in
replacement to the reference implementation D-Bus broker. In tests it
showed significantly better performance especially when routing BLE
messages.
* Allow dbus-broker to start early
For HAOS device wipe feature we need haos-agent.service and
udisk2.service early. Both require a working D-Bus broker.
The options PrivateTmp and PrivateDevices add additional After=
orderings which doesn't allow dbus-broker to be started early.
* Fix D-Bus dependency
D-Bus services should just depend on dbus.socket.
* Disable real-time scheduling
It seems that Linux' cgroup v2 currenlty does not support RT scheduling.
* Remove Supervisor RT support flag
With CGroups v2 we can no longer support CPU resource allocation for
realtime scheduling.
* Bump OS Agent to 1.3.0 for CGroups v2 support
This makes the Red+Blue Button cause the boot loader to wipe start4.elf,
which is essential for the boot loader to boot from eMMC. With the file
missing, the Raspberry Pi firmware will continue its boot flow and boot
from USB host next. This allows to run the Home Assistant OS Installer
from a USB flash drive again.
A faster restart policy is unlikely to help. Increasing the limit makes
it less likely to run into cloud service rate limits (e.g. container
registry).
