The bridge support is not complete and causes issues in Supervisor.
Supervisor first needs proper support for it before we can deploy it in
Operating System.
See also: https://github.com/home-assistant/supervisor/pull/4133
* Enable wpa_supplicant access point funtionality, to allow NetworkManager to manage WiFi interfaces as HotSpots or access points.
* Add an exception, to allow NetworkManager to manage bridge interfaces whose name starts with 'bridge'.
* Update buildroot-external/rootfs-overlay/etc/NetworkManager/NetworkManager.conf
Co-authored-by: Stefan Agner <stefan@agner.ch>
Co-authored-by: Stefan Agner <stefan@agner.ch>
To get access to the experimental advertisement monitor api
experimental mode is required. This eanbles the experimental D-Bus API
by default.
See also: https://github.com/hbldh/bleak/pull/884
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).
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.
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.
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
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
* 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.
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.
* 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>
* 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.
* Rename NetworkManager default profile
Rename the NetworkManager default profile to "Home Assistant OS
default". Improve documentation on how to reset to default
configuration.
* 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.
Currently Linux has a limit of IGMP memberships of 20. When trying to
add membership to more than that, Linux fails with:
OSError: [Errno 105] No buffer space available
Allowing more memberships should not really be problematic as memory is
allocated dynamically when membership is actually added.
However, there is a protocol limit of how many memberships a host can be
in. The number of memberships needs to fit in a single group report
datagram of 64kB. In total 5459 group records fit in a datagram, but due
to IP header options this might be slightly smaller in practise.
(see https://github.com/home-assistant/core/issues/45957).
Use a limit of 1024, which should be plenty of headroom in both
directions.
Related to: https://github.com/home-assistant/core/issues/45957
It seems that on certain setups the default DNS over TLS mode
"opportunistic" causes delays of ~10s when trying to resolve names. This
is probably caused by providers and/or firewall setups not properly rejecting
connections on port 853.
It seems that also other distributions (such as Arch Linux) still
disable DNS over TLS currently. Side step issues with DNS over TLS by
disabling it for now.
Old Laptops are a popular choice to run Home Assistant: They have low
power consumption, are relatively fast and cheap to come by. However,
closing their lid by default puts a Linux system into suspend. This is
not what the typical user of Home Assistant OS wants. Ignore lid
activity in any state by default.
* Add resolved.conf to disable stub resolver and DNSSEC
There are Add-Ons which try to bind port 53 on all interfaces including
127.0.0.53. Disable the stub resolver to make them continue working. We
don't need the resolver currently anyway.
Also disable DNSSEC to make sure the baords can access a NTP time server
even when their time is incorrect (since DNSSEC validation may fail).
This is a known chicken-egg problem with systemd-resolved/systemd-timesyncd
and might be addressed in a future version, with what we can reenable
DNSSEC:
https://github.com/systemd/systemd/issues/5873
* Make sure resolve gets added only once to nsswitch.conf
Only add resolve to nsswitch.conf if not already present.
Drop AVAHI and use systemd-resolved to announce hostname via mDNS
and LLMNR. Also continue to offer the _workstation._tcp.local service
since it is used by the CoreDNS mDNS plug-in.
