Update of OpenSSL in OS 12.2 from 1.1.1 to 3.2 changed the output of `openssl
sha256` command. It seems that some hypervisors don't like this and fail if
it's not plain "SHA256".
Fixes#3654
Update Docker and its dependencies to versions packaged in last bugfix release.
* buildroot 3914f8cad5...4cd211162d (4):
> package/runc: bump version to v1.2.6
> package/docker-cli: bump version to v28.0.4
> package/docker-engine: bump version to v28.0.4
> package/containerd: bump version to v1.7.26
Firmware change that set initial_turbo to 60 from the previous 0 has broken
initialization of some SD cards in U-Boot. Adjust the value in config.txt on OS
update if the value is not already set by the user, and put it to the default
config.txt.
The config.txt also contains a short comment explaining the purpose. The
purpose of it is also to make it easier to revert this change in the future if
the problem is fixed in the firmware or U-Boot.
Fixes#3965
One of the reason for failures after update to OS 15.0 was missing support for
the kernel PIO driver in EEPROM firmware. Backport upstream patches from
raspberrypi/linux#6645 and raspberrypi/linux#6642 that handle this situation
more gracefully. These patches could be dropped after the next RPi kernel
release.
Refs #3943
Update generic_raw_uart package to the latest sources available coming with
direct kernel 6.12.x compatibility dropping the intermediate patches
accordingly. In addition, the eq3_char_loop patchset was updated to reflect the
same changes performed.
When Intel GPUs are used in passthrough, the i915 is probed too early and fails
to load firmware which is in the rootfs mounted later. The CONFIG_DRM_I915=y
comes from x86_64_defconfig, by changing it to module (like we do for
generic-x86-64), the driver becomes only available after the rootfs is mounted
and firmware is loaded correctly.
Fixes#3949
It seems that kernel 6.12 handles device probing less gracefully when these
options are not enabled and causes crash on some AMD SoCs, e.g.:
*ERROR* Invalid callback to read register 0x58184
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4050
Refs #3944
U-Boot update in #3878 changed the layout of patch folders for Hardkernel
targets with the goal to make it less confusing. However, it missed adding the
top-level hardkernel patches directory to all hardkernel targets and only
remove it from some of them in [1].
Revert to state before #3878 by adding the hardkernel folder to c2/c4/n2. In
the future, the patches from this folder should be split per target and if any
patches remain in it, they should be applied for all hardkernel boards.
[1] 2716b564c2Fixes#3936
We check that landing page is working when the network is down but we don't
check it in the happy path. Add its test to make it more obvious when the
just landing page is broken.
In some cases, the wipe service may be called due to a race condition for the
second time during the boot, very likely failing because the filesystems are
already mounted. This can not be reproduced on OVA but can be fairly easy
triggered e.g. on RPi. As we want the service to be executed exactly only once,
we can do what's suggested in [1] and set the RemainAfterExit=yes. That should
ensure the unit is not ever started for the second time.
[1] https://www.github.com/systemd/systemd/issues/29367
(cherry picked from commit 24640c11aeb89290f7a1ecfd0c8c6527f8523e27)
In some cases, the wipe service may be called due to a race condition for the
second time during the boot, very likely failing because the filesystems are
already mounted. This can not be reproduced on OVA but can be fairly easy
triggered e.g. on RPi. As we want the service to be executed exactly only once,
we can do what's suggested in [1] and set the RemainAfterExit=yes. That should
ensure the unit is not ever started for the second time.
[1] https://www.github.com/systemd/systemd/issues/29367
Add missing patch and update for latest runc version to fix losing device
permissions when new devices are added in runtime.
* buildroot b079a02a9a...3914f8cad5 (2):
> package/runc: add patch for extended default allowed devices in v1.2.4
> package/runc: add missing patch to fix device permissions update
Fixes#3915
(cherry picked from commit 04debe2f539c4275fd68fe4d38fee3f8b8bab84b)
Update to latest version of the driver and matching firmware. The most common
application for it - Frigate - currently has 4.19.0 in stable but 4.20.0 is
staged in dev. As it's easier to select OS version than a version of the
add-on, it makes sense to stay ahead in HAOS. This also means Frigate needs to
be updated to the matching version (as staying on an arbitrary older patch
revision doesn't make much sense either).
(cherry picked from commit 173a4388fe7ee2f26c277b6c2dccdcab1b9f0a58)
* Add test checking journal logs for dependency cycles
* Run some test cases to get their output also when full init fails
* Remove high timeouts from the times when GHA couldn't use KVM
* Enable logging durations for future optimizations
(cherry picked from commit 4a1d2b75b94483efc749e88aab95fa639aa2bb0a)
Use simple shell script to perform device wipe instead of calling OS Agent to
do that through the UDisks2 API. While it might have been a good idea to use
high level interface for that back then, it turns out it causes more issues
than the benefits it could bring.
Main problem currently is that the OS Agent needs to read sysctl variables, but
those are only set after mounting the overlay partition. But at the same time,
the overlay partition can't be mounted if we want to wipe it - this creates a
dependency cycle through the haos-agent.service.
To get rid of the cycle and simplify things, use a shell script doing basically
the same what the OS Agent does. Since the wipe functionality only makes sense
to be implemented on HAOS targets (not on Supervised), there's little point of
having it in higher layer of abstraction that OS Agent provides.
It should be also checked if changes from #1291 are needed anymore, as the
driving factor for those have been probably the wipe feature in OS Agent too,
but at this point they seem to be harmless.
(cherry picked from commit 6c4f32a8c0cb48ba203d48068a773a5b3895ccfc)
Update to latest version that fixes start order in haos-agent.service. Without
that, OS Agent reports incorrect swappiness after boot.
(cherry picked from commit 36d905720a12742b4d46f3a0a6b0ca4628ed3f1d)
As discussed in #3885, now that fixed Supervisor is in stable, we can test that
no AppArmor denied events are logged during CI tests.
(cherry picked from commit 610ced0162aa1c76915a0cc2adf16d93c858358e)
Add missing patch and update for latest runc version to fix losing device
permissions when new devices are added in runtime.
* buildroot b079a02a9a...3914f8cad5 (2):
> package/runc: add patch for extended default allowed devices in v1.2.4
> package/runc: add missing patch to fix device permissions update
Fixes#3915
Update to latest version of the driver and matching firmware. The most common
application for it - Frigate - currently has 4.19.0 in stable but 4.20.0 is
staged in dev. As it's easier to select OS version than a version of the
add-on, it makes sense to stay ahead in HAOS. This also means Frigate needs to
be updated to the matching version (as staying on an arbitrary older patch
revision doesn't make much sense either).
* Add test checking journal logs for dependency cycles
* Run some test cases to get their output also when full init fails
* Remove high timeouts from the times when GHA couldn't use KVM
* Enable logging durations for future optimizations
Use simple shell script to perform device wipe instead of calling OS Agent to
do that through the UDisks2 API. While it might have been a good idea to use
high level interface for that back then, it turns out it causes more issues
than the benefits it could bring.
Main problem currently is that the OS Agent needs to read sysctl variables, but
those are only set after mounting the overlay partition. But at the same time,
the overlay partition can't be mounted if we want to wipe it - this creates a
dependency cycle through the haos-agent.service.
To get rid of the cycle and simplify things, use a shell script doing basically
the same what the OS Agent does. Since the wipe functionality only makes sense
to be implemented on HAOS targets (not on Supervised), there's little point of
having it in higher layer of abstraction that OS Agent provides.
It should be also checked if changes from #1291 are needed anymore, as the
driving factor for those have been probably the wipe feature in OS Agent too,
but at this point they seem to be harmless.
Cherry-pick bumps up to v5.79 and sync other changes and fixes with latest
upstream state.
* buildroot b4df362187...7d5c3b5e70 (10):
> package/bluez5_utils: tidy up the init script
> package/bluez5_utils: install datafiles with correct permissions
> package/bluez5_utils: fix dbusconfdir
> package/bluez5_utils{, -headers}: bump version to 5.79
> package/bluez5_utils: enable asha/bass when building audio plugins
> package/{bluez5_utils, bluez5_utils-headers}: bump to version 5.78
> bluez5_utils: disable asha profile
> package/{bluez5_utils, bluez5_utils-headers}: bump to version 5.77
> package/bluez5_utils: disable datafiles
> package/bluez5_utils: fix sixaxis build without tools
Update Docker to latest version and containerd to latest version from the 1.7
line. Runc updated to v1.2.5 with rebased patchset from the outstanding PR.
* buildroot 257ddc70ce...b4df362187 (4):
> package/runc: bump version to v1.2.5
> package/docker-cli: bump version to v28.0.1
> package/docker-engine: bump version to v28.0.1
> package/containerd: bump version to v1.7.25
Mainly the amdgpu updates cause an increase of generic-x86-64 image size by
~12MB but there's still enough of space in the rootfs after recent cleanup.
* buildroot c5a1cbcf73...257ddc70ce (9):
> package/linux-firmware: bump Intel BZ firmware version to 92
> package/linux-firmware: bump version to 20250211
> package/linux-firmware: bump version to 20241210
> package/linux-firmware: fix build failures to due RTL8723 file changes
> package/linux-firmware: bump version to 20240909
> package/linux-firmware: bump to version 20240709
> package/linux-firmware: improve help text for Realtek 88xx Bluetooth firmware
> package/linux-firmware: install all rtl88 Bluetooth binary blobs
> package/linux-firmware: RTL_88XX_BT: install all firmware
Disable downstream option for linux-firmware compression. With #3877 it's not
needed for x86 anymore and other boards don't need it. Eventually the higher
EROFS compression for firmwares and modules can be enabled for other targets as
well.
