Owut, sysupgrade and PARTUUID: Image check failed

Installing and Using OpenWrt
1

Do owut and/or sysupgrade examine the PARTUUID values when evaluating a host for an upgrade or checking for validity?

Context is a small x86_64 box (Dell Wyse 3040) running 25.12.4. Box is running well - I had done a standard dd install with the x86-64-generic-ext4-combined-efi.img.gzimage, but followed by a resize and few hiccups. Somewhere along the way, the PARTUUID on the rootfs got biffed and I had to recreate it ...

On my setup currently:

/dev/mmcblk1p1: PARTUUID="5c2fffbe-0205-272d-b7f7-1329ad7e6301" UUID="1234-ABCD"
/dev/mmcblk1p2: PARTUUID="802e7767-8088-2e23-7437-b1089064f702" UUID="ff313567-e9f1-5a5d-9895-3ba130b4a864"
/dev/mmcblk1p128: PARTUUID="5c2fffbe-0205-272d-b7f7-1329ad7e6380"

I'm aware that normally the PARTUUID values are predictable in relation to each other: the offsets from p1 to p2 to p128 are always 0x1 and 0x79 (decimal 1 and 127).

Is that p2 PARTUUID what is causing owut to choke when I try to download an upgrade, for instance?

root@AGH-DW3040:~# owut download
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         x86/64
Profile        generic
Package-arch   x86_64
Version-from   25.12.4 r32933-4ccb782af7 (kernel 6.12.87)
Version-to     25.12.4 r32933-4ccb782af7 (kernel 6.12.87)
15 packages are out-of-date
There are 0 missing and 1 modified default packages
Request hash:
  37409bb524d85199be6e565cd6325208a5821026a0f4b13ec0f3d6795448a86b
--
Status:   queued - 0 ahead of you
Progress:   0s total =   0s in queue +   0s in build
--
Status:   container_setup
Progress:   2s total =   0s in queue +   2s in build
...
Progress: 201s total =   0s in queue + 201s in build

Build succeeded in 201s total =   0s in queue + 201s to build:
Image saved : /tmp/firmware.bin
ERROR: sysupgrade validation failed:
stderr =
Thu May 21 14:05:28 CDT 2026 upgrade: Image metadata not present
Thu May 21 14:05:28 CDT 2026 upgrade: Unable to determine upgrade device
Image check failed.

Maybe p2 wants to be PARTUUID="5c2fffbe-0205-272d-b7f7-1329ad7e6302" ?

2

Is this that GPT partition table stuff?

Normal output from the checks is this, tested on a valid x86/64 image, so from your output it looks like it's croaking on the read partition table from the bootdisk, and hasn't gotten around to looking at the new image file yet...

$ sysupgrade --test /tmp/firmware.bin
Thu May 21 16:31:36 PDT 2026 upgrade: Image metadata not present
Thu May 21 16:31:36 PDT 2026 upgrade: Reading partition table from bootdisk...
Thu May 21 16:31:36 PDT 2026 upgrade: Extract boot sector from the image
Thu May 21 16:31:36 PDT 2026 upgrade: Reading partition table from image...
3

Yes, exactly.

It seems so...

Exactly right, Dave. Ya hit the nail on the head.

Yes, as soon as I went in w/ gdisk and changed the PARTUUID of /dev/mmcblk1p1 to the expected value... and mounted /dev/mmcblk1p1 & edited grub.conf there to agree, owut no longer complained.

For my own record, the UEFI on my little box lists the PARTUUID of p1... and grub.conf needs the PARTUUID of p2 in order to boot. Good learning experience.

Everything came together here, finally:

owut download      #   just build the image and download it; don't install yet
/etc/owut.d./no_serial_in_grubcfg.sh    # run my script to sed out serial-related stuff in grub.cfg
owut install       #   install and wait a minute or three ...

To be clear, what worked for @ikjadoon here [ Attended Sysupgrade: keep grub.cfg edits to prevent failed boots & physical keyboard commands every upgrade ] did NOT work for me. I ended up with mismatching PARTUUID's listed on the grub.cfg vs what blkid showed.

This also solves my other post here : [ Most Efficient way of customizing x86_64 install image - #16 by davygravy ]

Still, it is always a good idea to keep a copy of your current configuration, as well as the firmware.bin (with a time and version stamp on it) that you used to upgrade.

Of note, my script actually regenerates the firmware.sha256sums file as well - that seemed to be essential.