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)
* 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.
- [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 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)
@@ -13,6 +17,7 @@ The following boards/devices are supported:
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 [`ODROID-M1S_EMMC2UMS.img`][1]
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.
@@ -27,6 +24,3 @@ index 6cdf595cdc2c..e867da211c9f 100644
};
&i2s {
--
2.42.0
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.
