armsr/armv8:generic ERROR: Sysupgrade type 'combined-efi' should be one of [ "combined", "rootfs" ]

[AlbrechtL]

I don't know if this is really a bug but owut told me to report it ;-) .

root@OpenWrt:~# owut check --version-to SNAPSHOT
owut - OpenWrt Upgrade Tool 2024.10.25~8c8907c6-r2 (/usr/bin/owut)
ERROR: Sysupgrade type 'combined-efi' should be one of [ "combined", "rootfs" ]
This is a bug in 'owut/2024.10.25~8c8907c6-r2', please report at
  https://github.com/efahl/owut/issues

In [anonymous function](), file /usr/bin/owut, line 103, byte 24:
  called from function complete_build_info (/usr/bin/owut:1202:84)
  called from function collect_platform (/usr/bin/owut:1314:39)
  called from function collect_all (/usr/bin/owut:1321:19)
  called from anonymous function (/usr/bin/owut:2024:15)

 `           `  ${issue_url}\n`);`
  Near here -------------------^

root@OpenWrt:~# 

Background I'm running OpenWrt via qemu in a container (https://github.com/AlbrechtL/openwrt-docker). I decided not to use the combined image, instead I use the kernel and the ext4 rootfs as separate images. Maybe it is time to overthink this decision... Anyway, I'm looking how to upgrade an OpenWrt installation without losing the user packages in a qemu environment. For that reason I'm following your great owut development.

[efahl]

Hmm, that's an odd one. This is on the armsr/armv8 target like in the graphic on your GH page?

