The TCPMSS target module for iptables was enabled in some kernel defconfigs but
not for all targets. It is used e.g. in default config of @bigmoby's WireGuard
Client add-on. Enable it globally in the HAOS kernel config to make sure it's
always present.
Fixes#3730
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.
Hailo modules are usable also in other generic targets, so enable them also on
generic x86 and ARM targets. Runtime tested only on x86-64 (Beelink with Intel
N100).
The PCIe card from the RPi AI Kit (and probably other M.2 cards using the
Hailo-8 chip) can be used on Yellow - the driver initializes correctly and
creates a /dev/hailo0 device on Yellow both with CM4 and CM5.
* Add HA Yellow image to RPi Imager index update action
Update the action to also bump HA Yellow image added in
home-assistant/version#402.
* Sync image name with the current JSON PR
Instead of using in-tree module on RPi 5, build it as a module from the
original sources. This will give us better control over the version used and
will also allow us for easier way to add the module to other platforms.
This also makes 017d172 unnecessary anymore.
* buildroot c65b0306bb...b2077df873 (1):
> package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e
Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API
which uses the DUMP_OBSS feature for channel selection. If it's not preset, it
results in drivers reporting errors, e.g.:
brcmf_set_channel: set chanspec 0xd099 fail, reason -52
The RPi OS firmware was updated but the package we use for this firmware
contains an old version that lacks this support. Update to latest version
synced from RPi upstream to fix the issues. The root cause is explained in [1]
by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the
errors go away.
[1] https://github.com/raspberrypi/linux/issues/6049#issuecomment-2485431104Fixes#3367
With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
(cherry picked from commit 9d643edb54)
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
(cherry picked from commit c514d6b482)
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
(cherry picked from commit 489de0b2fb)
With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
(cherry picked from commit d57e507764)
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
(cherry picked from commit b288cd212a)
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
(cherry picked from commit 98ac7f0170)
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
Add Hailo-8 firmware binary for Rasperry Pi AI accelerators. The version needs
to be determined from the Git history of the kernel sources, as the driver
source code is included in the RPi downstream kernel and the version string
can't be found in the code directly.
Fixes#3663
* Add Makefile variable for Supervisor channel
Allow to set the release channel pre-installed Home Assistant components
like Supervisor and add-on are fetched from. This channel is then also
used at runtime.
* Use choice instead of string variable
* Fix channel in Supervisor updater.json config
* Add newlines
As stated in the docs [1], post-install hook is not executed if the slot
already has an install hook defined. Merge the post-install hook with the
install hook to fix CM5 migration for Yellow.
[1] https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
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.
* Move RPi U-Boot patches to version-specific directory
We will need to use different series for 2024.10 which would be used as the
base for CM5 support.
* Remove common.h include from the fileenv cmd
It doesn't seem to be used and common.h has been removed in newer U-Boot.
* Use U-Boot 2024.10 with BCM2712 PCIe patches for Yellow
Use rebased patchset from v2024.01 with the first patch removed. Add patches
needed for PCIe initialization and use rpi_arm64_defconfig as the base config
for both CM4 and CM5.
* Add device tree for CM5 on HA Yellow and adjust config
Add device tree definition based on the CM5 device tree with BCM2712D0 changes
applied, and add nodes required for the on-board peripherals of Yellow.
Currently the difference in serial numbering still requires either changes in
this device tree, or userspace changes to create correct symlinks to make HA
configuration directly compatible with CM4 on Yellow.
* Add config.txt migration for conditional device_tree options
* Fix typos and minor issues found by CodeRabbit
* RaspberryPi: Update kernel to 6.6.51 - stable_20241008
* Update rpi-firmware to version for kernel 6.6.51
* buildroot 2ffac68a74...19027bc796 (1):
> package/rpi-firmware: bump to version 1.20241008 for kernel 6.6.51
Guest agent doesn't start because if HyperV Enlightenments are enabled, the
virtualization gets detected incorrectly. Backport Systemd patch that fixes the
detection, allowing the guest-agent service to meet its dependencies.
This patch should be no longer needed after update of Systemd to v256, or in
case the patch gets eventually backported to the v254 stable branch.
Fixes#3565
* 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
If the system fails to boot, some kernel messages may not be shown before the
system fully boots. Enable the debug option for rescue shell options to have an
easy way to see those without modifying GRUB options. This will increase log
verbosity and turn on debug logging for Systemd as well [1].
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.html#debug
Bump labgrid to latest release. None of the changes require adjustments in the
tests. Remove pytest from requirements.txt, it's not needed anymore, so let pip
to resolve the correct (latest) version from labgrid's dependencies. With these
new dependencies, previous DeprecationWarnings on Python 3.12 are gone now.
* Update Docker to v27.2.0
Update Docker and containerd to latest supported version.
* buildroot a2c10a16a0...c68e03d96b (3):
> package/containerd: bump version to v1.7.21
> package/docker-cli: bump version to v27.2.0
> package/docker-engine: bump version to v27.2.0
* package/hassio: update DinD container to v27.2
If an attempt to access R2 artifacts is made before the files exist, the 404
reply gets cached and it's not possible to access the file after it's been
created without purging the cache, essentially doing a cache poisoning for
future build artifacts. To avoid it, list all files that have been created by
the build and call the purge cache API.
As there's a limit for number of files that can be purged in a single API call
[1], the GNU split utility is used to split intermediary list of files to
chunks of 30 URLs, which is then converted to a JSON array and passed to the
curl command.
[1] https://developers.cloudflare.com/api/operations/zone-purge#purge-cached-content-by-url
HP t520 have been reported to have the same issues as Atom boards with bad UEFI
firmware that doesn't work well with the new EFI loader used since GRUB 2.12.
Apply the patch to use legacy loader for its CPU ID as well.
Fixes#3557
Fix AX210 firmware files, this time for real. In #3549 we still had only
ucode and pnvm files for AX211, AX210 was still missing the pnvm file,
because its ucode was provided through IWLWIFI_22000 without appropriate
pnvm file. Both AX210 and AX211 firmwares are now installed with
IWLWIFI_6E which includes both pnvm and ucode files.
Also some firmwares which are not used by the current kernel can be
removed, because the kernel always only loads the most recent one.
* buildroot 01188d9c38...a2c10a16a0 (2):
> Revert "package/linux-firmware: exclude some files from compression"
> package/linux-firmware: fix AX210 support, stick to latest supported ucode API, reorganize the split
Fixes#3477
Since updating to Buildroot 2024.02, the iwlwifi loads a different version of
firmware for Intel AX cards (reported on AX210) which also needs the pnvm file.
However, unlike firmwares, the load method is different and the driver can't
load a compressed file. Disable compression for all .pnvm files to fix this.
* buildroot baa16784d2...55be56d521 (1):
> package/linux-firmware: exclude some files from compression
Fixes#3477
(cherry picked from commit d3a43a4ca4)
Since updating to Buildroot 2024.02, the iwlwifi loads a different version of
firmware for Intel AX cards (reported on AX210) which also needs the pnvm file.
However, unlike firmwares, the load method is different and the driver can't
load a compressed file. Disable compression for all .pnvm files to fix this.
* buildroot baa16784d2...55be56d521 (1):
> package/linux-firmware: exclude some files from compression
Fixes#3477
With #3523 as inspiration, it might be useful to wait for buttons to be
released, e.g. in case when they become stuck. Also indicate the button
operation (wipe, boot files removal, UMS) has been handled by turning on the
yellow LED.
* Improve LED naming in U-Boot DTS
Port Stefan's patch from Linux patchset to U-Boot.
* Implement device wipe using the hardware button on Green
Unlike Yellow, Green doesn't have a way to easily wipe the device, e.g. if the
user forgets the password - in that case the only option is to use a microSD
card and reflash the system. Fortunately, Green has a hardware button wired to
the PMIC chip which exposes the button state in one of the registers. Read this
value in U-Boot and decide if cmdline flag for device wipe should be set - same
as we do on Yellow.
Also enable LED driver and command in U-Boot. In the current implementation, if
the button is held for ~5 seconds when plugging in the device (this time
includes DDR training, SPL, etc.), the yellow LED turns solid to indicate wipe
is about the start. When the Linux kernel starts, the kernel LED driver takes
over and starts blinking in heartbeat pattern. Because it takes a while to load
the kernel, the LED stays solid for 2-3 seconds, which should be enough to
recognize it was acknowledged.
* Wait for button to be released before wiping
Enable NTFS and exFAT drivers, as they're not in defconfigs of all platforms and may be useful when mounting removable drives.
Fixes#2723
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
With default console on HDMI (tty0), we lost the console on the serial port. It
may be useful for debugging, let's enable it for new installs with the same
speed as bootloader (to avoid the need for baud rate switching).
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in
the original patch series we took inspiration from that HS200 works more
reliably, so enable it in Green's defconfig by amending the patch.
(cherry picked from commit 0452965fb0)
While mksquashfs uses this value by default, Genimage's default is 4K. This is
far too low value and results in slower kernel load, especially on embedded
boards with a flash drive. Explicitly set it to 128K to generate same images as
in pre-genimage builds.
(cherry picked from commit edba18f6c4)
We previously reverted the bump because we were unsure where the eMMC issues
are coming from. Now we know some of them were caused by incompatible eMMCs
then never worked from the beggining, and attempt to fix them (by changing the
frequency) caused some other side effects. Bump U-Boot back to the version used
generally and continue from there.
(cherry picked from commit 50a0062ee6)
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in
the original patch series we took inspiration from that HS200 works more
reliably, so enable it in Green's defconfig by amending the patch.
While mksquashfs uses this value by default, Genimage's default is 4K. This is
far too low value and results in slower kernel load, especially on embedded
boards with a flash drive. Explicitly set it to 128K to generate same images as
in pre-genimage builds.
We previously reverted the bump because we were unsure where the eMMC issues
are coming from. Now we know some of them were caused by incompatible eMMCs
then never worked from the beggining, and attempt to fix them (by changing the
frequency) caused some other side effects. Bump U-Boot back to the version used
generally and continue from there.
* add Documentation category
* add Dependencies (to easily filter them out if not needed in changelog)
* adjust the order a bit to have user-facing changes first
* Test landing page is reachable without internet connection
Add test that checks user is able to access the landing page even when HAOS has
no internet connection. We still need some sort of outgoing connectivity, so
outgoing connection attempts don't end up with "network is unreachable". To
simulate this, restricted network is created for the QEMU instance used in the
test, and when everything is started, unresponsive default gateway is added.
This intents to test regression that was fixed by
home-assistant/supervisor#5204, Supervisor 2024.7.0+ is thus needed for this
test to pass.
* Bump requirements for tests
* Use GRUB2 legacy loader only on some Intel Atom boards specifically
Previous revert of GRUB2 change that introduced usage of the generic EFI loader
for all x86 boards in #3324 caused regressions, the one confirmed is #3348.
This commit adds a specific patch that identifies the broken platforms based
on SMBIOS data gathered in #3305 and falls back to the legacy loader there.
Tested on Intel D525MW (falls back) and QEMU (no fallback).
* Enable GRUB's smbios module
Having smbios command in GRUB can help in future debugging, e.g. to add more
CPUs that should use the linux loader fallback.
Genimage sets the first usable LBA to the offset of the first partition. While
it shouldn't be an issue in theory, Windows may do some nasty things with the
GPT header afterwards which breaks the Raspberry Pi bootloader, manifesting as
Before purpose of this behavior is clarified in [1], add a downstream patch
that sets the first usable LBA back to 34, which was the value that was used
before migrating to Genimage in #3388. Since changing this value (hopefully)
doesn't have any other consequences, and the images now should be closer to
pre-genimage builds, no more side-effects are expected from this change.
[1] https://www.github.com/pengutronix/genimage/issues/262Fixes#3437
Rockchip config fragment had EROFS compression explicitly disabled. Remove that
option and also remove the EROFS one, as it's already set in common config.
Reduce verbosity from deactivated Docker mounts, triggered by the Docker
healthcheck. These messages do not carry any value for us and logs supplied by
users are often spammed mostly with these. Moreover, they sometimes cause
confusion that something is wrong, see for example #3021.
Unfortunately, it's not possible to use LogFilterPatterns= here, because it's
not applied to these messages, as explicitly said in the docs:
Filtering is based on the unit for which LogFilterPatterns= is defined
meaning log messages coming from systemd(1) about the unit are not taken
into account.
runc 1.2.0 supposedly should fix this, but it's unclear when it would be
available, so let's stick to this solution (reducing verbosity from debug to
notice for all units `run-docker-*.mount`) for the time being.
* Use name.sh functions for paths in genimage
Paths for images generated outside of genimage were not used in genimage
definitions. Use them as the single source of truth.
Images generated by genimage itself (e.g. kernel.img) don't need to use those
functions, so remove the unused ones.
* Use EROFS instead of SquashFS for root FS
* Enabled EROFS in common kernel fragment
* RootFS image switched to EROFS with options to get decent compression
* rootfstype removed from kernel command line
* Get size of correct FS image in GH build summary
While not as bad as in 87a6c84, because the grubenv already exists in the
image, RAUC still complains about missing ORDER on the very first boot on
aarch64. Populate the environment in the same way as we do for other GRUB
platforms.
With upgrade path enforced in standard HAOS upgrade procedure, we don't need to
keep some old code anymore. This means that upgrade from some very old HAOS
version (pre-8.0) to HAOS 13+ will fail in the install-check hook but this is
rather desirable.
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.
On the very first boot, grubenv doesn't exist and loading and saving it
silently fails. However, it is later created by the hassos-persists script and
the missing information are added by grub.cfg on the next boot. As the
consequence, when RAUC tries to get information from grubenv on the first boot,
ORDER variable is missing and the slot is reported as bad.
Fixes#3376
We still face occasional build errors when fetching from the Docker registry
fails and is not retried with the Skopeo's built-in retry mechanism that was
enabled in #1866. This happens on some network failures, or when premature EOF
is returned when fetching the HTTP data. Seems we're not the only ones having
such issues [1].
To workaround this, add a generic retry shell function that simply retries when
the command ends with a non-zero status, no matter what was the actual cause of
the error.
[1] https://www.github.com/containers/common/issues/654
Very often we have to ask for further details about the hardware that HAOS is
running on. Add a required field that asks for these details - in the end it
should't complicate the form a lot and might result in faster turnaround of
resolving the issues.
Also adjust the question about the upgrade and swap the order (people often
don't care and keep the pre-selected value).
When Green starts, there is an error indicating the MMC write failed when
saving the bootstate:
storing env...
MMC write: dev # 0, block # 1214464, count 64 ... mmc write failed 0 blocks written: ERROR
This results in the boot count not being updated properly if the boot fails.
Seems to be a known issue for this platform, disabling the DDR52 mode (which is
the same what upstream does for other RK356x boards [1]) fixes the issues and
the bootstate is updated correctly.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20240204205312.2342868-2-jonas@kwiboo.se/
As we don't have proper solution for #3319 and #3351 yet, revert to
previous U-Boot which was proven working. This is intended as a
workaround but as there's nothing in the latest U-Boot that will be
really missed on N2, we can stay on the older version for the time
being.
This also means reverting the "40 MHz hack" back to the 24 MHz one.
Since this patch only applies to N2 (meson gx), it can stay along the
common hardkernel uboot patches.
The compression is necessary for successful generic-x86-64 build.
* buildroot 770f939463...b9520eedc6 (1):
> package/linux-firmware: fix compression after bad merge
* Bump buildroot to 2024.02.3
* buildroot 691077e577...770f939463 (1):
> Merge tag '2024.02.3' into 2024.02.x-haos
* package/hassio: update dind to version 26.0 used in current buildroot
* Use Genimage for declarative image layout instead of s[fg]disk and dd
* Change partition type to hybrid for M1, M1S and Green
This is what it really is, so just make sure only one "fix" function is
called.
* Change efi BOOT_SYS to gpt
There is no reason to have separate efi and boot sys, since all boards
that use efi also use grub as the loader.
* Change BOOT_SYS to more explanatory PARTITION_TABLE_TYPE
* Add units to DISK_SIZE
* Add forced-primary patch and use it in MBR images
* Avoid disabling SC2155, remove old comments
The preferred console (which is used for printing the systemd boot log)
is the last one specified in the cmdline boot arguments. Make sure it is
always tty0, i.e. the first graphical console.
In some places tty1 was used - change it to tty0 which is commonly used,
and in HAOS points to tty1 anyway.
The only exception is the Yellow, which doesn't have an HDMI port, so
the serial console is used as the preferred one instead.
For ASUS Tinker, use a versioned cmdline.txt file instead of in-place
generating it in the post-build hook.
* RaspberryPi: Update kernel to 6.6.31 - stable_20240529
* Unify Linux patches after RPi update to non-conflicting 6.6.31
* Bump buildroot to update rpi-firmware
* buildroot 9af2384782...691077e577 (1):
> package/rpi-firmware: bump to version 1.20240529 for kernel 6.6.31
* Reintroduce IPv6 reachability probe patch for RPi lost after refactoring
In #3384 we moved the patches around, which results in version-specific
patches not applied for RPi linux-custom build. Copy the missing IPv6
reachability probe patch to the RPi patches directory.
* Only copy IPv6 reachability probe patch to top-level linux patches
Instead of copying the patch to RPi directory and renumbering the
patches, only copy it upper level so it's applied for all linux versions
other than 6.6.31.
* Linux: Update kernel to 6.6.31
* https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.31
* Update patch workarounding Z-Wave.me USB issues
Linux commit 480c3abbba36628dab063b9ca218bb28090e5b46 changed code that
is reverted by the patch. Use a version-specific patch directory again
for upstream Linux patches before RPi kernel is updated to 6.6.31+.
ODROID M1, M1S and Green historically used git repo as the source. Now
that we use the same version for all boards, use always use distribution
tarball for consistency and more efficient caching.
Cherry-picked downstream-only patch lost in Buildroot 2024.02 bump.
* buildroot 34e790c5da...9af2384782 (1):
> package/openvmtools: bump version to 12.3.0
Fixes#3366
RPi 5 config uses BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS which builds
the device tree overlays from the Linux tree when building the kernel.
The overlays directory also contains overlay_map.dtb which is necessary
to correctly map overlays without RPi version suffix to the
platform-specific ones. Without this, some peripherals may not work
correctly on Pi 5 without any obvious error messages in the kernel log
because an incorrect (Pi 4) overlay is used as the default.
Fixes#3321
* buildroot cc0481f40e...0a64bfe8f1 (1):
> Install overlay_map.dtb when using in-tree DT overlays
(cherry picked from commit fce19b7846)
Enable libkcapi in generic kernel config. The bloat is minimal and the
options are enabled on most distributions. These modules are also needed
for Bluetooth Mesh and adding them fixes compatibility with some HCI USB
adapters.
Fixes#3322
(cherry picked from commit 67315f86d4)
RPi 5 config uses BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS which builds
the device tree overlays from the Linux tree when building the kernel.
The overlays directory also contains overlay_map.dtb which is necessary
to correctly map overlays without RPi version suffix to the
platform-specific ones. Without this, some peripherals may not work
correctly on Pi 5 without any obvious error messages in the kernel log
because an incorrect (Pi 4) overlay is used as the default.
Fixes#3321
* buildroot cc0481f40e...0a64bfe8f1 (1):
> Install overlay_map.dtb when using in-tree DT overlays
Enable libkcapi in generic kernel config. The bloat is minimal and the
options are enabled on most distributions. These modules are also needed
for Bluetooth Mesh and adding them fixes compatibility with some HCI USB
adapters.
Fixes#3322
This fixes "Warning: your password will expire in 0 days." message
shown on tty login since Buildroot bump in HAOS 12.2.
* buildroot 9f5750121a...d29893dd98 (1):
> package/linux-pam: bump to version 1.6.1
GRUB 2.12 release contains a change of the loader [1] used for loading
the kernel on x86_64 platform. This change was identified to cause boot
failure on some old Intel Atom boards with the NM10 chipset, and
possibly some others. Revert this patch before we get a more proper fix
for the issue.
[1] https://git.savannah.gnu.org/cgit/grub.git/commit/?id=cfbfae1aef0694b416aa199291cfef7596cdfc20Fixes#3305
It seems that forcing 24MHz clocks is problematic for newer 32GB
Kingston based eMMC modules on ODROID-N2(+). Use what downstream
U-Boot is using as f_max, which is 40MHz.
Fixes: #3227
With #3281 we hit the maximum length of the quirks parameter. Since
cmdline.txt changes are not applied on OS update, only new installs of
12.2 are affected, effectively disabling all quirks until this patch
lands in future OS release.
Fixes#3308
Make sure all Raspberry Pi devices using the BCM2837 SoC (or the SiP
version RP3A0 of it) are deployed. This especially makes sure that
we only deploy the downstream device trees (named bcm2710*) and deploy
device trees for the CM3 as well as the Zero 2 and Zero 2 W consistently
for 32-bit and 64-bit.
* RaspberryPi: Update kernel to 6.6.20 - 6f16847710cc0502450788b9f12f0a14d3429668
Used version specified in RPi OS release notes [1].
[1] https://downloads.raspberrypi.org/raspios_arm64/release_notes.txt
* Update RPi Buildroot defconfigs for v6.6.y kernel
* Update RPi kernel patches for v6.6.y kernel
* Amended old patches to accomodate for new DTS paths
* Removed 6.6.25 patches -> moved to the common folder
* Added patch to fix Yellow DTS compilation
* Bump buildroot to update rpi-firmware
* buildroot b45d671fe3...9f5750121a (1):
> package/rpi-firmware: bump to version for (untagged) kernel v6.6.20
* Remove kernel v6.1.y config fragments, as they're not needed anymore
* Only run HA CLI interactively if stdout is a terminal
Flags for running HA CLI commands in an interactive shell added in #3238
cause the command to fail if the process is not running in a terminal.
This is needed for example for the fsfreeze hook, otherwise the command
fails, as seen in this trace when the hook is executed:
-----------
+ '[' thaw '=' freeze ]
+ '[' thaw '=' thaw ]
+ echo 'File system thaw requested, thawing Home Assistant'
File system thaw requested, thawing Home Assistant
+ ha backups thaw
the input device is not a TTY
------------
However, for example on Proxmox this message is not logged anywhere and
the hook just fails silently (i.e. it doesn't cause the backup to fail).
Fixes#3251
* Use -i also when not running in a terminal
(cherry picked from commit 78d281fce1)
CP15 barrier instruction emulation only exists on arm64 architecture.
Avoid sysctl writing an error to the journal when the setting doesn't
exist by prepending a dash.
(cherry picked from commit 889b561ca1)
Booting from a ADATA SD600Q fails when connected to a USB 3.0 port on RPi4. Adding it to the quirks list resolves the issue.
(cherry picked from commit 5ee9cef8c8)
* Only run HA CLI interactively if stdout is a terminal
Flags for running HA CLI commands in an interactive shell added in #3238
cause the command to fail if the process is not running in a terminal.
This is needed for example for the fsfreeze hook, otherwise the command
fails, as seen in this trace when the hook is executed:
-----------
+ '[' thaw '=' freeze ]
+ '[' thaw '=' thaw ]
+ echo 'File system thaw requested, thawing Home Assistant'
File system thaw requested, thawing Home Assistant
+ ha backups thaw
the input device is not a TTY
------------
However, for example on Proxmox this message is not logged anywhere and
the hook just fails silently (i.e. it doesn't cause the backup to fail).
Fixes#3251
* Use -i also when not running in a terminal
CP15 barrier instruction emulation only exists on arm64 architecture.
Avoid sysctl writing an error to the journal when the setting doesn't
exist by prepending a dash.
Since buildroot commit 3ceb8c97bcb6753740fa27a58b8e0dc00dbbbd19, systemd
has new option BR2_PACKAGE_SYSTEMD_VCONSOLE_DEFAULT_KEYMAP which
defaults to "us". With this option specified, systemd-console depends on
kbd package and causes the following message to be printed during
startup on HAOS:
systemd-vconsole-setup[253]: sh: gzip: not found
This comes from the loadkeys call which tries to open the gzipped file,
so likely the kbd package should also depend on gzip. However, since we
don't want the kbd package at this point, I'm leaving this for later
investigation and simply unsetting the new option to revert to
pre-2024.02 setup.
List Nabu Casa appliances under boards README.md
* Home Assistant Green
* Home Assistant Yellow (based custom carrier board and powered by a Raspberry Pi 4 Compute Module)
* Home Assistant Blue (based on ODROID-N2+)
The official description says:
Multipath TCP (MPTCP) connections send and receive data over multiple
subflows in order to utilize multiple network paths. Each subflow uses
the TCP protocol, and TCP options carry header information for MPTCP.
Thanks to MPTCP, being able to use multiple paths in parallel or
simultaneously brings new use-cases:
- Seamless handovers: switching from one path to another while
preserving established connections -- Apple is using it for this
reason since 2013.
- Best network selection: using the "best" available path (latency,
losses, cost, bandwidth) -- one path can be used as a "backup" one.
- Network aggregation: using multiple paths at the same time to have a
higher throughput -- e.g. to combine a fixed an mobile network to
send files faster.
For example, for HA, it is possible to keep a SSH connection alive when
switching from one network to another (e.g. while travelling).
To be able to use MPTCP, both ends need to support it. An application
has to request it, by creating an MPTCP socket instead of a TCP one.
The rest in unchanged. An alternative is to use 'mptcpize' tool, which
relies on LD_PRELOAD to create an MPTCP socket instead of a TCP one.
Note that a MPTCP-enabled server continues to accept regular TCP
connections that do not use the Multipath TCP extension without any
performance impact. When a connection request is received, and is linked
to a listening socket with MPTCP support, the kernel will simply check
if MPTCP options are present. If not, the accepted socket will be a
"plain" TCP one, with the same impact as before.
To use multiple paths at the same time, additional IP addresses need to
be configured, e.g. via the 'ip' tool (IPRoute2).
MPTCP in the kernel is enabled in most main Linux distributions (Debian,
Ubuntu, RedHat, Fedora, etc.), but in more specific ones like Raspbian.
It is available in the Linux kernel since v5.6.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
* Update Buildroot to tag 2024.02 with rebased HAOS patchset
* udisks2: update to v2.10.1
* Updated to version 2.10.x compatible with libblockdev v3
* Rebased patches to new codebase
* Autoreconf patch is not needed anymore
* libblockdev-nvme is now hard dependency of udisks daemon
* patches/grub2: remove upstreamed efidisk patch
* patches/network-manager: update multiple gateway patch
* package/os-agent: fix go download
After the Go update, build fails with the following error on mod vendor:
GOPROXY list is not the empty string, but contains no entries
Turns out this step is not having the environment variables set, use
those used for download to fix it.
* package/xe-guest-utilities: set DL env for go mod vendor
* Bump buildroot to fix missing unit file from nfs-utils
* buildroot 3f950a1aee...a1b2d12f32 (1):
> package/nfs-utils: only install fsidd binary and unit file with enabled nfsd
* CI: install flake8 for pr-checks runner
Use distribution package, as it's what's used in Buidlroot's Gitlab CI
Docker image at buildroot/support/docker/Dockefile.
* Disable check for Upstream section in the patch header for now
It was introduced in latest BR - disable it for now and re-enable
for HAOS in a later separate PR.
Fix regression caused by #3224 which introduced version-specific
directory for linux patches, causing the upper-level patch not being
applied. Copy the patch to the version folder instead. Also we need
to keep it in the upper directory for RPi kernels.
(cherry picked from commit 8226323a1b)
The test was missing --no-progress flag, which only manifested after
merging #3238 - causing the CLI to run in an interactive pseudotty.
(cherry picked from commit 122dd1c288)
Use -i (--interactive) and -t (--tty) to start the HA CLI interactively.
This is required by some commands like the new device wipe command added
with https://github.com/home-assistant/cli/pull/464.
(cherry picked from commit fe1978f98f)
Fix regression caused by #3224 which introduced version-specific
directory for linux patches, causing the upper-level patch not being
applied. Copy the patch to the version folder instead. Also we need
to keep it in the upper directory for RPi kernels.
Use -i (--interactive) and -t (--tty) to start the HA CLI interactively.
This is required by some commands like the new device wipe command added
with https://github.com/home-assistant/cli/pull/464.
The in-tree driver introduced in HAOS 12.0 is having random issues,
so revert back to the stable OOT driver that was used before for now.
Also it add it to RPi 2 and Yellow where it's been missing the whole
time.
Fixes#3205
Revert changes in the USB driver causing Z-Wave sticks (Z-Wave.me a
and Aeotec at least) failing to enumerate. Issue is reported upstream
but reverting the patches is a feasible workaround for the time being.
Refs #2995
Remove the mentions of petitboot, as it's not normally used on M1S.
Document possibility to use SD card boot and alternative method of
reflashing the eMMC from an OS running from an SD card.
With recent change of Azure VM type, the disk layout has changed and
the build of ova target fails with insufficient space. Since there
is now plenty of space on /mnt partition, we can use that, just like
we've been using it for cache for now.
Ref: https://github.com/easimon/maximize-build-space/issues/39#issuecomment-1935591779
* Copy Odroid-m1 config for new odroid-m1s board
* config: Adjust names and paths for odroid-m1s
* configs: Use rk3566 blobs for ATF
* set correct fdt in uboot.ush
* Add linux patches with Odroid-m1s devicetree
Synced from Hardkernel unofficial 6.1 tree
ae33b44557/arch/arm64/boot/dts/rockchip/rk3566-odroid-m1s.dts
With additional cleanup and fixes for mainline linux
* Add Odroid M1S to Github actions
* uboot: Patch boot order to set SD Card first
* Create u-boot placeholder partion for odroid-m1s also
* Switch u-boot to full odroid-m1s config
* cherry-pick emmc stability improvements
* Generalise u-boot to use ${devtype} instead of hardcoded mmc
* Remove deprecated snps, reset options from device tree
* re-enable uboot ethernet
* Create common kernel config for Rockchip aarch64 boards
* Green: drop kernel option already included in main config
* Move rockchip RNG patchset to common folder
* Odroid-m1 has no board specific patches now
We added drivers for Realtek cards readers in #3005, however it also
needs MMC drivers in order to make card reading possible. Enable both
USB and PCI versions of those (each about ~40 kB).
Fixes#3167
* Update issue template with better links to logs, add CLI instructions
Legacy supervisor_logs target (which is currently kind of broken) replaced
with standard logs with provider specified. Added instructions how to get
logs in HA CLI.
* Apply suggestions from code review
Co-authored-by: Stefan Agner <stefan@agner.ch>
* RaspberryPi: Update kernel to 6.1.73 - stable_20240124
* Bump rpi-firmware to version for RPi Linux 6.1.73
* buildroot f844f7f725...0ab96d7c0d (1):
> package/rpi-firmware: bump to version for stable_20240124 kernel
ODROID XU4 fails to boot after update to Linux 6.6. Comparing downstream
kernel config with upstream exynos defconfig shows it has various lockdep
options enabled, and PROVE_LOCKING seems to be the one that causes the
issue. It seems it (or any of PROVE_RCU, TRACE_IRQFLAGS or
PREEMPTIRQ_TRACEPOINTS) which get enabled along with it) probably
triggers some timing issues on the I2C bus, which causes the main PMIC
to fail to properly initialize all voltages.
Since these options should not have any real impact on our system, the
easiest option is to disable them. If we need them, or want to stay
closer to upstream defconfig, further debugging is needed.
Fixes#3137
We originally enabled it in 0ebcdcb9dc
but later reverted the patch in 5b927389b8
because of backward compatibility issues. Since we're going to 12.0,
there is now hopefully enough room for seamless transition.
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Use separate path for v6.1.y and v6.6.y kernel config fragments
Since we're now maintaining Linux configs for two different versions,
it may happen that we want to add some options only to one of the
versions. While the Kconfig might figure the invalid options itself,
our config checking tooling would spam us with warnings. This commit
splits the configs to two directories. This pattern is used only for
the common fragments, more specific ones are usually sharing the same
Linux version anyway.
* Add back options removed in v6.6.y to v6.1.y kernel config fragments
* Linux: Update kernel 6.6.15
* Update buildroot packages to work with Linux 6.6
* Fix top-level and pc patches of linux
* Update tinker patch series
* Drop Odroid M1 patches
M1 is now supported in upstream.
* Update Hardkernel patches
Needed larger refactoring because of 379ae64609c7a3301b60483eb65bd8bc78f76328
* Update Green patches
* Update Odroid XU4 patches
Removing the TMU patch/hack for now, need to check if it's still needed.
If it is indeed, then it needs slighter rewrite.
* Move Rockchip RNG patches to M1 and Green dirs
* Update rtl88x2bu package to fix build
* Update gasket package to fix build
* Fix eq3_char_loop build
* Use fan53555 instead of custom rk860x driver
* Fix kernel base configs and fragments after 6.6 update
Mostly removed options that have been removed between releases. Only
a few options have been renamed, then there's bunch of options that
had dependencies added so they are available only on some architectures,
which are not those that we're using.
* Remove deprecated regulator-compatible from Green DTS
Generate list of changelogs if we're bumping to the next patch release.
If major or minor version is bumped, the commit message contains only
the title, like before.
Also fix English in the commit title of RPi bump.
Odroid M1 was using 1056 MHz blob for RAM training, although it can run
at 1560 MHz. Use the correct file for M1 and update it to latest version,
along with ARM Trusted Firmware blob.
(cherry picked from commit 1f45aaf359)
We don't really use the MMC environment, so disable it by default. This
prevents the following warning at startup:
Loading Environment from MMC... *** Warning - bad CRC, using default environment
(cherry picked from commit f263326ef8)
It seems that the Ethernet initialization in U-Boot causes significant
packet drops in Linux on some board. On a ODROID-M1 with 8GB of RAM, a
packet loss rate of ~20% has been observed. From the user point of view
it feels like a massive slow down (SSH feels very slow, Home Assistant
loads very slow or not at all).
Disabling the Ethernet controller driver avoids initialization in U-Boot
and makes Ethernet work correctly again in Linux.
While at it, drop the previously board specific configs. They haven't
been used and the board seemed fine without them.
(cherry picked from commit bd3cae5300)
Odroid M1 was using 1056 MHz blob for RAM training, although it can run
at 1560 MHz. Use the correct file for M1 and update it to latest version,
along with ARM Trusted Firmware blob.
We don't really use the MMC environment, so disable it by default. This
prevents the following warning at startup:
Loading Environment from MMC... *** Warning - bad CRC, using default environment
It seems that the Ethernet initialization in U-Boot causes significant
packet drops in Linux on some board. On a ODROID-M1 with 8GB of RAM, a
packet loss rate of ~20% has been observed. From the user point of view
it feels like a massive slow down (SSH feels very slow, Home Assistant
loads very slow or not at all).
Disabling the Ethernet controller driver avoids initialization in U-Boot
and makes Ethernet work correctly again in Linux.
While at it, drop the previously board specific configs. They haven't
been used and the board seemed fine without them.
Enabling CONFIG_EXPERT, which was a dependency of some options we try
to set by our config fragments, had a side-effect of toggling some other
options, most importantly the framebuffer console support. Enable the
options found by diffing old and new kernel configs.
Fixes#3112
(cherry picked from commit 3d234144a2)
Enabling CONFIG_EXPERT, which was a dependency of some options we try
to set by our config fragments, had a side-effect of toggling some other
options, most importantly the framebuffer console support. Enable the
options found by diffing old and new kernel configs.
Fixes#3112
* ../../../buildroot 55120df0b7...512a487366 (3):
> package/linux-firmware: add WiFi and BT firmware for MT7921 and MT7922
> package/dbus-broker: fix legal info
> package/rtl8821cu: fix legal info
Since we're using a custom os_prefix for dual boot on RPi 5, overlays
can be also present in different directories. Raspberry Pi's bootloader
has a strange feature that it only respects os_prefix if the directory
with overlays contains a README file:
https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix
While rpi-firmware package touches the file when copying overlays to
the destination directory, for RPi 5 we are using BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS
option which does not copy or create it. Ensure it is present (no matter
if we're using intree on rpi-firmware overlays) in the hassos-hook.
Fixes#3079
(also removed invalid mention about the README from config.txt)
* Remove all non-existing kernel config symbols
* Remove unapplied x86 Intel sound options
These are missing various subsystem dependencies and were never in fact
enabled, assuming they're rather exotic and removing them completely.
* Add missing dependencies, adjust tristate values, remove nonsense
* Use KERNEL_LZ4 only for non-aarch64
Since aarch64 doesn't use self-extracting kernel:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190119185540.20526-1-tobias.johannes.klausmann@mni.thm.de/
* Extract PCI options to device-support-pci fragment (renamed from device-support-pcie)
RPi 4+ should use this fragment too, since CM4 has PCIe support.
* Rename RPi's kernel-32b fragment to kernel-armv7
* Bump U-Boot to 2024.01 for Raspberry Pi and Home Assistant Yellow
* Regenerated using --no-thread
By default git creates some email headers. We can minimize them using
--no-thread.
* Fix build for Yellow
* Update U-Boot for ASUS Tinker Board
* Update U-Boot for Khadas VIM3
* Update U-Boot for ODROID-M1
* Update U-Boot for Home Assistant Green
* Update U-Boot for ODROID-C2/C4/N2/XU4
It seems that the PCIe driver is not enabled for Khadas VIM3. Enable it
by default.
Note to make use of the M2X extension board, the following commands need
to be executed on the U-Boot command line:
```
HAOS> i2c dev 0
Setting bus to 0
HAOS> i2c mw 0x18 0x33 1
```
Wrong arch for arm64 produces few false check results resulting
from some symbols in arm64 tree not being loaded. We can use raw
$(ARCH) variable for arm, only need to translate aarch64 -> arm64.
Using apt-key for managing Debian repo keys has been deprecated for a
while now. While it currently works ok, seems to be broken in bookworm. This migrates to storing keys in trusted.gpg.d as recommended by the warning messages when using apt-key.
* buildroot 153f1461f6...55120df0b7 (8):
> package/linux-firmware: bump version to 20231211
> package/linux-firmware: bump version to 20231030
> package/linux-firmware: add iwlwifi quz firmware
> package/linux-firmware: add new option for Marvell prestera firmware
> package/linux-firmware: bump version to 20230804
> package/linux-firmware: bump version to 20230625
> package/linux-firmware: add QCA9377 BT firmware
> package/linux-firmware: bump version to 20230515
Path to cmdline is set in tryboot.txt to cmdline-tryboot.txt before
attempting A/B boot. After successful boot, tryboot.txt is relocated
to config.txt, yet the config path of cmdline is not changed and remains
set to cmdline-tryboot.txt which doesn't exist anymore at that point,
causing following reboots to fail.
Fixes#3065
The value of ```self_signed_cert``` is being set incorrectly, resulting in a failed build, as the self signed certs aren't copied correctly.
Updated so the value is set from ```self_signed_cert``` and not ```self_signed```
* Revert kernel patch causing failures on CIFS share disk usage
The issue was reported upstream, waiting for a fix there. Reverting the
patch for a quick resolution of the bug that breaks some things in HA
and add-ons badly.
Refs #3041
* Move the patch to 6.1.71 subdirectory
That way Raspberry Pi's kernel won't be patched (unless it's the same
version which it's currently not).
The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then
Cortex-A53. However, both ar armv7 architectures, and that is also how
the Operating System itself is configured. Use the correct architecture
for Supervisor.
The hassos-supervisor script should recreate the container
automatically on first boot after update.
Since Supervisor itself is written in Python this shouldn't affect much.
However, the Supervisor uses it's architecture as default architecture
when building local add-on and uses it as default architecture for
multi-arch container images. This is also where this error got noticed
(see https://github.com/home-assistant/supervisor/issues/4402#issuecomment-1865979421).
The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then
Cortex-A53. However, both ar armv7 architectures, and that is also how
the Operating System itself is configured. Use the correct architecture
for Supervisor.
The hassos-supervisor script should recreate the container
automatically on first boot after update.
Since Supervisor itself is written in Python this shouldn't affect much.
However, the Supervisor uses it's architecture as default architecture
when building local add-on and uses it as default architecture for
multi-arch container images. This is also where this error got noticed
(see https://github.com/home-assistant/supervisor/issues/4402#issuecomment-1865979421).
* Remove duplicated step uploading ova QEMU image for the test job
Instead of uploading the file twice with a fixed name, upload it in the
same step that is used for unpublished builds and pass the version string
to the test job.
* Update .github/workflows/test.yaml
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
Generate the certificate only once and make it available. The preferred
option that doesn't generate warnings would be to use secrets in the
repository config, in that case no certificate is generated or archived.
Enable PCI card reader found on some Intel NUC models, along with the USB
drivers as well.
Adds two new modules (listed with size):
30104 /lib/modules/6.1.68-haos/kernel/drivers/misc/cardreader/rtsx_usb.ko
167240 /lib/modules/6.1.68-haos/kernel/drivers/misc/cardreader/rtsx_pci.ko
Fixes#2688
There is bunch of kernel config options that are not propagated
correctly to the kernel configuration after fragments are merged
and processed by Kconfig. Current Buildroot tools are not good at
discovering these - while we cleaned up most inconsistencies by using
linux-diff-config and output from the merge_config.sh script, there
are still options that were removed or get a different value than
intended because of dependencies, etc.
This commit adds a Python script that is using Kconfiglib to parse
current kernel's Kconfig files and the generated .config and compare
the requested values from individual kernel config fragments. The
script can be used manually by running `make linux-check-dotconfig`
from the buildroot directory (with path to BR2_EXTERNAL directory set)
and it's called also from the CI, where it generates Github Workflow
warning annotations when some of the values are not present or when set
incorrectly.
The kconfiglib.py is checked-in to the repo as well, because the library
is currently abandoned on PyPI and packaged version has a bug that causes
errors parsing Kconfigs in newer Linux versions, fixed in outstanding
pull request ulfalizer/Kconfiglib#119 - so version from this PR is used
here.
If pypi/support#2526 is ever resolved, we could remove it from our repo
and use pip for installing the package as a requirement during build
of the build container.
Add new firmwares and enable them for all targets.
Bloat in rootfs in my x86_64 test build was ~2.16 MiB.
Buildroot bump:
* buildroot 8a75878da4...4c89661fd1 (2):
> package/linux-firmware: add WiFi and BT firmware for MT7921 and MT7922
> package/linux-firmware: add rtw89 firmware files
Make it possible to run build on feature branches by adding a flag that
can be used to select whether the build output will be uploaded to the
R2 artifacts bucket or kept only as build artifact on GH. The latter is
also used for 3rd party repos, allowing builds in forked repositories.
Feature builds are using Unix timestamp as the dev version suffix. This
makes them easily distiguishable, yet it makes them appear to be newer
than standard daily dev version builds when compared by AwesomeVersion.
Compress firmware files from linux-firmware using ZSTD algorithm.
This should grant us some more space to add more firmwares and should
not have any major performance impact, because firmwares are not accessed
frequently.
Includes buildroot submodule bump:
* buildroot 07e08e01b2...8a75878da4 (1):
> linux-firmware: add option for firmware files compression
This allows for rudimentary image/partition size tracking between builds,
potentially this could be further extended with more useful information
about the build (TBD).
* Add initial Raspberry Pi 5 buildroot config
* Add machine-id support via cmdline.txt
* Add new entry if entry is missing
* Don't overwrite cmdline.txt when adding machine-id
Use sed to append the new cmdline parameter to the first line.
* Skeleton script for RAUC custom bootloader interface
* Deploy kernel/device-tree into a RAUC slot specific directory
This allows us to use the os_prefix feature to switch between slot A and
B. Compared to the boot_partition option, this option allows to use a
shared config.txt and cmdline.txt, which makes it more like how HAOS
currently works on other Raspberry Pis.
* Deploy new kernel/device-tree to correct slot on installation
* Increase boot size to 128MB
This makes sure we can store up to three kernels (slot A, B and an
temporary one while installing the OTA update).
* Initial tryboot implementation using os_prefix
* Make sure to delete the old slot completely
* Add Busybox xargs for tryboot bootloader script
* Compare tryboot bootloader file silently
* Revert "Increase boot size to 128MB"
This reverts commit 7f2c69b58f02f500d6aeee4f0a419046899b5e38.
* Use compressed kernel
* Address shellcheck
* Address shellcheck issue in rauc-hook
* Fix shellcheck for rpi-tryboot.sh
* Do not follow source - it gets checked separately
* Correctly set the slot to boot
* Apply suggestions from code review
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop serial console from default cmdline.txt
* Resync rpi5_64_defconfig with rpi4_64_defconfig
* Improve machine-id match
Only match actual hexadecimal characters.
* Deploy firmware overlays to OS prefix directory
* Add Raspberry Pi 5 to documentation
* Bump buildroot
* buildroot fd1dc86f40...f13ad03408 (1):
> linux: add in-tree device tree overlay support
* Install device tree overlays from Kernel sources
* Drop RPi RF modules for now
No Raspberry Pi 5 specific device tree overlays are available, drop RPi
RF mod for now.
* Use Raspberry 5 specific identifiers for Supervisor/OS Agent
* Bump buildroot
* buildroot f13ad03408...07e08e01b2 (1):
> linux: fix add in-tree device tree overlay support
* Revert "Drop RPi RF modules for now"
This reverts commit 46fc1701e4.
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
There is no sanity check when creating OS images, so when some of the
partitions gets too big, part of its data may get overwritten by the
following partition, resulting in corrupted image. Add checks for the
defined partition sizes and bail out if they're too big.
* Fix Supervisor image corruption detection
When multiple images match the reference, multiple IDs are passed as a
single argument to docker image rm, leading to an error:
Error response from daemon: page not found
Make sure to pass the ids as separate argument to make the delete work
in any case.
* Cleanup reusing Supervisor from an old/unused reference
As noted in #2113, we don't need this logic anymore after a major OS
releases. So simply drop the logic to also make the image corruption
detection work again.
* Make sure image IDs are sorted to make them unique
Current mainline contains support for two more WiFi cards in the mt7921u
driver that only use a proprietary VID/PID but are compatible with the
standard driver. Backport support for those via a simple driver patch.
Fixes#2926
* Fix Supervisor image corruption detection
When multiple images match the reference, multiple IDs are passed as a
single argument to docker image rm, leading to an error:
Error response from daemon: page not found
Make sure to pass the ids as separate argument to make the delete work
in any case.
* Cleanup reusing Supervisor from an old/unused reference
As noted in #2113, we don't need this logic anymore after a major OS
releases. So simply drop the logic to also make the image corruption
detection work again.
* Make sure image IDs are sorted to make them unique
Preemptively enable larger set of WiFi drivers for all platforms and add more firmwares for them with the aim to harmonize WiFi device support among all boards and to have implicit support of devices that users might want to use. Targets `generic_aarch64`, `generic_x86_64` and `ova` also include options and firmwares for cards that are using PCI/PCIe bus - support for these is in a separate config fragment.
Especially the `generic_x86_64` is currently very tight with the rootfs space, so I had to do some triaging and select only sensible drivers and firmwares - especially archaic PCMCIA devices or devices not supporting only 802.11g or lower standards were among the first that I removed during the triaging - we can consider enabling those but this time on an someone's explicit need to have them enabled.
This closes#2815 and replaces large part of #2761, also potentially addresses (at least) these: #2806, #2783, #2841, #2776, #2725, #2600
-------------
* Remove WiFi options from generic and board kernel config fragments
* Enable MMC in OVA kernel
This is needed for SDIO drivers to work. Use the same options as we
currently use for generic_x86_64.
* Add CRYPTO_MICHAEL_MIC to the common kernel config
This is requirement for TKIP and is a dependency of ATH11K driver.
* Add kernel config fragments with wireless cards support
* Add firmwares for WiFi cards
* Enable more Bluetooth device drivers
* Remove kernel HCI driver if no WiFi/Bluetooth module present (#2944)
If the WiFi/Bluetooth module is not present on the SDIO bus, remove the
HCI driver. This avoids hci0 interface to be present. Current Home
Assistant Core versions show a Bluetooth device as soon as a hci device
is present. With this change there won't be a Bluetooth device shown.
* Update buildroot-external/package/pi-bluetooth/hcidisable.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Do not start hciuart.service if krnbt is used
Avoid starting (and failing to start) hciuart.service if krnbt is used.
This avoid unnecessary failed services showing up.
* Update buildroot-external/package/pi-bluetooth/hciuart.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop duplicate bluetooth in path
* Avoid bthelper@hci0.service failing
* Revert "Avoid bthelper@hci0.service failing"
This reverts commit f79777e63e.
* Add ExecConditiono to bthelper@.service as well
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Remove kernel HCI driver if no WiFi/Bluetooth module present (#2944)
If the WiFi/Bluetooth module is not present on the SDIO bus, remove the
HCI driver. This avoids hci0 interface to be present. Current Home
Assistant Core versions show a Bluetooth device as soon as a hci device
is present. With this change there won't be a Bluetooth device shown.
* Update buildroot-external/package/pi-bluetooth/hcidisable.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Do not start hciuart.service if krnbt is used
Avoid starting (and failing to start) hciuart.service if krnbt is used.
This avoid unnecessary failed services showing up.
* Update buildroot-external/package/pi-bluetooth/hciuart.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop duplicate bluetooth in path
* Avoid bthelper@hci0.service failing
* Revert "Avoid bthelper@hci0.service failing"
This reverts commit f79777e63e.
* Add ExecConditiono to bthelper@.service as well
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Generate self-signed certificates for development
To simplify development generate a self-signed certificate on first
build. Also make sure that the self-signed certificate is being added
the RAUC keyring so that manual updates can be performed.
* Add self-signed certificat independent of deployment type
* Add a warning when building with self-signed certificate
Bluetooth initialization was broken on Yellow because RPi's kernel
started to use initialization by the kernel driver by default, yet
changes from the miniuart-bt overlay are applied directly to Yellow
DTS and had to be updated too. This commit replaces the previous
patch forcing the miniUART usage for Bluetooth with a new one which
is based on the current miniuart-bt-overlay.dts.
Also added a little warning to the RPi kernel bump script, so the
future me/us don't do the same mistake as I did.
* buildroot 20ea6bedda...a48cc458e7 (1):
> package/rpi-firmware: bump to version for stable_20231030 kernel
Reduce fully-expanded configs versioned in our repository to defconfigs
containing only the necessary options. Just like #2923, this change does
not alter the resulting kernel .config in any way for the affected
platforms (Tinker, Odroid C2/C4/N2).
For tinker and amlogic-based targets we're using checked-in kernel
configs generated by kconfig for some old kernel revisions. Check in
current config before we clean it up and reduce to a smaller stub later.
Clean up all kernel configs and fragments from non-existing kernel
options, invalid choice values and choices that trigger warnings
during kernel package configuration.
Here's an example of warnings triggered for Yellow:
.config:8531:warning: override: MODULE_COMPRESS_NONE changes choice state
.config:8536:warning: override: ZSWAP_COMPRESSOR_DEFAULT_LZ4 changes choice state
.config:8537:warning: override: ZSWAP_ZPOOL_DEFAULT_ZSMALLOC changes choice state
.config:8543:warning: override: CPU_FREQ_DEFAULT_GOV_ONDEMAND changes choice state
.config:8717:warning: override: reassigning to symbol CGROUP_HUGETLB
.config:8767:warning: symbol value 'm' invalid for XFRM
.config:8852:warning: symbol value 'm' invalid for MEDIA_CONTROLLER_DVB
.config:8972:warning: symbol value 'm' invalid for SND_HDA_I915
There were also some options that are set in our or default configs
but end up patched by `KCONFIG_(DIS|EN)ABLE_OPT` in package makefiles,
these options are now explicitly set in our fragments too. For example
this was toggled for `generic_aarch64`:
CONFIG_DEFAULT_SECURITY_APPARMOR n -> y
CONFIG_DEFAULT_SECURITY_DAC y -> n
CONFIG_GCC_PLUGINS y -> n
The only goal of this commit is to make sure no warnings appear
anymore and the resulting kernel configs remain unchanged. This will
allow us to create tools for sanity checks of our kernel config
overrides. There is one single change in `ova` config resulting from
previously invalid `m` option for a bool value:
-# CONFIG_9P_FS_POSIX_ACL is not set
+CONFIG_9P_FS_POSIX_ACL=y
* Use kernel local version for HAOS compiled Linux kernel
Use the local version config option to add "haos" to the system's Linux
kernel version to indicate the kernel is built specifically for Home
Assistant OS. This makes sure to overwrite any other local version (e.g.
provided by Raspberry Pi kernel's defconfig) and makes it easier to
verify something is running on HAOS since the string will be visible in
any Container using `uname -a`.
* Add dash in front
* Add missing dependency to kernel.config
* Move CONFIG_IIO up to follow Kconfig hieararchy
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* 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
Can be found in [Settings -> System -> Repairs -> System Information](https://my.home-assistant.io/redirect/system_health/). It is listed as the `Board` value.
@@ -56,10 +60,21 @@ body:
validations:
required:true
attributes:
label:Did you upgrade the Operating System.
label:Did the problem occur after upgrading the Operating System?
default:0
options:
- "Yes"
- "No"
- "Yes"
- type:textarea
validations:
required:true
attributes:
label:Hardware details
description:>
Provide details about the hardware used for your install.
This is especially important for bare-metal x86 installations.
If you have any USB devices attached, please list them here.
For VMs, include the hypervisor type and version.
- type:textarea
validations:
required:true
@@ -79,10 +94,10 @@ body:
attributes:
label:Anything in the Supervisor logs that might be useful for us?
description:>
Supervisor Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/)
then choose `Supervisor` in the top right.
Supervisor Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/?provider=supervisor)
then choose `Supervisor` in the top right. Alternatively enter `ha supervisor logs` in the Home Assistant CLI.
[](https://my.home-assistant.io/redirect/supervisor_logs/)
[](https://my.home-assistant.io/redirect/logs/?provider=supervisor)
render:txt
- type:textarea
validations:
@@ -90,8 +105,8 @@ body:
attributes:
label:Anything in the Host logs that might be useful for us?
description:>
Host Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/)
then choose `Host` in the top right.
Host Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/?provider=host)
then choose `Host` in the top right. Alternatively enter `ha host logs` in the Home Assistant CLI.
- [Home Assistant Yellow](https://www.home-assistant.io/yellow/) (based custom carrier board and powered by a Raspberry Pi 4 Compute Module)
- [Home Assistant Blue](https://www.home-assistant.io/blue/) (based on ODROID-N2+)
- Raspberry Pi
- Pi 4 Model B (1 GB, 2 GB, 4 GB and 8 GB model) 64-bit (recommended)
- Pi 4 Model B (1 GB, 2 GB, 4 GB and 8 GB model) 32-bit
- Pi 3 Model B and B+ 64-bit (recommended)
- Pi 3 Model B and B+ 32-bit
- Pi 2 (not recommended)
- Pi Zero-W (not recommended)
- Pi (not recommended)
- Pi 5 ([4 GB](https://www.raspberrypi.com/products/raspberry-pi-5/?variant=raspberry-pi-5-4gb) and [8 GB](https://www.raspberrypi.com/products/raspberry-pi-5/?variant=raspberry-pi-5-8gb) model) 64-bit
- 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)
Home Assistant OS 12 and newer support the ODROID-M1S board.
## SD-card
ODROID-M1S can boot HAOS directly from an SD card, as it has higher priority than the system on the eMMC. Simply flash the image to the SD card using your favorite tool and insert it to the micro SD slot on the board. This works even when the eMMC is wiped, or when it contains the factory-default U-Boot SPL loader, which is still able to load U-Boot provided in the HAOS image. In the second case, however, if the SD card fails to probe (e.g. due to a hardware failure), the system on the eMMC may be booted instead of HAOS.
## eMMC
HAOS can be installed directly to the eMMC using a special boot image, to do that:
1. Download the _UMS Utility_ image: [`ODROID-M1S_EMMC2UMS.img`][1]. The _UMS Utility_ is a special image that switches ODROID-M1S to USB Mass Storage device.
2. Use balenaEtcher or another tool to flash the _UMS utility_ onto an SD card.
3. Plug-in that SD card to your ODROID-M1S and boot it. Connect your PC to the Micro USB OTG port.
4. The eMMC will show as a drive on your PC and you can directly flash the HAOS image with balenaEther.
Installing HAOS replaces the firmware and SPL on the eMMC with the mainline version provided by HAOS. As a result, it is not possible to use the SD card with the EMMC2UMS image anymore, because the mainline SPL is not compatible with U-Boot in the EMMC2UMS image at this time (February 2024). This does not pose any problem for standard use, just makes it more complicated in case you want to return to the Hardkernel-provided OS.
A reliable way of reflashing the eMMC in this case is to use HAOS booted from an SD card. To do that, insert the SD card with HAOS to the micro SD slot and plug the board in. Once the device boots to the HA CLI, enter `login` to enter the root shell and use `curl` to download an image and `dd` it to the eMMC block device:
This way the device will start in the UMS mode on the next boot with the SD card removed. Alternatively you can use the [Hardkernel installer image][2] directly instead of the EMMC2UMS image.
## NVMe
Booting directly from NVMe is not supported. The NVMe card can be used as a data disk.
## Technical notes on boot flow
The Home Assistant OS image is bootable by the SoC directly. Refer to the [boot sequence documentation][3] for the details on what part of the boot is executed from the eMMC and what from the SD card. The steps documented above should however cover all scenarios that a standard user may encounter during usage.
## Console
By default, console access is available on the serial header (UART) and on HDMI.
The serial console's baudrate is 1500000 by default.
The systemd startup messages will only appear on the serial console by default.
To show the messages on the HDMI console instead, add the console manually
to the `cmdline.txt` file on the boot partition (e.g. `console=tty0`).
## GPIO
Odroid-M1S introduces a new 14pin expansion header. Refer to [the ODROID wiki][4].
At this point not all functionality is supported by the upstream kernel used by Home Assistant OS.
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.
[](https://www.openhomefoundation.org/)
## Features
@@ -14,6 +16,7 @@ Home Assistant Operating System uses Docker as Container engine. It by default d
## Supported hardware
- Nabu Casa
- Raspberry Pi
- Hardkernel ODROID
- Asus Tinker Board
@@ -37,7 +40,7 @@ The Home Assistant Operating System documentation can be found on the [Home Assi
### Components
- **Bootloader:**
- [Barebox](https://barebox.org/) for devices that support UEFI
- [GRUB](https://www.gnu.org/software/grub/) for devices that support UEFI
- [U-Boot](https://www.denx.de/wiki/U-Boot) for devices that don't support UEFI
- **Operating System:**
- [Buildroot](https://buildroot.org/) LTS Linux
@@ -55,4 +58,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).
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.
