* 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
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.
* 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.
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
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
