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] 98fc09128b
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
Use the version used in the docker-engine package to ensure it stays in sync.
Although we haven't seen any issues related to the fact it was sometimes
mismatching, reduce the burden of needing it to be synced manually.
This might be required for some modern Intel processors (Meteor Lake and newer)
which fail to boot Linux kernel without x2APIC controller when some features
(e.g. VT-d or x2APIC itself) are enabled in the BIOS.
Enable it also for OVA, as it can be emulated in virtual machines, even when
the host CPU does not support it.
Fixes#4337, fixes#4144, fixes#4345
The CPUfreq governor "powersave" sets the CPU statically to the lowest
frequency within the borders of scaling_min_freq and scaling_max_freq.
This can be useful if a particular power budget should not ever be
crossed. Can be set using `cpufreq.default_governor=powersave`. Note
that this obviously affects performance.
* 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
RaspberryMatic was renamed to OpenCCU in
https://github.com/OpenCCU/OpenCCU/pull/3162. This caused change of the name of
the directory in the source tarball, causing build failure when the archive
wasn't cached.
The extra information printed when using the top-level makefile can clutter the
output when it needs to be further processed, e.g. when running
`make show-info | jq`. Make it respect the --silent flag (which also suppresses
messages about changing directories which would break parsing as well).
Use the --cidfile Docker CLI argument when starting the container and
bind-mount the generated file containing full ID of the container to the
container itself.
Using --mount instead of --volume is needed, as --volume is racy and creates
empty directory volume at the destination path instead.
This is prerequisite for home-assistant/supervisor#6006 but can come handy for
other cases too.
Upstream commit [1] caused regression in IPv4 routing which can cause some
routes becoming broadcast even though they should be routed as unicast, e.g.:
# ip route get 1.1.1.1
broadcast 1.1.1.1 via 192.168.122.1 dev enp0s3 src 192.168.122.204 uid 0
cache <local,brd>
It's not entirely clear yet why it happens but this behavior seems to be
triggered for instance when the SSDP integration sends the broadcast packet on
HA startup. While this behavior is not described in the regression report [1],
the commit cherry-picked from Linux master fixes the problems for us as well.
Patches moved to version-specific folder, as this one shouldn't be applied on
Raspberry Pi targets.
[1] https://lore.kernel.org/all/20250710142714.12986-1-oscmaes92@gmail.com/
[2] https://lore.kernel.org/stable/20250822165231.4353-4-bacs@librecast.net/Fixes#4265
(cherry picked from commit 78bda4bd10cc6edace9d5f5c54bd81821c04db45)
Upstream commit [1] caused regression in IPv4 routing which can cause some
routes becoming broadcast even though they should be routed as unicast, e.g.:
# ip route get 1.1.1.1
broadcast 1.1.1.1 via 192.168.122.1 dev enp0s3 src 192.168.122.204 uid 0
cache <local,brd>
It's not entirely clear yet why it happens but this behavior seems to be
triggered for instance when the SSDP integration sends the broadcast packet on
HA startup. While this behavior is not described in the regression report [1],
the commit cherry-picked from Linux master fixes the problems for us as well.
Patches moved to version-specific folder, as this one shouldn't be applied on
Raspberry Pi targets.
[1] https://lore.kernel.org/all/20250710142714.12986-1-oscmaes92@gmail.com/
[2] https://lore.kernel.org/stable/20250822165231.4353-4-bacs@librecast.net/Fixes#4265
