* Improve handling of timeouts in tests
Make timeout handling in tests more transparent. Added a custom shell
driver that allows to define global timeout for commands in the config
file, and replaced for/sleep constructs with infinite loops that will be
eventually terminated by pytest-timeout plugin. Current timeouts taken
from last runs on Github CI with some extra headroom.
* test_supervisor_is_updated shouldn't be skipped if no update was needed
* Allow more time for system startup
* Allow even more time for system startup
If a reusable workflow is called from another workflow, the event_type
in the child workflow is still the same as parent's. This is a known
"feature": https://github.com/actions/runner/discussions/1884
Add a flag to inputs that has default value set to true. This is in turn
set only if the workflow is called from another one, chosing the correct
step for obtaining the OS image.
* Add test suite for Supervisor tests
* test_supervisor_is_updated should depend on test_update_supervisor
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
Print the object cache statistics before uploading them to the action
cache. The action cache accesses all files, this makes the statistics
of files used during build not useful.
* Optimize build cache for dev builds
* Remove downloaded files cache, as it doesn't save that much time and
it can't fit into the repo cache limit, randomly causing eviction of
CC object cache for a single board.
* Limit saving of the object cache only to the dev branch, because
of the restrictions for the cache access limit us from effectively
using the cache for rc/main branches anyway.
* Adjust names of the steps a bit for clarity.
* Add printing of some cache stats
* Compare old ccache files' age to Makefile
* Maintain and upload artifacts index
Make the artifacts browsable by maintaining a list of builds. This keeps
it up-to-date even when deleting images from the object storage, and
minimizes queries to the object storage.
* Add favicon
* Apply suggestions from code review
Co-authored-by: Joakim Sørensen <joasoe@gmail.com>
* Move index update outside of the build Matrix
* Add error handling and styling
* Exclude index files
* Add cache flush
* Use separate prefix for indexes
This allows to filter by prefix when generating the main index. Since
the list-objects-v2 is limited to 1000 entries, this will be a bottle
neck soon. Separating indexes allows to support up to 1000 nightly
builds.
* Add missing backslash
* Use cp and fix index format
* Sync index.html as well
* Move OS artifacts index file to root directory
This is not really GitHub related, so it shouldn't live in there.
* Adjust URL for dev builds
---------
Co-authored-by: Joakim Sørensen <joasoe@gmail.com>
Automate bump of the rpi-imager-haos.json in the version repository on
stable release so we don't have to do it manually. Uses slightly
advanced jq magic to touch only the changed fields and keep the rest of
the JSON content intact.
Automate bump of the rpi-imager-haos.json in the version repository on
stable release so we don't have to do it manually. Uses slightly
advanced jq magic to touch only the changed fields and keep the rest of
the JSON content intact.
Make sure the environment can be read and written to SD card as well.
This makes sure that first boot detection works properly too when
booting from SD card.
* Use alternative environment for release build bump
By using a separate environment, we can postpone the bump in the version
repository by adding a requirement for approval. Dev version will use
default (empty string) environment which doesn't have any constraints.
* Update build step name - it's not always dev build anymore
* Use dynamic environment name for beta/stable channels
The patch added in #2434 is not working: IS_ENABLED requires the full
config symbol including CONFIG_ prefix.
Fix the patch to make automatic IPv6 route failover depening on IPv6
reachability probes actually work.
* Fix extraction of OVA image artifact in test step
If the test image is obtained from an artifact instead of downloading,
its name contains the version as well, in that case we still need to use
wildcard expansion.
* uncompress qcow2 to a stable filename
* Create foundation for Labgrid-based OS tests
Add foundation for Labgrid-based tests of OS builds. Currently uses just
the QEMU driver, which starts a virtual machine with pristine OS, and
generates few log reports which are saved as build artifacts.
Workflow is currently triggered either manually by specifying an OS
version, or by OS build job, which now saves an artifact of the OVA
image. This allows for some modularity. If we eventually add the
possibility to run builds on PRs, we could also add the workflow_call
trigger and turn the workflow into a reusable one.
TBD (in future PRs): some meaningful tests and possibility to test on
real hardware (either local or distributed).
* Apply suggestions from @agners
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Wrap test command in a script, create venv for local tests
* Make shellcheck happy
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
* buildroot b1c6a5e707...81cb78a54b (86):
> Update for 2023.02.6
> package/libhtp: bump to version 0.5.45
> package/exim: security bump version to 4.96.2
> package/mutt: fix libgpgme static build
> board/raspberrypi: fix typo in comment
> package/netsnmp: fix musl build
> package/nmap: fix build with libressl >= 3.5.0
> package/gcc: remove leftover from legacy PowerPC patch
> package/samba4: security bump version to 4.18.8
> package/libcue: security bump to version 2.3.0
> package/go: security bump to version 1.20.10
> {linux, linux-headers}: bump 4.{14, 19}.x / 5.{4, 10, 15}.x / 6.{1, 5}.x series
> package/wireless-regdb: bump version to 2023.09.01
> package/python3: bump version to 3.11.6
> {linux, linux-headers}: bump 5.15.x / 6.{1, 5}.x series
> package/gstreamer1-editing-services: bump to version 1.22.6
> package/gst-omx: bump to version 1.22.6
> package/gst1-rtsp-vaapi: bump to version 1.22.6
> package/gst1-rtsp-server: bump to version 1.22.6
> package/gst1-python: bump to version 1.22.6
> package/gst1-libav: bump to version 1.22.6
> package/gst1-devtools: bump to version 1.22.6
> package/gst1-plugins-ugly: security bump to version 1.22.6
> package/gst1-plugins-bad: security bump to version 1.22.6
> package/gst1-plugins-good: security bump to version 1.22.6
> package/gst1-plugins-base: security bump to version 1.22.6
> package/gstreamer1: bump to version 1.22.6
> package/cups: add upstream security fix for CVE-2023-4504
> package/mbedtls: security bump to version 2.28.5
> package/mbedtls: bump to version 2.28.4
> package/mbedtls: bump to 2.28.3
> DEVELOPERS: add Thomas Petazzoni for nodejs
> package/exim: security bump version to 4.96.1
> package/efl: bump to version 1.26.3
> package/netsnmp: security bump to version 5.9.4
> package/sslh: add SSLH_CPE_ID_VENDOR
> package/gptfdisk: fix bug with util-linux 2.38
> package/libmodplug: use a full-length hash as version
> package/libmodplug: add a patch fixing cctype UB
> package/enlightenment: security bump to version 0.25.4
> package/wpewebkit: needs >= GCC 9
> package/Makefile.in: set --shuffle=none for MAKE1
> package/pkg-generic.mk: fix rule order for reinstall/rebuild/reconfigure
> package/tar: security bump to version 1.35
> package/go: fix installation
> package/pkg-utils.mk: break hardlinks in global {TARGET, HOST}_DIR on per-package build
> package/webkitgtk: require GCC 9 for the 2.40.x series
> package/linux-tools: fix SysV init script
> boot/at91bootstrap: disable PIE and stack-protector build flags
> package/rockchip-mali: fix hash of generated archive
> package/urandom-scripts: move seedrng init script to S01
> package/opkg-utils: actually install to target
> package/powertop: picutils is optional, not mandatory
> package/gnu-efi: disable on mips64el
> package/olsr: fix build with gpsd >= 3.25
> package/python-mako: add optional runtime dependency on python-babel
> package/python-mako: add optional runtime dependency on python-pygments
> package/python-mako: add missing dependency on python-markupsafe
> package/openblas: Add support for RISC-V architecture
> package/pipewire: fix typo in Kconfig comment
> package/go: cgo for the target needs the toolchain
> package/go: security bump to version 1.20.9
> package/go: security bump to version 1.20.8
> package/go: security bump to v1.20.7
> package/go: adjust Upstream header in patch
> package/go: fix go-bootstrap when parent dir contains invalid .git
> package/go-bootstrap-stage2: bump version to 1.19.11
> package/go: bump to version 1.20.6
> package/go: adjust comments
> package/go-bootstrap: split into two stages: go1.4 and go1.19.10
> package/{glibc, localedef}: security bump to version glibc-2.36-118-g22955ad85186ee05834e47e665056148ca07699c
> package/neon: drop patches
> package/libfastjson: security bump to version 0.99.9.1
> package/libvpx: Add upstream security patch to fix CVE-2023-5217
> package/libvpx: bump version to 1.13.0
> package/mosquitto: bump to version 2.0.18
> package/samba4: bump version to 4.18.7
> package/php: bump version to 8.2.11
> package/suricata: security bump to version 6.0.14
> package/librsvg: security bump to version 2.50.9
> unifdef: add missing license
> package/{glibc, localedef}: security bump to 2.36-117
> package/nodejs: fix parallel build further
> package/libyang: security bump to version 2.1.111
> package/bind: security bump to version 9.16.44
> {linux, linux-headers}: bump 4.{14, 19}.x / 5.{4, 10, 15}.x / 6.{1, 4}.x series
The deployment on dev channel should always be development. The change
came in from the main branch backmerge where the wrong merge strategy
has been used (the merge strategy "ort" along with option "ours" has
been used, instead of the "ours" merge strategy). And since the
deployment was a separate hunk, it resolved to the release branch.
This reverts commit 0ebcdcb9dc.
We only added verity support in HAOS 10.4. However, we currently have
an issue since HAOS 10.3 where certain Realtek network cards don't work
anymore (see issue #2630). For this systems, it won't be possible to
upgrade, even when using the console.
Only having two HAOS releases creates a rather "narrow" upgrade path
accross all boards. There could be more issues where this proves
problematic.
Currently we don't use any new feature of the verity format. Therefor
let's postpone the move to the new format for a couple of releases
for now.
This reverts commit 0ebcdcb9dc.
We only added verity support in HAOS 10.4. However, we currently have
an issue since HAOS 10.3 where certain Realtek network cards don't work
anymore (see issue #2630). For this systems, it won't be possible to
upgrade, even when using the console.
Only having two HAOS releases creates a rather "narrow" upgrade path
accross all boards. There could be more issues where this proves
problematic.
Currently we don't use any new feature of the verity format. Therefor
let's postpone the move to the new format for a couple of releases
for now.
With the move to Docker 23 containerd stores its metadata no longer
undernath the Docker data directory but at its default location at
/var/lib/containerd. Previously Docker passed a containerd configuration
toml file which explicitly set the metadata root underneath Docker's
data directory.
On Home Assistant OS, the new location /var/lib/containerd is on a tmpfs
file system. For unknown reasons, it seems that if containerd's root
directory is on a tmpfs this leads to significantly more syscalls and
hence CPU load.
Change the metadata location to be on the data partition again. Since
containerd is treated separately from Docker these days, use a new
root directory under /mnt/data for containerd as well. With this, the
CPU load of containerd is back to normal.
* Bump buildroot
* buildroot a1bdf74b19...f125c3e292 (1):
> package/containerd: add control for additional build tags
* Drop unnecessary containerd changes
Now that the snappshotter and the CRI plug-ins are disabled we don't
need to configure or disable them via configuration anymore. Drop the
unnecessary configs.
Move from the current plain format to the new verity bundle format. This
requires at least HAOS 10.4 to work. The Supervisor will make sure to
update to the latest minor release of the previous major release, so
updating will work in the regular use case.
* 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
This enables backlight support on these hosts, which is useful if
running HASS on an old laptop or tablet and you want to (e.g.) conserve
power by controlling the backlight.
* buildroot d6894cf55f...df5fccafd8 (3):
> package/docker-cli: bump version to v24.0.6
> package/docker-engine: bump version to v24.0.6
> package/containerd: bump to version 1.7.6
Currently `CONFIG_OVERLAY_FS_METACOPY` and
`CONFIG_OVERLAY_FS_REDIRECT_DIR` kernel options are enabled but not
preferred by Docker. The metadata copy feature is disabled by default,
and also not actively used by the overlayfs2 driver (see
2c3d1f7b4b).
So the metadata copy config is not really problematic per se. However,
it enables the redirect_dir feature. And a kernel which has the
redirect_dir feature compiled in also enables it by default. This
actually makes the overlayfs2 driver to fallback to naive diff, which
is, from what I understand, slower than the overlayfs native diff (see
also
49c3a7c4ba).
The Docker daemon is also reporting this on startup:
Not using native diff for overlay2, this may cause degraded performance
for building images: kernel has CONFIG_OVERLAY_FS_REDIRECT_DIR enabled
Currently `CONFIG_OVERLAY_FS_METACOPY` is enabled, and it also enables
`CONFIG_OVERLAY_FS_REDIRECT_DIR`. There was already a previous attempt
to disable the latter (see #2067).
Disable both configs explicitly until Docker is able to use them.
Respect quotes in the meta file. While at it, simplify version
validation as well.
Make sure development version is correctly set at build time.
While at it also simplify version check.
* Adjust Home Assistant versioning to prepare for new release strategy
With OS 11 we'll create rc pre-releases which will get directly pushed
to the beta channel. In contrast, release builds will get directly
pushed to the stable channel.
Similar to Home Assistant Core we'll create bump commits for all stable
and beta releases. This makes sure that the source code matches the
built binaries for all releases.
The development build will get a generated version. To avoid issues
with the new rc builds the dev build version will get injected on source
level now.
* Apply suggestions from code review
* Download latest stable Supervisor after device wipe
Currently we download the latest tag after a device wipe, which gives us
the latest Supervisor (which quite likely can be a development version).
Use the stable version file instead to get the tag to be used to
download the Supervisor.
* Delete potentially corrupted updater info
Use a single workflow file for releases and dev builds. This avoids
duplication and enhances the release builds with some of the recent
improvements (e.g. shared build container).
This essentially reverts #2380, making sure that Home Assistant OS uses
systemd's latest network naming scheme.
We stick to a certain naming scheme to make sure NetworkManager still
applies the network configuration (which is matched by network interface
name by default).
With Supervisor [PR #4476](https://github.com/home-assistant/supervisor/pull/4476)
NetworkManager uses udev path by default. With this we can safely enable
the new interface naming and NetworkManager will still apply the
configuration based on udev path correctly.
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.
It turns out that the way concurrency works in GitHub action doesn't
allow to queue up multiple pending jobs. As soon as a second job gets
pending, the previous pending jobs get cancelled. So this does not allow
to sequentially run all cache combine jobs as we hoped for.
Let's use a single download cache and per board build cache for now.
This combines all caches in a single cache to save space (assumption is
that quite some files are duplicated otherwise). With this we shouold
end up with 4 relevant cache files (build cache for each architecture
plus download cache).
Use more specific keys for GitHub Action caches to make sure we update
caches regularly. Also add board id to the downloads cache to get a
more specific cache file. This avoid redownloading large dependencies
of some boards.
Separate fetching the current release and loading the container image
into separate build steps. This allows to manually later the version
json file for testing.
Enable fully preemptible kernel (low-latency desktop) configuration for
Home Assistant. Home Assistant can be considered as a soft real-time
system, where a lower latency is preferred over throughput.
A few tests using the rt_test development add-on didn't show measurable
improvements, but this could be due to rather synthetic test.
Currently some platform use voluntary preemptible kernel, and some fully
preemptible. So besides improving latency, this also aims to synchronize
the settings across all platforms.
Also make sure that debugging is not enable as it can have high runtime
overhead according to Kconfig.
The BR2_GCC_ENABLE_LTO config used to enable LTO on compiler level. That
config symbol doesn't exist anymore. Instead, LTO is enabled by default
with GCC.
However, there is a new flag named BR2_ENABLE_LTO which enables LTO in
packages. So far it doesn't look like that packages we are using support
the flag, but that might get added in the feature. Opt-in already today.
* Determine git reference in prepare step
We can determin the git reference used once in the prepare step.
* Build HAOS builder in prepare step
Instead of building the build container multiple times, simply build it
once in the prepare step. This saves some GitHub Runner time (as we only
need to create the builder once).
* Drop per PR builds
Drop the per PR builds which are based on pull_request_target. These
make things more complicated with the recent changes requiring two
deployment approvals since we use the environment in for the prepare
and build job now. It will also interfere with future expansions.
We should consider readding the feature using `pull_request` and
subsequent `workflow_run` trigger, as suggested by
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/.
* Simplify board filter
In case a group with the same id as used outside the container already
exists, do not create a group inside the container.
It seems that GitHub Action runners started to use primary group id 999
which is the default group id used by the Docker daemon.
Home Assistant Green uses a SPI NOR flash storage. One can use dd to
write to the SPI NOR flash, but this is problematic if a unit has bad
blocks. Add MTD tools, specifically flashcp, to enable SPI NOR
flashing support.
Update U-Boot board configuration for Home Assistant Green. This moves
all Green specific board configuration into the U-Boot source code
patches. The "sf probe" command now picks up the correct SPI bus by
default.
* Initial commit of Home Assistant Green board support
* Add Home Assistant Green boot files
* HA Green board configs
* board/nabucasa: Unsupport rtc rk808
* Use odroid-m1 as Supervisor machine for now
* Green: linux: pmic: set set PWRON_LP_OFF_TIME 12s
* green: Update U-Boot to 2023.07.02
* green: supports usb boot
* green: uboot-boot.ush use rk3566-ha-green.dtb
* green: spinor supports uboot
* green: use U-Boot provided devtype as boot device type
* green: Fix polarity of power key
The power key is low active. Add patch to avoid accidential long press
being reported to user space.
* green: uboot: eeprom: add CONFIG_ENV_OVERWRITE
* green: uboot: eerprom: add mac read
* green: fix-cpufreq null issue
* green: board aliases ethernet0
* green: uboot mac set ethernet0
* green: uboot add serial-number read
* green: Update kernel 6.1.39
* green: add green to the build matrix
* green: fix 339d13 & 9b9416 can not boot from usb
* green: changfe sd mode, change led default state
* green: uboot add board.c to read eeprom info
* green: enable uboot to read eeprom info
* green: delete boot.scr read eeprom function
* green: change spl loader uboot order:sd-emmc-spi_nor
* green: serialnum change to 18 bytes
* green: Update kernel 6.1.43
* green: use hwrng support from ODROID-M1
* green: Use latest Rockchip BL31/DDR binaries
* change led_act polarity
* green: Disable watchdog
The watchdog on Green seems to not reliably reset the system. For now
disable the driver to avoid systemd making use of it.
* green: Update kernel 6.1.44
* green: Fix Supervisor Machine
Use odroid-m1 for now as Supervisor machine (used to download the
landing page).
* green: emmc use hs200 to increase speed
* green: use green as Supervisor machine
* green: Update kernel 6.1.45
* green: add Green to the kernel documentation
---------
Co-authored-by: Zhangqun Ming <north_sea@qq.com>
Co-authored-by: syan <syan.cham@gmail.com>
Use the official rkbin repository for Rockchip binaries. Use the
binaries from an older git hash which provide the very same binaries
(by hash). This makes sure we use the same DDR version as currently used
by the Hardkernel in their SPI flash bootloader (DDR v1.09).
* Including the RTW8821ce driver module to support Wifi on the KAMRUI AK1 PRO micro PC. It is a low-cost Intel Celeron N5105 that I think should work well for Home Assistant. However, it does not use Intel radios, it needs Realtek drivers.
* also need the firmware for the rtl8821ce
* Use hosted GitHub Action runners
Instead of using self-hosted runners use the hosted GitHub Action
runners. Officially the GitHub Action runners have a maximum of 14GB
free space available. However, a single Home Assistant OS build requires
up to 23GB (the ova board seems to require most because of the various
output image formats).
This PR adds some tricks to make use of the GitHub hosted GitHub Action
runners still, namely:
- Build and download cache is stored on /mnt which offers an additional
10GB of disk space
- Some tools/SDKs on the runner get removed from the root disk to free
up some disk space.
Other than that building on the hosted GitHub Action runners seems
straight forward. The build time is significantly longer (from ~30
minutes on the current AMD Ryzen 7950X build machine to 1 hours 30
minutes even with cache). But since we can build all boards in parallel
now, the overall build time will likely be shorted.
* Remove top-level release directory
The top-level release directory adds another copy of the images. This is
unnecessary for our release process now. Save the additional space and
time requirement. It comes with a slight downside for developers, but
also helps to save disk space on dev machines.
The chosen GitHub action sets MIME types correctly and allows glob
uploads. Also upload directly from the output directory. This way we can
remove the unnecessary copy to the release directory in the future.
Add patches for the hardware random number generator part of the
Rockchip RK3568. This avoids dbus-broker startup failure seen on some
Hardkernel ODROID-M1 devices due to lack of entropy.
On some platforms (it seems to be pronounced on Intel NUC systems)
Bluetooth advertisements suddenly stop after a short while. Currently
there are work arounds in place to restart the HCI controller to keep
receiving the advertisements.
Advertisements have been received fine with Linux 5.15. This change
reverts a commit which has been isolated to be the culprit.
In case a system takes a bit longer to boot (e.g. due to SWAP
initialization on first boot, especially on a system with lots of memory
and not very fast strage, e.g. an ODROID-M1 using an SD card) we might
time-out waiting for time synchronization before the time
synchronization service even got started. By ordering the
systemd-time-wait-sync.service after the network is online, the timeout
of this service should be started much later. With that the
systemd-time-wait-sync.service shouldn't timeout any longer.
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.
Many x86_64 tablets (e.g. Cherry View) use SDIO WiFi modules, this
enables the driver for a common one I've come across in the wild.
This module requires firmware from the following, which are already
enabled for this platform:
- BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX
- BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX_BT
fixes#2422
* Yellow: Always use mini-UART for Bluetooth
Unfortunately, the mini-UART device tree adjusts the alias for serial1,
which we need to make ttyAMA1 the Zigbee UART (UART4).
However, we can no simply adjust that overlay, as the overlays are not
built as part of the Buildroot build. Instead, they are directly copied
from Raspberry Pi's Firmware repostiory.
Instead of using device tree overlays, just apply the changes to our
Yellow specific device tree. To avoid that the device tree gets loaded
anyhow, we could adjust config.txt but that has complications on its
own. Since the overlay might be conflicting with the Yellow device tree
anyways, just remove all of them.
Note: The miniuart-bt.dtbo overlay won't be present, while config.txt
of upgraded instances still reference it. It seems that this doesn't
cause problems at boot time. Leaving the dtoverlay=miniuart-bt present
also allows user to downgrade in case needed.
* Avoid duplicating 98-rpi.conf
* Make it clearer that the image file needs to be renamed
- add information that the update was only successful if version 20230328 is visible.
* Update Documentation/boards/hardkernel/odroid-m1.md
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
* buildroot 8e1c933e7f...21edbd975f (4):
> package/docker-cli: bump version to v23.0.6
> package/docker-engine: bump version to v23.0.6
> package/containerd: Bump to containerd 1.6.21
> package/runc: bump to version 1.1.7
With U-Boot 2023.01 booting on Raspberry Pi 4 32-bit (at least with 4
or 8GB of memory) freezes when trying to enumerate USB devices. It seems
that the PCIe initialization partially fails, which causes the USB XHCI
initialization to fail.
It seems that a new restriction on viable addresses for PCIe
initialization causes the problem. Revert the offending commit to make
U-Boot properly detect USB devices again.
The new U-Boot 2023.01 requires an additional config which is missing
from the generic Raspberry Pi U-Boot configuration (see #2234). Add
it to the generic Raspberry Pi U-Boot configuration so Yellow as well as
other CM4 based systems can boot from NVMe SSD again.
* buildroot befb515cdb...ddc0ddca51 (4):
> package/docker-cli: bump version to v23.0.3
> package/docker-engine: security bump version to v23.0.3
> package/containerd: security bump to version 1.6.20
> package/runc: security bump to version v1.1.5
* 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.
* Add multiple routes support in NetworkManager
Support multiple routes to the same network learned via Router
Information Option. With this change, the kernel will have multiple
routing table entries to a given Thread network. The routes gateway
won't be updated with every new RIO any longer since every gateway
has its own entry.
* Enable IPv6 router reachability probing
Currently router reachability probing is disabled since HAOS enables
IPv6 forwarding and the necessary kernel options are not enabled. With
this change router reachability probing is enabled even though we are
a router on our own.
Note that Linux commit ea659e077528 ("[IPV6] ROUTE: Do not enable router
reachability probing in router mode.") by default disabled this
behavior. But since we are acting as a router as well as a host device,
we rather want this reachability probing.
See also: https://lore.kernel.org/netdev/b9182b02829b158d55acc53a0bcec1ed667b2668.1680000784.git.stefan@agner.ch/T/#u
* Fix swapfile creation for all memory sizes
In certain situation awk prints the swapfile size in scientific
notation. The script can't deal with that, in which case swap file
creation fails.
Use int to convert the number to an integer.
Since pages are 4k, also make sure swapsize is aligned to 4k blocks.
* Add info message
Drop PCIe hotplug since this causes network interfaces name changes
which aren't handled gracefully right now. People are left with no
network configuration.
By default systemd kills the service which causes an OOM. That make
sense for a typical service, however, for SSH we don't want this
behavior: The connection should continue, just the command which caused
OOM should be killed.
* 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.
* Avoid moving data to same device
When a data disk move is triggered when the data disk is already in use
the script currently renames that only data disk, rendering the system
unusable.
Don't continue if source and destination happens to be the same device.
* On failure rename to hassos-data-fail
The label hassos-data-failed is too long.
* 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.
By default ConditionFirstBoot is ankered to the presence of
/etc/machine-id. However, in our case /etc/machine-id is a bind mount,
which makes the first boot condition non-working.
Since machine-id is stored by the bootloader on HAOS, use the boot
loaders knowledge and pass the information to systemd.
* Add ODROID-M1 to documentation
While at it, also use the new writing style for all Hardkernel boards by
changing Odroid to ODROID.
* Add ODROID-M1 board specific documentation
* Add NVMe information
* Apply suggestions from code review
Co-authored-by: c0ffeeca7 <38767475+c0ffeeca7@users.noreply.github.com>
It seems that Raspberry Pi enabled Multi-Gen LRU by default. By my
testing, it performs worse in some situation. Add it by default for all
platforms, but disable it by default for now.
* Add ODROID-M1 board support
* Add Rockchip kernel config for ODROID-M1
Kernel defconfig for Rockchip is based on Armbian kernel defconfig
from config/kernel/linux-rk3568-odroid-edge.config (git hash
95c829f9e664).
* Add U-Boot/Kernel patches
* Add Rockchip blob support
Add package which provides Rockchip TPL and ATF firmware binaries.
* Use latest U-Boot for ODROID-M1
* Fix Rockchip blob support
* Update defconfig
* Use GPT by default
* Create uboot partition to support non-recovery boot
* Enable eMMC boot in U-Boot SPL
* Drop unnecessary mmc device selection
Distro boot already activates the right mmc device. The extra selection
seems to actually cause problems for eMMC boot.
* Make sure driver for eMMC is built-in
* Use odroid-m1 as Supervisor machine
* Add ODROID-M1 to CI pipeline and issue template
* Bump to Linux 6.1.16
* Add security library libseccomp
Enable libseccomp to activate seccomp support in HAOS. This will compile
systemd and Docker with seccomp support.
Note: Traditionally Supervisor required to disable seccomp. This seems
no longer to be the case with current Supervisor, but it needs further
testing. All containers started by Supervisor get currently started with
seccomp disabled.
* Enable seccomp in the kernel
Currently the only board supporting GPT partition table and SPL is the
ASUS Tinker board. Its Rockchip boot loader is stored at LBA 0x40 (64)
which is well past the last LBA of a regular GPT partition table which
is at LBA 33). Therefor a custom GPT main partition table location (via
sgdisk -j, --adjust-main-table=sector) is not necessary.
Technically we could copy anything after LBA 34 from the SPL image, but
since we don't support a board which needs that space for its SPL let's
stick with the well aligned Rockchip start at LBA 64.
Note: To preserve the layout we still add the SPL size to the regular
offset. Technically we could start the boot partition at LBA 16384, but
this would mean a different partition table compared to before and
different offset of subsequent partitions compared to other GPT
platforms.
* Support custom sized SPL/raw boot region
This is required for Rockchip which by default stores the U-Boot FIT
image at the 8MiB offset.
* Ignore shellcheck warning
The new systemd version v252 brings a new naming scheme, in particular
it seems that on device tree based systems (e.g. Raspberry Pis) the
Ethernet device name changes from eth0 to end0.
This breaks a previously made configuration.
Even worse, it seems that the default NetworkManager behavior is to only
configure a network device if there is no profile. But since profiles
are configured on a typical installation, NetworkManager doesn't bring
up any of the network interface, leaving the user stranded on an
unconnected system.
Ideally, we should have a plan how to migrate from one naming scheme to
the next. For now, just stick with the naming scheme HAOS 9.x has been
using.
The OTBR install scripts by default increases the net.core.optmem_max
ancillary buffer size to 64KiB to allow for a larger number of multicast
groups. Arch Linux as well recommends this size for high speed network
links.
* Update config for Buildroot 2023.02
* Use Buildroot's version of the rtl8821cu package
Buildroot provides a newer driver for the RTL8821CU based chipsets
provided by https://github.com/morrownr/8821cu-20210118.
* Pass argument when verifying partition table
This also avoids running into a segmentation fault in the current
version of sgdisk.
* Remove obsolte GRUB2/NetworkManager patches
* Bump buildroot
* buildroot 90aa1a6daa...4832525e6c (4596):
> package/runc: add support for CGroup device permission updates
> package/network-manager: fix build with -Dmodem_manager=false
> package/dbus-broker: bump to release 33
> package/iptables: Allow to use iptables with nf_tables backend
> package/brcmfmac_sdio-firmware-rpi: bump to latest version
> package/linux-firmware: Deploy fewer Intel WiFi 22000 series variants
> package/linux-firmware: Add more Intel WiFi 22000 series variants
> package/linux-firmware: Add Broadcom BNX2 firmware
> package/rpi-firmware: bump version to 1.20230106
> Update for 2023.02-rc2
* Use Ubuntu 22.04 for CI checks
* Bump xe-guest-utilities to 7.33.0
* Remove unnecessary shellcheck ignore for xe-guest-utilities
* Address new buildroot check-packages issues
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
* Linux: Update kernel 6.1.12
* Update generic_raw_uart to build with Linux 6.1
* Update Realtek rtl8821cu/rtl88x2bu to build with Linux 6.1
* Bump buildroot
* buildroot 43f82f01b9...90aa1a6daa (1):
> rtl8812au-aircrack-ng: bump to latest rev d98018
* Fix eq3_char_loop to build with Linux 6.1
* rtl8821cu: make sure -Werror is disabled for the kernel build
* generic_raw_uart: make sure -Werror is disabled for the kernel build
Replace Busybox ip command with the full version from the iproute2
package. This removes ~20KiB from Busybox, but adds ~685KiB for full
iproute2.
The main reason is to get full ip -6 route command support to debug
Thread related routing problems.
* 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>
Set 2022.02-haos as the default remote tracking branch. This should not
influence regular submodule updates/inits as they reference the git
hash tracked by the operating-system repository directly.
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
* Bump buildroot
* buildroot 215e54fe41...54eff73a8f (1):
> package/iptables: Allow to use iptables with nf_tables backend
* Use iptables with NFT backend
The powertop command built-in BusyBox uses old timer_stats proc API
which has been removed since Linux 4.11. Hence the command is not
useful on HAOS. Remove it.
The fq_codel network scheduler is the de-facto standard nowadays in most
distros. Systemd enables the scheduler by default if available. Make
sure all boards have the necessary kernel module activated.
The ODROID-XU4 is largely compatible with the ODROID-HC1. It seems that
the image used to work until recently, where a stable kernel update
broke access to the S-ATA disk.
Revert the offending stable kernel patch to fix S-ATA disk on
ODROID-HC1.
* Update outdated ui references in issue template
* Mention top right menu
* Remove health
* Remove health and fix directions
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Fix Docker key.json corruption check
Since /etc/docker does not get bind mounted anymore (see #2116),
key.json from the overlay partition is used directly.
* Use -e flag for jq to get useful exit code
The cgroup_enable parameter is a Raspberry Pi kernel specific kernel
parameter. Upstream based kernel do not have the parameter, and hence
do not do anything.
This gets rid of the following message during boot:
Unknown kernel command line parameters "cgroup_enable=memory", will be passed to user space.
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).
* RaspberryPi: Update kernel 5.15.61 - 1.20220830
* Add Yellow to the Raspberry Pi kernel update script
* Bump Yellow to kernel 5.15.61 - 1.20220830
Also drop the work around for the LED polarity as the new firmware
has been fixed.
* Explicitly select no kernel module compression
Home Assistant OS uses a compressed rootfs already, no compression for
kernel modules necessary.
* Bump buildroot
* buildroot d7e4c223e5...5468d36a26 (1):
> package/rpi-firmware: bump version to 1.20220830
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.
* Retry up to 3 times
By default, HAOS used to retry 3 times. That is still true for U-Boot
based boards. Apply the same logic for GRUB2 based systems for
consistency.
This can help to remedy intermittent internet/connectivity issuese.
Altough hacky, in practise it makes sense to give the newly installed OS
another go.
* Also apply to generic-aarch64
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.
* rpi4: Enable arm_boost=1 to unlock 1.8Ghz CPU
The official Raspberry Pi OS enables a "boosted" 1.8GHz
mode since their Debian bullseye based release [source]. This
commit brings this feature to HA OS.
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.
* buildroot 2083b57930...9dbf8d5e86 (3):
> package/brcmfmac_sdio-firmware-rpi: bump to latest version
> package/linux-firmware: Deploy fewer Intel WiFi 22000 series variants
> package/linux-firmware: bump version to 20220815
* 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.
* Move Bluetooth protocol configuration to hassos.config
Enable a couple of potential useful Bluetooth protocol drivers.
Also enable Bluetooth Network Encapsulation Protocol since the BlueZ
plug-in seems to be enabled.
* Drop OverlayFS configuration not liked by Docker
* Bump buildroot
* buildroot 0397d9c8f0...2ba3394abf (1):
> package/docker-engine: use kernel modules for extra network drivers
* Make IPv6 SIT tunnel driver a kernel module
This is what distributions seem to be doing too.
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
* buildroot 97287bbebf...0397d9c8f0 (5):
> package/docker-proxy: bump version to f6ccccb1c082
> package/containerd: security bump to 1.6.6
> package/docker-engine: bump to version 20.10.17
> package/docker-cli: bump to version 20.10.17
> package/runc: bump to version 1.1.3
* Load container images descending by size
Loading container images using docker load seems to require more space
at load time (which gets freed after loading). Loading the largest
container first avoids running out of space.
* 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
This makes the Red+Blue Button cause the boot loader to wipe start4.elf,
which is essential for the boot loader to boot from eMMC. With the file
missing, the Raspberry Pi firmware will continue its boot flow and boot
from USB host next. This allows to run the Home Assistant OS Installer
from a USB flash drive again.
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).
* chore: Set permissions for GitHub actions
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
* Remove global permissions which are set implicitly
With restrictive settings in the global GitHub Action permission settings
those permissions are given implicitly.
Co-authored-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
Co-authored-by: Joakim Sørensen <hi@ludeeus.dev>
Co-authored-by: Stefan Agner <stefan@agner.ch>
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/
* Add open-vm-tools to AArch64 for better VMware support (#1050)
* Bump buildroot
* buildroot 666868435d...de7aa15c65 (1):
> package/openvmtools: bump version to 11.3.5
For phyiscal hardware the default Power Button action has been disabled
to avoid accidentally power down the machine.
However, for virtual machine this method is often used to shutdown the
virtual machine gracefully. Use the regular power settings for virtual
machines.
* Use upstream Linux driver for Bluetooth on ASUS Tinker
* Drop unnecessary Bluetooth initialization systemd service
Bluetooth is now entirely handled by the kernel.
* Recreate defconfigs using savedefconfig target
Buildroot allows to generate minimal defconfigs using the savedefconfig
target. Regenerate all our configurations so they all look alive and are
minimalistc.
* Fix generic_aarch64_defconfig
* 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.
* Support firewall matching by pkttype
Matching by pkttype is required by the reference OTBR firewall script.
* Add additional Kernel configurations required for OpenThread.
It seems that the GitHub container registry sometimes returns 503
service unavailable temporarily ("Error fetching tags list: invalid status
code from registry 503"). Use skopeo's retry mechanism to try up to 5
times before failing.
Add VID/PID of some known problematic USB SSD controllers to USB storage
quirk list. This should make most USB SSD's work with Home Assistant OS
out-of-the box.
The Google Gasket driver has been removed from the main kernels staging
tree between 5.10 and 5.15 development window. Readd Google's
out-of-tree driver to continiue support Google Coral devices.
* Replace bluetooth-bcm43xx with pi-bluetooth Buildroot package
The new pi-bluetooth packages the scripts and systemd service from
the Raspberry distribution package directly:
https://github.com/RPi-Distro/pi-bluetooth
* Update to latest pi-bluetooth service files
* Update busybox configuration to 1.35.0
The new/deleted configurations are generated automatically, no actual
change in this patch.
* Enable busybox xxd command
The xxd tool is useful for conversion in scripts.
* Prevent start erros on Compute Module 4 without WiFi/Bluetooth
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.
* Enable wext and nl80211 drivers for wpa_supplicant for all devices
* Enable r8188eu module globally and add related firmware to all devices config
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Use anonymous Docker volume as build output
Use anonymous Docker volumes as build output. This makes sure
every build is using a clean output directory.
This aligns with what we used to have in Barebox. Most of the time the
user is not expected to make a choice, so keeping the timeout short is
sensible.
* 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 tempio host package
tempio is a template helper using Go's template engine and sprig
functions.
* Use tempio to generate rauc manifest
* Use tempio to generate rauc system.conf
This reverts commit ff07728fa3.
Removing the .git file from the git submodule is problematic when
updating buildroot: Files deleted stay present in the buildroot
directory (since their origin is no longer known).
The workaround has been introduced to allow building non-git submodule
releases (rel-6) on the same runners. Since rel-7 uses git submodule and
we stay with git submodule for the forseeable future, remove this work
around.
* Drop unnecessary device tree utilities
They have been used for Barebox which uses device tree to configure the
state storage and its location. With the change to GRUB the tools are no
longer required.
* Determine manual GRUB update depending on installed tools
Manually update the GRUB environment if no grub environment tools are
installed. This makes a upgrade work even after a previous downgrade (in
that case a grubenv file might still be present in the UEFI ESP).
* Add generic-aarch64 to the list of Kernels
* Bump buildroot
* buildroot 8bbb32c16a...962ff8c0d4 (1):
> package/rtl8812au-aircrack-ng: bump version to 3a6402e
* Fix kernel version for Raspberry Pi kernel based boards
* Linux: Update kernel 5.15.25
Use highest available kernel version in Buildroot 2021.08 (5.13)
* Update Hardkernel patches to Linux 5.15
* Update generic-x86-64/ova kernel config/patches for 5.15
* Drop Intel e1000e Sourceforge driver
The driver has been discontinued sometime last year. The main reason the
out-of-tree kernel has been enabled was for support for the i219-V
network chips which meanwhile are supported in mainline.
* Use shell functions for install hooks
* Use post-install hook to initialize GRUB2 bootloader env
Unfortunately the boot name to be updated (RAUC_SLOT_BOOTNAME) is not
available when updating the "boot" slot. Instead, initialize the boot
slot in a kernel post-install slot.
* Fix migration from Barebox GRUB
Create GRUB env which defaults to the boot slot we are updating to. This
makes sure that the newly installed OS version will be booted on next
reboot even if installed on boot slot B.
* 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.
To make HDMI CEC work, we have to compile MESON_DRM as a module
(see #1717). However, this essentially reverts #1347, which fixed the
reboot problem by compiling the driver into the kernel.
Hence we need to reintroduce the earlier fix from #1345, which reverts
the offending commit causing the reboot problem.
* Fix enable USB host mode kernel patch
Update to a new patch which applies the device tree change such that the
USB controller actually gets enabled.
* Update Home Assistant Yellow board config
Update config to match changes which have been made to other baords as
well.
* Rename Home Assistant Amber to Yellow
Rename the board from "amber" to "yellow" as Home Assistant Yellow is
the official name now.
* Add Home Assistant Yellow to the build matrix
* ODROID XU4: Update U-Boot on eMMC boot partition
Update the U-Boot on the eMMC boot partition if present. Only write the
first megabyte as the eMMC boot partition might be smaller than the SPL
image and only the first megabyte is occupied by FW/BL1/BL2/TZSW (see
https://wiki.odroid.com/odroid-xu4/software/partition_table#tab__odroid-xu341).
* Bump buildroot
* buildroot 907739ed48...4c6c8fb767 (1):
> package/rpi-firmware: bump version to 71bd3109
* RaspberryPi: Update kernel 5.10.63 - oldstable_20211201
* Add Raspberry Pi Zero 2 W device tree
* Use LSI Logic SCSI controller in vmdk descriptor as well
For some reason, the vmdk disk format's descriptor contains the
controller type as well. By default, qemu-img sets it to "ide", which
seems not optimal especially for VMware's ESXi. Set adapter type to
commonly supported "lsilogic".
* Move ova image generation to hdd-image.sh
* Check if Busybox supports oflag
It seems that Busybox' dd shipped with OS release 5 and earlier does not
support oflag. Check if the flag is supported before making use of it.
* Exit if a command in the update scripts returns an error
This makes sure that the update isn't marked as successful in case there
is an error in the update script.
* Devices description update
Updating the list of supported devices according to https://www.home-assistant.io/installation/
* Intel NUC -> Generic x86-64 (e.g. Intel NUC)
* Remove unsupported Raspberry Pi and Raspberry Pi Zero
* Use OpenSSL to generate OVA manifest file (#826)
It seems that sha256sum adds a space after the hash algorithm which
causes "Invalid OVF checksum algorithm" on certain VMware virtualization
products.
Using OpenSSL avoids the space and makes the manifest file compatible
wiht VMware products.
* Use Buildroot provided OpenSSL binary
* Use SCSI controller by default
Make sure to overwrite existing files on upload. This allows to trigger
rebuilds and have the latest builds on the os-builds server.
Note: When using GitHub Actions, the release/ directory is cleared at
the beginning (by the checkout action, which has the clean option set
by default which also causes files in .gitignore to be deleted).
* Avoid race condition when fetching containers during build
So far only a single builder was active for each architecture. This
toghether with the naming scheme to include architecture/machine name
made sure that an image could only be fetched or used by a single
builder.
However, since most systems are now aarch64, multiple runners are now
active for a single architecture. This makes it necessary to lock
fetching/coping of container images to avoid race conditions.
Use rtl8812au driver provided by buildroot. This uses a newer verison of
the v5.6.4.2 branch which works with newer kernel and seems to be the
recommended branch.
Note: It seems that our buildroot package currently fails to properly
deploy the 88XXau.ko kernel module. Instead of fixing our version, just
move to the buildroot version.
* Update Linux kernel patches for Home Assistant Amber
Fix user LED polarity. Also rebase the patchset ontop of the Raspberry Pi
kernel 1.20211029.
* Add RTC as well
Can be found in the [Configuration panel -> Info](https://my.home-assistant.io/redirect/info/). It is listed as the `Board` value.
Can be found in [Settings -> System -> Repairs -> System Information](https://my.home-assistant.io/redirect/system_health/). It is listed as the `Board` value.
[](https://my.home-assistant.io/redirect/info/)
[](https://my.home-assistant.io/redirect/system_health/)
- type:input
validations:
required:true
@@ -48,7 +52,7 @@ body:
label:What version of Home Assistant Operating System is installed?
placeholder:"6.6"
description:>
Can be found in the [Configuration panel -> Info](https://my.home-assistant.io/redirect/info/). It is listed as the `Host Operating System` value.
Can be found in [Settings -> System -> Repairs -> System Information (top right menu)](https://my.home-assistant.io/redirect/system_health/). It is listed as the `Host Operating System` value.
- type:dropdown
validations:
required:true
@@ -76,7 +80,8 @@ body:
attributes:
label:Anything in the Supervisor logs that might be useful for us?
description:>
Supervisor Logs can be found under [Supervisor -> System](https://my.home-assistant.io/redirect/supervisor_logs/), then choose Log Provider `Supervisor`.
Supervisor Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/)
then choose `Supervisor` in the top right.
[](https://my.home-assistant.io/redirect/supervisor_logs/)
render:txt
@@ -86,16 +91,19 @@ body:
attributes:
label:Anything in the Host logs that might be useful for us?
description:>
Supervisor Logs can be found under [Supervisor -> System](https://my.home-assistant.io/redirect/supervisor_logs/), then choose Log Provider `Host`.
Host Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/)
then choose `Host` in the top right.
render:txt
- type:textarea
attributes:
label:System Health information
label:System information
description:>
**Optional** Copy the full System Health in this text area.
Can be found in the [Configuration panel -> Info](https://my.home-assistant.io/redirect/info/).
Use the copy icon on top right and choose `For GitHub`.
System information can be found in [Settings -> System -> Repairs -> System Information (top right menu)](https://my.home-assistant.io/redirect/system_health/),
Click the copy button at the bottom of the pop-up and paste it here.
[](https://my.home-assistant.io/redirect/system_health/)
- Pi 4 Model B (1 GB, 2 GB and 4 GB model) 64-bit (recommended)
- Pi 3 Model B and B+ 32-bit
- Pi 3 Model B and B+ 64-bit (recommended)
-Pi 2 (not recommended)
- Pi Zero-W (not recommended)
- Pi (not recommended)
- Pi 4 Model B ([1 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-1gb), [2 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-2gb), [4 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-4gb) and [8 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-8gb) model) 32-bit or 64-bit (recommended)
-[Pi 3 Model B](https://www.raspberrypi.com/products/raspberry-pi-3-model-b/) and [B+](https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/) 32-bit or 64-bit (recommended)
Odroid-C4 support is based heavily on the Odroid-C2 and N2 configurations. Given the similarity of the SoCs, as well as the comparable level of support in the Linux kernel, the C4 should hopefully present few surprises. However, Home Assistant support should be regarded as experimental.
ODROID-C4 support is based heavily on the Odroid-C2 and N2 configurations. Given the similarity of the SoCs, as well as the comparable level of support in the Linux kernel, the C4 should hopefully present few surprises. However, Home Assistant support should be regarded as experimental.
Please also refer to the documentation pages for the [Odroid-C2](./odroid-c2.md) and [Odroid-N2](./odroid-n2.md), as some of that information may apply to the C4 as well.
Please also refer to the documentation pages for the [ODROID-C2](./odroid-c2.md) and [Odroid-N2](./odroid-n2.md), as some of that information may apply to the C4 as well.
Common C4 issues that have been specifically tested and appear to be working:
| Raspberry Pi 4 B |2019 | yes* | [rpi4](../../../buildroot-external/configs/rpi4_defconfig) / [rpi4_64](../../../buildroot-external/configs/rpi4_64_defconfig) |
\*1,2 and 4 GiB versions of the Raspberry Pi 4 B are supported. Support for the 8 GiB version is coming soon is part of #740.
## Limitation 64bit
The 64bit version is under development by RPi-Team. It work very nice but it could have some impacts. Actual we see that the SDcard access with ext4 are a bit slower than on 32bit.
| Raspberry Pi 4 B |2019 | yes | [rpi4](../../../buildroot-external/configs/rpi4_defconfig) / [rpi4_64](../../../buildroot-external/configs/rpi4_64_defconfig) |
- The `timesyncd.conf` file allow you to set different NTP servers. HassOS won't boot without correct working time servers!
- The `hassos-*.raucb` file is a firmware OTA update which will be installed. These can be found on on the [release][hassos-release] page.
You can put this USB stick into the device and it will be read on startup and files written to the correct places. You can also trigger this process later over the
API/UI or by calling `systemctl restart hassos-config` on the host. *The USB Stick just needs to be inserted to the device during this setup process and can be disconnected afterwards.*
Text files that are on USB stick must have Unix (LF) end of line characters. If you create USB stick on Windows machine, be sure to use Notepad++, Visual Studio Code or any other editor, that supports different line endings. In Notepad++ LF EOL can be enabled with setting `Edit -> EOL Conversion -> Unix (LF)`.
You can put this USB stick into the device and it will be read on startup and files written to the correct places. You can also trigger this process later using `ha os import` from the CLI or by calling `systemctl restart hassos-config` on the OS shell. *The USB Stick just needs to be inserted to the device during this setup process and can be removed afterwards.*
@@ -128,6 +128,14 @@ profile using DHCP, use the following commands on the host console:
Home Assistant OS will recreate the default connection profile during boot.
### Enabling Wi-Fi
Wi-Fi is discouraged for reliability reasons. However, if you still prefer to use Wi-Fi, you can us the `ha network` command to set up Wi-Fi (example for a Raspberry Pi 4, check `ha network info` to check if your board supports Wi-Fi and the name of the Wi-Fi device):
```bash
ha network update wlan0 --ipv4-method auto --wifi-auth wpa-psk --wifi-mode infrastructure --wifi-ssid "MY-SSID" --wifi-psk MY_PASS
````
### Powersave
If you have trouble with powersave then apply the following changes:
@@ -180,6 +188,6 @@ If you now view the default connection `cat /etc/NetworkManager/system-connectio
Doing a `nmcli con reload` does not always work, so restart the virtual machine or the physical system.
Home Assistant Operating System (formerly HassOS) is a Linux based operating system optimized to host [Home Assistant](https://www.home-assistant.io) and its [Add-ons](https://www.home-assistant.io/addons/).
Home Assistant Operating System uses Docker as Container engine. It by default deploys the Home Assistant Supervisor as a container. Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers. Home Assistant Operating System is **not** based on a regular Linux distribution like Ubuntu. It is built using [Buildroot](https://buildroot.org/) and it is optimized to run Home Assistant. It targets single board compute (SBC) devices like the Raspberry Pi or ODROID but also supports x86-64 systems with UEFI.
Home Assistant Operating System uses Docker as its container engine. By default it deploys the Home Assistant Supervisor as a container. Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers. Home Assistant Operating System is **not** based on a regular Linux distribution like Ubuntu. It is built using [Buildroot](https://buildroot.org/) and it is optimized to run Home Assistant. It targets single board compute (SBC) devices like the Raspberry Pi or ODROID but also supports x86-64 systems with UEFI.
## Features
@@ -16,8 +16,8 @@ Home Assistant Operating System uses Docker as Container engine. It by default d
- Raspberry Pi
- Hardkernel ODROID
- Intel NUC
- Asus Tinker Board
- Generic x86-64 (e.g. Intel NUC)
- Virtual appliances
See the full list and specific models [here](./Documentation/boards/README.md)
@@ -55,4 +55,4 @@ The Home Assistant Operating System documentation can be found on the [Home Assi
The Development build GitHub Action Workflow is a manually triggered workflow
which creates Home Assistant OS development builds. The development builds are
available at [os-builds.home-assistant.io](https://os-builds.home-assistant.io/).
available at [https://os-artifacts.home-assistant.io/index.html](https://os-artifacts.home-assistant.io/index.html).
@@ -81,5 +82,5 @@ index 831053aa6dff..5988dc5f34d0 100644
pinctrl-0 = <&pwm_ao_d_e_pins>;
pinctrl-names = "default";
--
2.25.1
2.39.1
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.