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.
* 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.
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
* 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).
Some applications try to increase the buffers for performance reason. The
QUIC Go implementation for instance tries to request a 2048 kiB buffer
size.
The kernel default depends on skubuf size (which is architecture
dependent), but it is memory size independet and typically around 200 kiB
(see [1]).
Other network tuning guides suggest 16MiB for 1GB ethernet, as well as
changing the default as well as maximum bufffer size (see [2]). This
conservatively increases the maximum buffer size to 4MiB.
[1]: https://elixir.bootlin.com/linux/v5.15.45/source/include/net/sock.h#L2742
[2]: https://nateware.com/2013/04/06/linux-network-tuning-for-2013/
* Enable additional LED triggers
* Improve Yellow device tree
Fix soundcard name and use BTN_1 as key code.
* Add input-event-daemon configuration
Add minimal input-event-daemon configuration to avoid the default
configuration taking effect. This minimal configuration triggers
the USB configuration import on button press.
Enable IPv6 forwarding by default which is useful to run IPv6 based
OpenThread Border Router.
Currently Docker enables IPv4 forwarding by default. Enabling IPv6
support will enable IPv6 routing as well, but we are not ready yet to
enable IPv6 support for Docker at this point.
Enabling IPv6 forwarding should be harmless as there are no IPv6
addresses configured internally and Home Assistant OS is not typically
dual-homed. In cases where it is dual-homed (e.g. VPN), routing is
often used and firewalling is setup as part of that add-on.
* 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.
Add a minimal motd so users know what kind of system they just logged
in. Also add the hint that the Home Assistant CLI is still available
using the command ha.
* 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.
* Use interface-name to exclude veth
The type veth is not a valid type (see [1] for how to obtain a list of
valid device types. Use `driver` to filter veth.
Note: It seems that NetworkManager did not manage veth so far, so this
change seems not to be relevant in practice.
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
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.
So far the exit code has been evaluated, which seems to be non-zero even
with a regular term signal. With that systemd assumed the service is in
a failed state, when in fact this seems the regular behavior of dropbear
when shutting it down.
