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.
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.
* 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
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).
* Drop default NetworkManager configuration
NetworkManager will automatically connect using the global defaults.
Also Supervisor today will create a profiles once the user configures
the network explicitly.
* Create system-connection directory
* Add AArch64/ARM64 EFI boot support (for QEMU and some boards)
* Allow GRUB to load cmdline.txt-like
* Enable qcow2/vmdk disk images
Co-authored-by: Stefan Agner <stefan@agner.ch>
* updated generic_raw_uart to latest version which comes with dualcopro
support for the HmIP-RFUSB usb rf-sticks by eQ3/ELV.
* remove 99-hmip-rfusb.rules to keep a HmIP-RFUSB device free from being
occupied by the cp210x driver but use the new generic_raw_uart support
instead allowing for advanced dualcopro support for HomeMatic/BidCos-RF
and homematicIP support in parallel.
* Add systemd-journal-remote to the image
This allows to access journald's log from within Supervisor and expose
more system logs to users.
* Allow to access systemd-journal-gatewayd from Supervisor
Create a systemd-journal-gatewayd.socket service using a Unix socket and
bind mount it into the Supervisor container. This allows to query
systemd-journald from Supervisor directly.
Currently the hassos-apparmor.service wants the
hassos-supervisor.service and vice-versa. This is unnecessary and leads
to activation of hassos-supervisor.service when reload/restart
hassos-apparmor.service (Supervisor is doing that on startup).
Make hassos-apparmor.service independent and add dependency as well as
ordering from hassos-supervisor.service side.
* Avoid duplicate log entries
So far the hassos-supervisor.service starts the hassos-supervisor script
which in turn attaches to the Supervisor container. This causes stdout
and stderr to be forwarded to the service unit, which in turn logs it in
the journal.
However, Docker too logs all stdout/stderr to the journal through the
systemd-journald log driver.
Do not attach to the Supervisor container to avoid logging the
Supervisor twice.
Note that this no longer forwards signals to the container. However, the
hassos-supervisor.service uses the ExecStop= setting to make sure the
container gets gracefully stopped.
* Use image and container name as syslog identifier
By default Docker users the container id as syslog identifier. This
leads to log messages which cannot easily be attributed to a particular
container (since the container id is a random hex string).
Use the image and container name as syslog identifier.
Note that the Docker journald log driver still stores the container id
as a separate field (CONTAINER_ID), in case the particular instance need
to be tracked.
Since we start the HomeAssistant shell directly on tty the service
responsible for starting did not restart the shell on exit. Remove the
RemainAfterExit flag to make sure that the shell restarts on exit.
When using quotes currently, they are not passed to HA due to $*. This
doesn't allow to use some commands properly, e.g. snapshot restore with
a passwort with spaces:
```
ha snapshot restore c31f3c93 --password "test test"
...
time="2021-05-26T11:24:19+02:00" level=fatal msg="Error while executing rootCmd: accepts 1 arg(s), received 2"
```
Properly pass all arguments using $@ in quotes.
* Recreate Supervisor container on OS upgrade/downgrade
When the operating system gets upgraded or downgraded the Supervisor
start script might start the Supervisor slightly differently (e.g. with
RT scheduling support). If the container has already been created, a OS
upgrade or downgrade won't recreate the Supervisor container.
* Move startup script version file to /mnt/data
* Start ha-cli on tty1 instead of a getty
Instead of starting a getty start the ha-cli directly. This will show
the banner right on startup with the important information such as IP
address of the instance or the URL to reach it.
* Use default shell as root shell instead of HA CLI
Instead of using the ha-cli.sh script as login shell use the regular
shell. Amongst other things, this allows to run VS Code devcontainers
remotely via SSH or using scp. The HA CLI is still available using the
`ha` command.
* Enable systemd-time-wait-sync.service by default
Enable the systemd-time-wait-sync.service by default. This allows to use
the time-sync.target which allows to make sure services only get started
once the time is synchronized.
* Make sure time is synchronized when starting hassos-supervisor.service
Use the time-sync.target to make sure that the Supervisor gets stsarted
after the time has been synchronized.
* Set timeout for systemd-time-wait-sync.service
Don't delay startup forever in case time synchronization doesn't work.
This allows to boot the system even without Internet connection.
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.
* Add --cpu-rt-runtime to allow Docker allocate real-time CPU time (#1235)
* Enable Supervisor's CPU bandwith allocation feature (#1235)
Since we have CONFIG_RT_GROUP_SCHED enabled in the Home Assistant OS
kernel the Supervisor needs to enable CPU bandwith allocation for
Add-Ons which need real-time scheduling. Set the appropriate environment
variable.
It seems that Busybox shell (ash) cannot calculate the disk size
properly probably due to integer overflow. Use jq to calculate the last
usable LBA which seems to be able to handle large integers.
There are incident reports on the internet where poeple report that
fsck.(v)fat actually leads to problems rather file system fixes. Around
the time when Home Assistant OS added fsck.fat for the boot partition,
reports of empty boot partitions or file with weired filenames started
to appear. This could be caused by fsck.fat.
Disable fsck on the boot partition.
Use udev rules to set the CPU online. For memory, we let the kernel
bring memory online automatically. This is preferred as udev rule
processing might be delayed in a low memory situation, see:
https://lwn.net/Articles/668944/
Partition handling for disks with 4k sectors broke partition resizing
when using MBR disk label. It seems that sfdisk doesn't calculate the
last LBA for diks with MBR label. Calculate the last usable LBA ourselfs
in the MBR case.
The calculation whether to resize the partition only works with disks
with 512 byte sector size. Use values provided by sfdisk exclusively to
make sure comparing the same sector size.
Furthermore, it seems that sgdisk does not like sfdisk's backup GPT
placement:
$ sgdisk -e /dev/zram1
Warning! Secondary partition table overlaps the last partition by 250 blocks!
Today it seems sfdisk can handle GPT quite well. Use sfdisk for all
operations in hassos-expand.
The supervisor container requires the "hassio-supervisor" AppArmor
profile. Make sure our AppArmor service hassos-apparmor is a dependency
of the hassos-supervisor.service.
* Use systemd-growfs instead of resize2fs (#1106)
Since systemd 236 systemd has a built-in file system growing mechanism.
The mechanism relies on the kernels online file system resize
capabilities instead of the external resize2fs utility. Online resizing
is supposedly much faster since the kernel takes care of things.
This also makes sure that external file systems get resized which
previously have not been taken care of.
* Drop HA OS specific file system resizing
Since we have systemd-growfs in place now we can drop our file system
resizing code.
* Make sure /dev/disk/by-label/hassos-data is present after resizing
Note: systemd will retry mnt-data.mount later, so at least in theory
this shouldn't really matter. However, the journal has a lot of churn
due to that reordering.
When we write the update to the boot partiton, there is nothing which
makes sure that data is written to disk. This leaves a rather large
window (probably around 30s) where a machine reset/poweroff can lead
to a corrupted boot partition. Use the sync mount option to minimize the
corruption window.
Note that sync is not ideal for flash drives normally. But since we
write very little and typically only on OS update to the boot partition,
this shouldn't be a problem.
