* 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