It looks like an EFI boot system is being detected in the container, but the build is only producing the non-EFI images (see https://downloads.openwrt.org/snapshots/targets/armsr/armv8/, no ...combined-efi... files).

Could you check inside the container and see if it thinks it's EFI?

$ ll /sys/firmware/
drwxr-xr-x    6 root     root             0 Oct 17 11:42 ./
dr-xr-xr-x   13 root     root             0 Oct 17 11:42 ../
drwxr-xr-x    5 root     root             0 Nov  9 14:43 acpi/
drwxr-xr-x    4 root     root             0 Nov  9 14:43 dmi/
drwxr-xr-x    4 root     root             0 Oct 17 11:42 efi/     <<<<<<<<< existence of this dir means "I'm an efi device"
drwxr-xr-x   18 root     root             0 Nov  9 14:43 memmap/

As a workaround try this; that final no should force it to ignore the above efi/ check.

$ owut check --device armsr/armv8:generic:ext4:no
...
Target         armsr/armv8
Profile        generic
Package-arch   aarch64_generic
Root-FS-type   ext4
Sys-type       combined
...

[AlbrechtL]

This is on the armsr/armv8 target like in the graphic on your GH page?

Yes. For armsr I'm using the images generic-kernel.bin and https://downloads.openwrt.org/snapshots/targets/armsr/armv8/openwrt-armsr-armv8-generic-ext4-rootfs.img.gz. But I boot OpenWrt via EFI.

root@OpenWrt:~# ll /sys/firmware/
drwxr-xr-x    6 root     root             0 Nov 10 13:25 ./
dr-xr-xr-x   12 root     root             0 Nov 10 13:25 ../
drwxr-xr-x    4 root     root             0 Nov 10 13:26 acpi/
drwxr-xr-x    2 root     root             0 Nov 10 13:26 devicetree/
drwxr-xr-x    4 root     root             0 Nov 10 13:26 dmi/
drwxr-xr-x    3 root     root             0 Nov 10 13:25 efi/
-r--------    1 root     root           398 Nov 10 13:26 fdt

root@OpenWrt:~# owut check --device armsr/armv8:generic:ext4:no --version-to SNAPSHOT
owut - OpenWrt Upgrade Tool 2024.10.25~8c8907c6-r2 (/usr/bin/owut)
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         armsr/armv8
Profile        generic
Package-arch   aarch64_generic
Root-FS-type   ext4
Sys-type       combined
Version-from   24.10-SNAPSHOT r28014-c0a50b1d59 (kernel 6.6.58)
Version-to     SNAPSHOT r28025-5f68e24333 (kernel 6.6.59)
Build-FS-type  ext4
Build-at       2024-11-08T09:51:00Z (~52 hours ago)
Image-prefix   openwrt-armsr-armv8-generic
Image-URL      https://downloads.openwrt.org/snapshots/targets/armsr/armv8
Image-file     openwrt-armsr-armv8-generic-ext4-combined.img.gz
Installed      268 packages
Top-level      144 packages
Default         61 packages
User-installed  89 packages (top-level only)

Package version changes:
[...]

[AlbrechtL]

Update: Inside my OpenWrt Docker image I changed to the squashfs combined image (https://downloads.openwrt.org/snapshots/targets/armsr/armv8/openwrt-armsr-armv8-generic-squashfs-combined.img.gz). Unfortunately, owut is still not working.

root@OpenWrt:~# owut check
owut - OpenWrt Upgrade Tool 2024.10.27~8c7e42f0-r1 (/usr/bin/owut)
ERROR: Sysupgrade type 'combined-efi' should be one of [ "combined", "rootfs" ]
This is a bug in 'owut/2024.10.27~8c7e42f0-r1', please report at
  https://github.com/efahl/owut/issues

In [anonymous function](), file /usr/bin/owut, line 103, byte 24:
  called from function complete_build_info (/usr/bin/owut:1203:84)
  called from function collect_platform (/usr/bin/owut:1315:39)
  called from function collect_all (/usr/bin/owut:1322:19)
  called from anonymous function (/usr/bin/owut:2025:15)

 `           `  ${issue_url}\n`);`
  Near here -------------------^

Maybe owut has also in issue with the new apk package manager (same as here: https://github.com/efahl/owut/issues/22)

root@OpenWrt:~# owut check --device armsr/armv8:generic:ext4:no --version-to SNAPSHOT
owut - OpenWrt Upgrade Tool 2024.10.27~8c7e42f0-r1 (/usr/bin/owut)
ERROR: ubus: Not found: Failed to invoke function 'packagelist' on object 'rpc-sys'
 from: 'ubus call rpc-sys packagelist { "all": true }'
This is a bug in 'owut/2024.10.27~8c7e42f0-r1', please report at
  https://github.com/efahl/owut/issues

In [anonymous function](), file /usr/bin/owut, line 103, byte 24:
  called from function [anonymous function] (/usr/bin/owut:240:58)
  called from function [anonymous function] (/usr/bin/owut:245:74)
  called from function collect_packages (/usr/bin/owut:964:69)
  called from function collect_all (/usr/bin/owut:1339:19)
  called from anonymous function (/usr/bin/owut:2025:15)

 `           `  ${issue_url}\n`);`
  Near here -------------------^

root@OpenWrt:~# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r28073-93d005e6bc'
DISTRIB_TARGET='armsr/armv8'
DISTRIB_ARCH='aarch64_generic'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r28073-93d005e6bc'
DISTRIB_TAINTS=''

[efahl]

ERROR: Sysupgrade type 'combined-efi' should be one of [ "combined", "rootfs" ]

Yeah, on current snapshot builds we're still dealing with that missing rpc call, but this one is something different for which I have not figured out a solution.

On x86, the existence of that /sys/firmware/efi/ directory determines whether you should use a combined or combined-efi image, but it appears not to do so on the armsr target. I need to get clarification from the devs as to why this is the case, and why there is no combined-efi image built for that target.

[efahl]

Now that I'm thinking about it, maybe it's some qemu setting??? I'm only familiar enough with it to copy-paste commands until they work, but I was wondering if there's an option that tells you to set up the VM as EFI-boot or bios-boot or something?

From the missing combined-efi, we can assume that OpenWrt thinks the armsr target will only be bios boot, so if there's a way to set "boot-mode" or whatever when creating the VM, that might be the proper solution (where "proper" == "easiest"), emulating the device as OpenWrt currently expects it...

[AlbrechtL]

[...] but I was wondering if there's an option that tells you to set up the VM as EFI-boot or bios-boot or something?

A bios mode (compared to x86) is not available on Arm targets. Arm devices are booting via device-tree (usually u-boot as bootloader) or via EFI. armsr stands for Arm SystemReady and is a generic image that boot on all devices that providing EFI-boot. I configured qemu to provide an EFI bios to boot the armsr image. So I don't think that this is a qemu specific issue. It should appear on all devices that are using this image. But armsr is quite new, for that reason you can't find much systems outside, currently. But this will change, for sure!

I need to get clarification from the devs as to why this is the case, and why there is no combined-efi image built for that target.

Great idea! The developers who are maintaining the armsr target should know it. What I can say is that the openwrt-armsr-armv8-generic-squashfs-combined.img images are only EFI, noting else.

[efahl]

Ask on IRC, no response, so reported it as https://github.com/openwrt/openwrt/issues/16966

[AlbrechtL]

Thanks for your efforts. Let's see how https://github.com/openwrt/openwrt/pull/12963 goes. Keeping names consistent is always a great idea.