The persistent timesyncd configuration is a single bind-mounted file
over /etc/systemd/timesyncd.conf. The NTP configuration through OS Agent
(home-assistant/os-agent#207) attempted to do atomic updates, but a
temporary file cannot be created next to it in the read-only
/etc/systemd, and replacing the file in the overlay directly changes the
inode, so the bind mount keeps pointing to the old content. Also, a
persisted copy of the whole file means changes to the shipped defaults
never reach existing installations.
Bind-mount the /etc/systemd/timesyncd.conf.d directory from the overlay
instead and keep the shipped timesyncd.conf read-only. Configuration is
layered as drop-ins, from lowest priority to higher:
* 10-ntp.conf (in /run): NTP servers from DHCP
* 20-custom.conf: timesyncd.conf imported from the CONFIG partition
* 50-os-agent.conf: NTP servers set through the OS Agent D-Bus API
On upgrade, settings from the previously persisted timesyncd.conf other
than the shipped defaults are moved to 20-custom.conf. This migration
can be removed later (with #4986). 50-os-agent.conf should be only
managed by OS Agent, so we don't need to care about user's edits.
Finally, if needed, drop-ins with higher priorities can be added for
complex customizations.
Refs home-assistant/supervisor#6278
Corrupted Docker image layers cannot be always fixed by removing and
re-pulling a single image, because layers are shared between images. The
only (easy) way to recover is wiping all of Docker's storage which is
currently cumbersome and requires OS shell access.
Add service triggered by /mnt/data/docker/.wipe-scheduled flag file
which wipes the Docker directory by atomically renaming it and deleting
synchronously. If this is interrupted, docker-prepare script removes the
leftovers before Docker is started on every boot.
It should be noted that docker-prepare also forces the switch to
containerd snapshotter after the wipe.
Refs home-assistant/supervisor#6555
Dropbear has no ordering relationship to haos-supervisor.service or
docker.service, so systemd schedules all three stop jobs in the same
batch and runs them concurrently. Dropbear exits within milliseconds
while the Supervisor gets up to 450s to stop containers, which means an
SSH session is dropped right when the interesting part of shutdown
starts. That makes it needlessly hard to debug slow shutdowns.
Order Dropbear before both units. Since stop order is the reverse of
start order, systemd now stops it only once the Supervisor and Docker are
gone. This is an ordering-only dependency: if Dropbear fails, is masked
or is skipped by its ConditionFileNotEmpty=, the ordering counts as
satisfied and both units start as before. It adds no boot latency
either, as docker.service already waits for the overlay partition that
Dropbear needs for /etc/dropbear.
Verified on a generic-x86-64 VM: an SSH session now survives the full
22.4s Supervisor teardown, and systemd stops Dropbear last, 3ms after
docker.service is gone.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The HA CLI unit (and the serial getty drop-in) pulled in
haos-supervisor.service via Wants=. Since #4326 the CLI unit is
configured to never reach its start limit (RestartSec=100ms,
RestartMaxDelaySec=3s, StartLimitIntervalSec=3s), so it restarts
indefinitely - and every restart starts the Supervisor again.
This makes it impossible to stop the Supervisor for debugging: stopping
haos-supervisor.service and removing the containers terminates
hassio_cli, which makes ha-cli@tty1.service exit and restart, which
immediately starts the Supervisor back up.
The Wants= is not needed: haos-supervisor.service is
WantedBy=multi-user.target and gets started on boot regardless. Drop it
and keep only the After= ordering.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Make Supervisor startup resilient to transient network failures
When the Supervisor image is missing and no local updater information is
available (e.g. on first boot after a factory reset/data wipe), the start
script fetches the current stable version from version.home-assistant.io.
This fetch can fail transiently: since #3669 the boot waits at most 15s
for time synchronization, so the script may run with an unsynced clock
(making TLS validation fail), or before the network is fully functional.
Today such a failure makes the script exit within ~400ms (via jq -e exit
code 4 under set -e). Combined with RestartSec=5s and StartLimitBurst=3,
three quick failures trip the start rate limit within ~15 seconds and the
unit stays failed until reboot - even if NTP syncs moments later, leaving
the device at the emergency console (as seen in #4863).
Make this path more robust:
- Let curl retry the version fetch (5 retries, 10s apart). Use
--retry-all-errors so DNS/TLS failures are retried as well, not just
transient HTTP errors.
- Increase the service start rate limit from 3 to 5 attempts per 30
minutes, so a slightly longer network/time-sync hiccup at boot doesn't
permanently disable the unit.
- Skip "docker image rm" in the startup-marker recovery path when there
are no Supervisor images at all, avoiding a spurious usage error.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix AppArmor profile download never retried after first failure
The haos-apparmor script only downloads the Supervisor AppArmor profile
when the profile directory is missing - but it creates the directory
before attempting the download. If the first download fails (e.g. no
DNS/network on first boot after a data wipe), every subsequent boot
skips the download because the directory exists, and the unit exits
successfully without loading any profile. The Supervisor container is
then created with --security-opt apparmor=hassio-supervisor and fails
to start forever with:
apparmor failed to apply profile: write .../attr/apparmor/exec:
no such file or directory
(observed in #4863 after the reporter fixed their DNS setup).
Key the download on the profile file instead of the directory, download
to a temporary file that is moved into place only on success, and let
curl retry transient failures like in the Supervisor version fetch.
Also fail the unit loudly when the download does not succeed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Apply suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Use upper case for STABLE_JSON variable
Match the naming convention of the other variables in the script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
The haos-expand.service ("HAOS data resizing") is a Type=oneshot unit
without an explicit timeout, so it inherited systemd's
DefaultTimeoutStartSec (90s). On slow or previously used disks the data
partition resize can take longer than that, causing the service to be
killed and mnt-data.mount to fail with "Dependency failed for HAOS data
resizing", leaving the system unusable.
Aborting the resize serves no purpose: if it fails the installation is
broken anyway. Set TimeoutStartSec=infinity so the resize runs for as
long as it needs instead of failing the boot.
Fixes#3365
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Harmonize systemd unit and helper-script prefixes to haos (#4725)
Rename the hassos-prefixed systemd units and their ExecStart helper
binaries to a consistent haos- prefix, and update all in-repo
references. Normalize the affected unit Description= strings as well.
Units renamed in this commit are not referred externally (except for
syslog identifiers used in Supervisor Host logs), so no other changes
should be needed.
* Rename hassos-config to haos-config with alias
Rename the hassos-config.service unit and its binary to the haos-
prefix. This unit is restarted by Supervisor in os/manager.py, so add
Alias= to avoid the need to try both variants there.
* Rename hassos-cli binary to haos-cli
* Change HassOS to HAOS in unit descriptions and comments
* Rename hassos->haos in Buildroot makefiles, scripts and configs
* Rename bootargs_hassos to bootargs_haos in U-Boot scripts
* Rename external Buildroot tree HASSOS to HAOS
Set external.desc name to HAOS and rename all BR2_EXTERNAL_HASSOS_PATH
references to BR2_EXTERNAL_HAOS_PATH accordingly.
* Rename hassos.conf service drop-ins to haos.conf
* Rename hassos.config kernel fragment to haos.config
* Rename hassos-blobs repo in package/bluetooth-rtl8723
The repo was renamed somewhere in the past and it now relies on an
internal GitHub redirect. Change the URL to match the new repo name.
Since switching to systemd-resolved we've announced Home Assistant
Operating System as a workstation through _workstation._tcp DNS-SD. This
most likely came in to preserve what avahi announced by default.
However, the service has not a clear definition what it means and there
is no need for the service announcement really. The host name gets
announced even without a service announcement. This commit removes the
service announcement file from the rootfs.
Give Supervisor enough time to gracefully stop Home Assistant Core, apps
and plugins when the host shuts down. The unit is already ordered
After=docker.service, so on a host reboot or power off it is stopped
before Docker tears containers down.
Supervisor should handle the SIGTERM from "docker stop" by running its
managed shutdown within 420 seconds, after that point it would be killed
by Docker, and ultimately 30 seconds later by Systemd.
Also, drop the delay after SIGTERM for ha-cli added in #2507. Once
Systemd shutdown is invoked, the ha-cli is no longer restarted.
Refs #4642, refs #4584
Previously the watchdog timeout was set to "default", which makes
systemd adopt whatever timeout the underlying hardware driver
advertises. In practice this means very different behavior across
platforms: common x86-64 watchdogs (iTCO_wdt, i6300esb on virtual
systems) default to around 30 seconds, while the Raspberry Pi BCM2835
watchdog uses 15 seconds.
These short timeouts have proven too aggressive in the presence of
stalled network storage. PID1 enters the kernel through paths that can
park it in D-state on a dead NFS mount: mount_enter_mounting() calls
chase()/open_tree(), is_dir()/mkdir_p_label() on bind mount sources,
and mkdir_p_label()/unit_warn_if_dir_nonempty() on destinations all
end up in nfs_lookup/nfs_getattr/nfs_readdir, waiting for an RPC major
timeout. While PID1 is blocked it cannot ping the watchdog, and the
system reboots even though the underlying issue is a network storage
stall, not a kernel hang. Reported upstream as
https://github.com/systemd/systemd/issues/42050.
Set RuntimeWatchdogSec to 5 minutes to align all platforms on a
single, conservative value that tolerates NFS/CIFS RPC timeouts while
still recovering from genuine PID1 hangs.
A note on hardware limits: some watchdog drivers expose a
max_hw_heartbeat_ms instead of max_timeout. In that case the watchdog
core in drivers/watchdog/watchdog_dev.c arms a kernel timer that pings
the hardware in the background and multiplexes a longer userspace
timeout on top, so a 300s request is accepted even when the silicon
counter cannot represent it. The BCM2835 watchdog used on all
Raspberry Pi variants is exactly this case: the PM_WDOG_TIME_SET
register caps at ~16s of hardware heartbeat, but the driver migrated
to the max_hw_heartbeat_ms path in v6.8 (commit f33f5b1fd1be
"watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling", Dec 2023), so
WDIOC_SETTIMEOUT(300) is honored — the core re-pings the chip every
~15s automatically and only stops once userspace has been silent for
the full 300s. Drivers that still use max_timeout directly will reject
300s with -EINVAL and systemd falls back to the driver's own value;
this is no worse than the previous "default" behavior.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
For users having non-English, and especially non-qwerty layouts, using the host
shell can be very awkward. There was no option to change the keymaps as they
haven't been installed in the OS, and the persistence couldn't have been
achieved because of read-only /etc.
With upstream patch merged in #4224, we have an option to put
/etc/vconsole.conf to a writable location and use the same approach as in the
timezone PR. This is needed because even if we only bind-mounted the file from
the overlay directory, the Systemd services which start early will still refer
to the inode on the read-only FS. Also, gzip is required as current version of
kbd in Buildroot (v2.6.4) always compresses the keymaps using gzip. We can get
rid of this after we bump to kbd v2.9.0 [1] or newer. The overall bloat in
local build of the OS is slightly over 1 MiB, so it is acceptable.
With these changes, the `localectl set-keymap` command can be used to use any
available keymap from the installed `kbd` package (refer to `localectl
list-keymaps` for complete lists) and persist it between reboots.
[1] https://github.com/legionus/kbd/releases/tag/v2.9.0Fixes#1775
The deprecated-key-path option is no longer handled, but it doesn't cause
problems because the key is explicitly ignored. It was completely removed in
Docker 19.03.0 [1].
As such, the option and the pre-start script to fix the corrupted key.json can
be removed now, as it has no effect, only printing confusing message when
Docker service fails to start.
[1] http://github.com/moby/moby/commit/98fc09128b3f8221680bd22c2de5b893bd3d7ef8
Prefer the containerd snapshotter by using it by default for new installs and
when no Docker data is present (e.g. after datadisk wipe). The snapshotter is
enabled by a dockerd flag which is set when a flag file is present in the data
partition. This flag file can be used also to opt-in for this snapshotter on
legacy installs (high level API through OS Agent and Supervisor TBD), to
migrate to the containerd snapshotter this file can be simply created manually.
Testing shown no major problems when migrating, the old overlay2 folder can be
(and should be - to avoid situations where the data disk might run out of
space) deleted before the docker.service is started in the docker-prepare
script.
Note that there's no offline migration path, OS needs to be connected to the
internet to re-download the images when migrating. This could be theoretically
possible through docker image save/load functions but guarding for enough of
space and other edge cases would be probably too complex to justify it.
Refs #4252
Refs #4253 - easier opt-in method is still needed
Closes#4254 - migration is handled seamlessly by Docker
* Improve UX of HA CLI wrapper and emergency console
For many users, the emergency console gives feeling that the system is
completely broken. However, there are various cases when the system just takes
just a bit longer to start up and the emergency message is shown, while it
finishes a proper startup shortly after. This change tries to improve the UX in
several ways:
* The limit before a forced emergency console startup is changed to 3 minutes
* Waiting can be interrupted with Ctrl+C (reset counter is cleared then)
* Some hints what to check have been added before starting the shell
* Also, because if the HA CLI failed for 5 times in a row in quick succession,
the CLI startup was then not retried anymore and user may have been left with
a black screen, the restart limits timeouts have been adjusted only to back
off and never mark the unit as failed
Closes#4273
* Use /bin/sh and printf to silence linter errors
To make system timezone configurable, we need to have /etc/localtime
writable, and it must be possible to atomically create a symlink from
this place, which means the whole parent folder must be writable. We
don't have /etc writable and can't use the usual bind mount for this.
Latest Systemd v258 has patch that allows setting an environment
variable that sets where the localtime should be written. This can be
persisted in the overlay partition, with a symlink from /etc/localtime
leading there, finally pointing to the actual zoneinfo file. If the
symlink doesn't exist, create it by hassos-overlay script (it's not
really needed as UTC is the default, but Systemd does the same if you
change from non-UTC timezone back to UTC).
Also disable BR2_TARGET_LOCALTIME, so /etc/localtime and /etc/timezone
(the latter is only informative and non-standard) are not written by the
tzdata package build.
In some cases, the wipe service may be called due to a race condition for the
second time during the boot, very likely failing because the filesystems are
already mounted. This can not be reproduced on OVA but can be fairly easy
triggered e.g. on RPi. As we want the service to be executed exactly only once,
we can do what's suggested in [1] and set the RemainAfterExit=yes. That should
ensure the unit is not ever started for the second time.
[1] https://www.github.com/systemd/systemd/issues/29367
Use simple shell script to perform device wipe instead of calling OS Agent to
do that through the UDisks2 API. While it might have been a good idea to use
high level interface for that back then, it turns out it causes more issues
than the benefits it could bring.
Main problem currently is that the OS Agent needs to read sysctl variables, but
those are only set after mounting the overlay partition. But at the same time,
the overlay partition can't be mounted if we want to wipe it - this creates a
dependency cycle through the haos-agent.service.
To get rid of the cycle and simplify things, use a shell script doing basically
the same what the OS Agent does. Since the wipe functionality only makes sense
to be implemented on HAOS targets (not on Supervised), there's little point of
having it in higher layer of abstraction that OS Agent provides.
It should be also checked if changes from #1291 are needed anymore, as the
driving factor for those have been probably the wipe feature in OS Agent too,
but at this point they seem to be harmless.
Allow configuration of the swap size via /etc/default/haos-swapfile file. By
setting the SWAPSIZE variable in this file, swapfile get recreated on the next
reboot to the defined size. Size can be either in bytes or with optional units
(B/K/M/G, accepting some variations but always interpreted as power of 10). The
size is then rounded to 4k block size. If no override is defined or the value
can't be parsed, it falls back to previously used 33% of system RAM.
Fixes#968
* Move rauc.db to boot partition
The RAUC metadata file contains information that is tightly related to the
system and kernel partitions. With the possibility to migrate data disk, the
rauc.db can contain bogus information when moved to a different system. Removal
of the file on "device wipe" is also not desirable, because the information
about slot status is lost.
Relocate the rauc.db to the boot partition after a system upgrade (as this
can't be handled by RAUC hooks, because it needs to be executed after all slots
and metadata is written) and adjust the script for recreating it. The downside
is that its content in /mnt/data would be recreated if the boot slot is changed
or system downgraded but this should be handled quite gracefully.
Also remove the raucdb-first-boot service which is no longer necessary
with the file not present in the data partition.
* Fix shellcheck and mount path
The /etc/usb_modeswitch.d is present and empty but it can't be written to allow
user modification. Bind-mount it like other /etc folders to make it possible to
adjust usb_modeswitch config.
Fixes#3785
If data disk is adopted on Yellow using the mechanism added in #3686, it
contains RAUC version information that is very likely invalid. In such case,
remove the file on first boot and have it recreated by the raucdb-update
service.
The timeout of 90s was introduced before it was ensured that the timesync
systemd unit starts after network is online. Now with that, it makes less sense
to wait that long - if network is unreachable at the point the time
synchronization starts, and the server fails to reply on the first sync, the
polling interval is exponentially increased and the benefit of waiting for more
attempts is doubtful.
Since another synchronization attempt is done after network changes its state,
we should rely on that instead of having the 90 seconds interval as a waiting
period for plugging the network cable. Worst case, there are other mechanisms
that should set the time to a reasonably accurate value, making the NTP sync
less importart for most of the cases.
* Relocate HAOS Systemd drop-ins to /usr/lib/systemd
With some exceptions, Systemd drop-ins overriding default unit configuration
have been placed to `/etc/systemd/system`. This is meant for user overrides of
those, or per `man 5 systemd.unit` for "system unites created by the
administrator". Relocate all of these to `/usr/lib/systemd` which should be
used as path for units "installed by the distribution package manager" which is
closer to what we're trying to achieve.
This will make it easier to detect changes to unit files once we enable the
possibility to edit the content of /etc.
* Patch systemd-timesyncd.service instead of replacing it fully
RAUC currently doesn't know the version of the booted slot when booted for the
first time or after wiping the data partition. As a result `ha os info` is
missing this information too.
As there's no built-in mechanism for generating these data by RAUC itself, add
a oneshot service that checks if the boot slot information is contained in the
rauc.db and if not, then generate it.
RAUC seems to cope quite well even with bogus data contained in rauc.db but in
any case, a test has been added to check that everything works as expected.
* Add fsfreeze support for QEMU/KVM/Proxmox installations
Add fsfreeze scripts which calls the new Supervisor API to freeze Home
Assistant Core and add-ons which support the backup freeze scripts
(`backup_pre` and `backup_post`).
This allows to create safe snapshots with databases running.
* Fix lint issues
Pull in the swapfile creation service haos-swapfile.service when
swap.target is reached. This makes sure the service is started even when
other targets are used (e.g. rescue.target).
* Delete Bluetooth device cache regularly
Delete stale Bluetooth devices from the BlueZ device cache every week.
This makes sure that the overlay partition doesn't run out of inodes
which has happened in real world scenarios where many new Bluetooth
devices are discovered.
BlueZ maintains these files on a best effort base. So removing them
while BlueZ is running should be safe.
An alternative considered was to lower BlueZ GATT caching (e.g. by
using Cache=yes instead of always, to cache only paired devices).
However, this would hurt performance and battery lifetime of Bluetooth
devices due to additional unnecessary GATT attributes reads. This is in
particular true for Bluetooth 5.1 devices which support the Database
Hash charactristic. Caching has also helped reliability with
intermittent connections (see
https://github.com/bluez/bluez/issues/191).
More importantly, besides the GATT attribute cache the same files are
also used to cache the device names as well. This is independent of the
above mentioned GATT cache configuration (see device_store_cached_name
in BlueZ). So disabling the GATT caching alone wouldn't solve the
particular problem we are facing.
See also: https://github.com/home-assistant/supervisor/issues/4490
* Use access timestamp instead of modification timestamp
The modification timestamp gets updated regularly (on each connect) it
seems. However, using access timestamp might be more accurate, as it
seems to preserves slightly more cache files. This additional devices
might be devices we don't regularly connect but are still around (and
therefor we shouldn't reread the GATT attributes regularly).
So deleting cache entries with access time older than 7 days. Which
essentially deletes all the entries of devices which haven't been seen
the last 7 days.
To read the current LED configuration correctly /mnt/boot is required.
This change makes sure that the boot partition is mounted when the OS
Agent starts.
* Enable Multi-Gen LRU
Multi-Gen LRU should improve performance under memory pressure. This is
especially useful for embedded platforms where memory is scarce.
* Add service to configure Multi-Gen LRU
Use min_ttl_ms of 1 which is the least aggressive in terms of lag. Since
we are a server application, we can tune trashing prevention with a
higher acceptable lag.
* Use zswap instead of swap in zram
This requires a swap file which will get generated automatically on
startup.
* Fix file size and free disk space comparison
* Set zswap factor to 33%
* Set vm.swappiness to 1
Decrease swapping to a minimum. This is also recommended for database
work loads by the MariaDB documentation. In practice it causes the least
amount of writes to disk when under memory pressure, while still making
swap available when needed.
* Deactivate any external data disk device on first boot (#2390)
* Use lsblk to determine the underlying device file
Comparing major number is not reliable, e.g. virtio disks have the same
major number despite being different devices. Use lsblk to find the
underlying device, and compare the device name instead.
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.
* 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.
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).
* 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.
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.
* 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.
Jan Čermák
Stefan AgnerandClaude Opus 5
Steven Barth