root@OpenWrt:~# fdisk --list
Disk /dev/sda: 1 GiB, 1073741824 bytes, 2097152 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0D61FAEB-DFC5-2FD9-CBC4-2C6C75394C00
Device Start End Sectors Size Type
/dev/sda1 512 33279 32768 16M EFI System
/dev/sda2 33280 2097118 2063839 1007.7M Linux filesystem
/dev/sda128 34 511 478 239K BIOS boot
Partition table entries are not in disk order.
Please do not get rude, because this is exactly why I am here, to find a way to get this thing going for long term (a.k.a. do my homework). It is not your call or place to say what I should or should not do regarding what services I offer.
If its any help this is what i get from fdisk --list
i also have the exact same error when trying to do an upgrade
Sat Mar 21 11:41:53 UTC 2026 upgrade: Image metadata not present
Sat Mar 21 11:41:53 UTC 2026 upgrade: Unable to determine upgrade device
root@OpenWrt:~# fdisk --list
Disk /dev/loop0: 1014.56 MiB, 1063845888 bytes, 2077824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: W800S 256GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A4A4C2F7-990C-4CD7-AEC9-EF2808CB481F
Device Start End Sectors Size Type
/dev/sda1 512 33279 32768 16M Linux filesystem
/dev/sda2 33280 2130431 2097152 1G Linux filesystem
/dev/sda4 497659904 500117503 2457600 1.2G Windows recovery environment
Regarding this, AI suggested to use gdisk to convert the partition type to EFI System, but this did not helped. Also, suggested to mount manually /dev/sda1 into /boot, this didn't helped either...
Let's see what the guts of the sysupgrade system is up to by running some of its internal functions. Save this as a script, diag.sh maybe, and chmod +x diag.sh, then run it. It should run to completion and tell us if anything is dying when trying to read the root partition. We may need to tweak some of the hard-coded values, but I think it should be ok as your fdisk output looks "normal".
#!/bin/sh
. /lib/functions.sh
. /lib/upgrade/common.sh
rootpart="$(cmdline_get_var root)"
echo "rootpart = $rootpart"
export_bootdevice
echo "major = $BOOTDEV_MAJOR"
echo "minor = $BOOTDEV_MINOR"
export_partdevice diskdev 0
echo "diskdev = $diskdev"
get_partitions "/dev/$diskdev" bootdisk
echo "partitions ="
cat /tmp/partmap.bootdisk
nblocks=$(awk '{n += $NF} END{print n}' /tmp/partmap.bootdisk)
nblocks=$(awk '{n = $NF} END{print n}' /tmp/partmap.bootdisk)
lbs=$(cat /sys/class/block/sda/queue/logical_block_size)
mb=$(ucode -p "$nblocks * $lbs / 1024.0 / 1024")
printf "%d @ %d = %d bytes = %s MiB\n" "$nblocks" "$lbs" $((nblocks * lbs)) "$mb"
Fair. I pointed out that if it's critical and you depend on it you should learn to use the image builder locally. (And don't offload your business costs on a public and free service, maybe. It also scales way better.)
1 Like
Well... not as expected, it has issues with reading partitions:
root@OpenWrt:~# ./diag.sh
rootpart = PARTUUID=7A24E933-5919-4152-9360-5BC86C53C2E9
major =
minor =
diskdev =
partitions =
cat: can't open '/tmp/partmap.bootdisk': No such file or directory
awk: /tmp/partmap.bootdisk: No such file or directory
awk: /tmp/partmap.bootdisk: No such file or directory
Syntax error: Expecting expression
In line 1, byte 2:
` * 512 / 1024.0 / 1024`
^-- Near here
sh: invalid number ''
0 @ 512 = 0 bytes = MiB
Sorry if i am hijacking the topic but i get the same output
rootpart = PARTUUID=027c1c40-fda5-5045-c667-d5f9d1e14c02
major =
minor =
diskdev =
partitions =
cat: can't open '/tmp/partmap.bootdisk': No such file or directory
awk: /tmp/partmap.bootdisk: No such file or directory
awk: /tmp/partmap.bootdisk: No such file or directory
Syntax error: Expecting expression
In line 1, byte 2:
` * 512 / 1024.0 / 1024`
^-- Near here
sh: invalid number ''
0 @ 512 = 0 bytes = MiB
You are not hijacking, you are confirming findings on your end... Thank you for contributing here with your input.
1 Like
According to AI, the export_bootdevice() function does not determine correctly the boot partition because it looks at "The GPT Header field: Disk GUID at offset 568" not at partition UUID, so it will never match.
I have made this script to dump partitions guids:
#!/bin/sh
disk="${1:-/dev/sda}"
base_offset=1024 # LBA 2 * 512
entry_size=128
max_entries=128 # typical GPT
i=0
while [ $i -lt $max_entries ]; do
entry_offset=$(( base_offset + i * entry_size ))
# read Unique Partition GUID (16 bytes at offset +16)
guid_raw=$(dd if="$disk" bs=1 skip=$((entry_offset + 16)) count=16 2>/dev/null \
| hexdump -v -e '16/1 "%02x"')
# stop if entry is empty (all zeros)
[ -z "$guid_raw" ] && break
[ "$guid_raw" = "00000000000000000000000000000000" ] && {
i=$((i+1))
continue
}
# convert from GPT mixed-endian to standard GUID
g1=${guid_raw:6:2}${guid_raw:4:2}${guid_raw:2:2}${guid_raw:0:2}
g2=${guid_raw:10:2}${guid_raw:8:2}
g3=${guid_raw:14:2}${guid_raw:12:2}
g4=${guid_raw:16:4}
g5=${guid_raw:20:12}
printf "Partition %d PARTUUID: %s-%s-%s-%s-%s\n" \
$((i+1)) "$g1" "$g2" "$g3" "$g4" "$g5"
i=$((i+1))
done
and... surprise... the root partition GUID matches partition 2....
root@OpenWrt:~# ./dumpguids.sh
Partition 1 PARTUUID: 0d61faeb-dfc5-2fd9-cbc4-2c6c75394c01
Partition 2 PARTUUID: 7a24e933-5919-4152-9360-5bc86c53c2e9
Partition 128 PARTUUID: 0d61faeb-dfc5-2fd9-cbc4-2c6c75394c80
maybe the library function is wrong...
1 Like
This is my output from your script
Partition 1 PARTUUID: 027c1c40-fda5-5045-c667-d5f9d1e14c01
Partition 2 PARTUUID: 027c1c40-fda5-5045-c667-d5f9d1e14c02
Partition 4 PARTUUID: 2ef6f22f-7626-4c5d-93d3-e4453c2fedfd
Hmm, not sure how that could be, it's been working for like 10+ years on all sorts of devices...
Here's from a sata HD on an apu2 running 25.10.0:
rootpart = PARTUUID=83beaead-02
major = 8
minor = 0
diskdev = sda
partitions =
1 512 32768
2 33792 212992
212992 @ 512 = 109051904 bytes = 104.0 MiB
And from an EFI N5105 miniPC with an nvme drive running 25.12-snapshot:
rootpart = PARTUUID=33e0c92d-f7b7-f3fd-b717-9e1bbe4dfe02
major = 259
minor = 0
diskdev = nvme0n1
partitions =
1 512 32768
2 33280 1048576
And a Hyper-V VM running 24.10-snapshot:
rootpart = PARTUUID=0bf605d0-65dd-058c-3548-b83d11220202
major = 8
minor = 0
diskdev = sda
partitions =
1 512 32768
2 33280 212992
212992 @ 512 = 109051904 bytes = 104.0 MiB
Thanks to the provided scripts I have dig around commands and disk layout and I asked AI a bunch of questions.... I figured that the root issue is that (according to AI because I am not that smart about this):
OpenWrtâs GPT layout intentionally makes the boot partitionâs PARTUUID share the same base GUID as the disk GUID, and that is exactly why
export_bootdevice()strips the last two hex digits and compares against the disk GUID, not the partition GUID. This is not a bug â itâs a design choice in the OpenWrt image builder.
And if you look at my partitions GUID the second is not the same as fist but with
"2" at the end but something else:
Disk GUID : 0D61FAEB-DFC5-2FD9-CBC4-2C6C75394C00
partition 1 PARTUUID : 0d61faeb-dfc5-2fd9-cbc4-2c6c75394c01
partition 2 PARTUUID : 7a24e933-5919-4152-9360-5bc86c53c2e9 << outlier!
Partition 128 PARTUUID: 0d61faeb-dfc5-2fd9-cbc4-2c6c75394c80
So I did this, WARNING! those steps can brick your device! :
root@OpenWrt:~# apk add gdisk
root@OpenWrt:~# sgdisk -p /dev/sda
Disk /dev/sda: 2097152 sectors, 1024.0 MiB
Model: Virtual Disk
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 0D61FAEB-DFC5-2FD9-CBC4-2C6C75394C00 << This is what I need
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 2097118
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 512 33279 16.0 MiB EF00
2 33280 2097118 1007.7 MiB 8300 << And this is my root partition
128 34 511 239.0 KiB EF02
Update the 2nd partition guid to the format expected by OpenWRT (replace last 2 digits of disk GUID with the partition number, so 2 => 02):
root@OpenWrt:~# sgdisk --partition-guid=2:0D61FAEB-DFC5-2FD9-CBC4-2C6C75394C02 /dev/sda
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Validate that the GUID is actually changed:
root@OpenWrt:~# sgdisk -i 2 /dev/sda
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 0D61FAEB-DFC5-2FD9-CBC4-2C6C75394C02 << Yup, it is changed
First sector: 33280 (at 16.3 MiB)
Last sector: 2097118 (at 1024.0 MiB)
Partition size: 2063839 sectors (1007.7 MiB)
Attribute flags: 0000000000000000
Partition name: ''
Then... you need to update grub.config... or you have a soft-brick now! (you can still boot manually if you have access to the boot console and press e to edit the boot params and fix them in order to boot, but this is a one-shot, not a persistent solution)
Step 1: mount the boot drive:
mkdir -p /boot;mount /dev/sda1 /boot
Step 2: use your favorite text editor to open it:
root@OpenWrt:~# mcedit /boot/boot/grub/grub.cfg
And replace the PRTUID GUID with the one for the partition (the one ending in 02)
Then reboot...
Then magic... diag script works:
root@OpenWrt:~# ./diag.sh
rootpart = PARTUUID=0d61faeb-dfc5-2fd9-cbc4-2c6c75394c02
major = 8
minor = 0
diskdev = sda
partitions =
1 512 32768
2 33280 2063839
2063839 @ 512 = 1056685568 bytes = 1007.7338867188 MiB
Since currently the build server is out of disk space, I cannot test the upgrade at this point, but I will edit or post a reply as soon as I have the results of that.
@machmandp your partition's GUIDs seem fine (01 and 02) but the disk GUID is not (yours is A4A4C2F7-990C-4CD7-AEC9-EF2808CB481F instead of 027c1c40-fda5-5045-c667-d5f9d1e14c00) so in your case the above steps may not help you. Probably the best for you is to just change the GUID of the disk to the expected one with 00:
sgdisk --disk-guid=027c1c40-fda5-5045-c667-d5f9d1e14c00 /dev/sda
reboot
this will match the expected values... But again, this is dangerous and make sure you have a bare metal backup first... I would wait for other, smarter people, to confirm those actions...
Thx will do
Changing the partition UUID to expected one (same as disk's GUID but with 02 at the end) solved the issue...
Upgrade log
root@OpenWrt:~# owut upgrade -v
owut - OpenWrt Upgrade Tool 2026.03.30~670907a5-r1 (/usr/bin/owut)
ASU-Server https://sysupgrade.openwrt.org
Upstream https://downloads.openwrt.org
Target x86/64
Profile generic
Package-arch x86_64
Root-FS-type ext4
Sys-type combined-efi
Version-from 25.12.1 r32768-b21cfa8f8c (kernel 6.12.74)
Version-to 25.12.2 r32802-f505120278 (kernel 6.12.74)
Build-commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=f505120278
Build-FS-type ext4
Build-at 2026-03-25T20:09:53Z (~12 days ago)
Image-prefix openwrt-25.12.2-x86-64-generic
Image-URL https://downloads.openwrt.org/releases/25.12.2/targets/x86/64
Image-file openwrt-25.12.2-x86-64-generic-ext4-combined-efi.img.gz
Installed 284 packages
Top-level 163 packages
Default 44 packages
User-installed 120 packages (top-level only)
Package version changes:
base-files 1696~b21cfa8f8c 1699~f505120278
kmod-ovpn-dco-v2 6.12.74.0.2.20250801-r1 6.12.74.0.2.20251017-r1
2 packages are out-of-date
Default package analysis:
Default Provided-by
nftables nftables-json
There are currently package build failures for 25.12.2 x86_64:
Feed: packages
domoticz Sun Apr 5 19:37:49 2026 - not installed
pigeonhole Sun Apr 5 19:52:15 2026 - not installed
python-constantly Sun Apr 5 19:15:11 2026 - not installed
python-flask-httpauth Sun Apr 5 19:46:58 2026 - not installed
python-gevent Sun Apr 5 19:43:05 2026 - not installed
python-psycopg2 Sun Apr 5 19:16:56 2026 - not installed
python-pyodbc Sun Apr 5 19:45:03 2026 - not installed
python-ubus Sun Apr 5 19:18:02 2026 - not installed
tvheadend Sun Apr 5 19:03:19 2026 - not installed
Feed: telephony
asterisk-chan-sccp Sun Apr 5 20:18:31 2026 - not installed
Feed: video
assimp Sun Apr 5 17:30:05 2026 - not installed
glslang Sun Apr 5 17:30:29 2026 - not installed
qt5base Sun Apr 5 20:03:42 2026 - not installed
qt5quick Sun Apr 5 20:03:41 2026 - not installed
qt5quick-controls Sun Apr 5 20:03:51 2026 - not installed
qt5script Sun Apr 5 20:03:41 2026 - not installed
qt5svg Sun Apr 5 20:03:41 2026 - not installed
qt5translations Sun Apr 5 21:05:40 2026 - not installed
qt5virtualkeyboard Sun Apr 5 21:05:40 2026 - not installed
vkmark Sun Apr 5 19:54:53 2026 - not installed
20 package build failures don't affect this device, details at
https://downloads.openwrt.org/releases/faillogs-25.12/x86_64/
Request:
Version 25.12.2 r32802-f505120278 (kernel 6.12.74)
ROOTFS_PARTSIZE set to 1007 MB
Request hash:
957cf1d761338026016eea9550aca0dadd9fe738231c310ff4386b084ff6e2ee
--
Status: started - validate_manifest
Progress: 0s total = 0s in queue + 0s in build
--
Status: validate_manifest
Progress: 3s total = 0s in queue + 3s in build
--
Status: building_image
Progress: 207s total = 0s in queue + 207s in build
--
Status: done
Progress: 209s total = 0s in queue + 209s in build
Build succeeded in 209s total = 0s in queue + 209s to build:
version_number = 25.12.2
version_code = r32802-f505120278 (requested r32802-f505120278)
kernel_version = 6.12.74
rootfs_size_mb = 1007
init-script = no-init-script
Image source: https://sysupgrade.openwrt.org/store/957cf1d761338026016eea9550aca0dadd9fe738231c310ff4386b084ff6e2ee/openwrt-25.12.2-6210d853f264-x86-64-generic-ext4-combined-efi.img.gz
Image saved : /tmp/firmware.bin
Manifest : /tmp/firmware-manifest.json
Verifying : /tmp/firmware.bin (22818658 bytes) against /tmp/firmware.sha256sums
Saved sha256 matches
Mon Apr 6 12:44:07 EEST 2026 upgrade: Image metadata not present
Mon Apr 6 12:44:07 EEST 2026 upgrade: Reading partition table from bootdisk...
Mon Apr 6 12:44:08 EEST 2026 upgrade: Extract boot sector from the image
Mon Apr 6 12:44:08 EEST 2026 upgrade: Reading partition table from image...
Mon Apr 6 12:44:08 EEST 2026 upgrade: Partition layout has changed. Full image will be written.
Checks complete, image is valid.
Installing /tmp/firmware.bin and rebooting...
root@OpenWrt:~# Connection to openwrt closed by remote host.
Connection to openwrt closed.
Bare in mind that I did changed the root partition size in config (/etc/config/attendedsysupgrade), the partition is OK in size (smaller, rounded down to 1007 MB), but there is an issue reported by fdisk:
root@OpenWrt:~# fdisk --list
GPT PMBR size mismatch (2095648 != 2097151) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/sda: 1 GiB, 1073741824 bytes, 2097152 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 60C863B3-8834-3F8A-8F5E-C8F39BB10200
Device Start End Sectors Size Type
/dev/sda1 512 33279 32768 16M Linux filesystem
/dev/sda2 33280 2095615 2062336 1007M Linux filesystem
/dev/sda128 34 511 478 239K BIOS boot
Partition table entries are not in disk order.
To fix that:
root@OpenWrt:~# fdisk /dev/sda
w << write to disk
Summary of fixing this issue
(WARNING: you may brick your device!)
- ran the
diag.shscript above > confirmed that the tools can't find the drive - ran
fdisk --listand noted down the disk GUID - ran my partition UUID dumping script (could be done with other tools like
sgdisk) and printed the partitions UUIDs - compare the disk GUID which must end with "00" and partitions GUID which must end with the hexadecimal partition numbers "01", "02" etc. and noted outlier for partition 2
- used
sgdiskto change the outlier partition UUID to the expected one (in this case ending with "02") - since I changed the partition identifier, I had to update grub config to match
- rebotted to have the right data in memory
- upgrade to latest version
- checked
fdiskand fixed GPT PMBR size mismatch, which I expect not to show up in subsequent upgrades, as previously the partition was not an exact multiple of MB in size.
On the other hand, machmandp had an issue with the disk's GUID which was different than the partitions UUIDs which were correct (ending with "01" and '02"). sgdisk can change the disk's GUID too to align, in this case there is no need to alter grub config. I do not know the upgrade success for machmandp, but for me this fixed it.
I will try today , just need to get everyone off the net for a while and ill report back
Thanks
It is all thanks to @efahl who did provided very useful feedback and investigation directions.
Couldn't do it without that input, so the help is very much appreciated. Thank you from the bottom of my 
!
It is things like those type of conventions that are unknown to clueless users and throws them offtrack easily... But I understand why the convention is there (things have to be simple and have small code footprint to fit in limited router storages) and I did learned something very useful to me (playing with GPT tools safely, fixing GRUB boots etc.).
I ran the command
sgdisk --disk-guid=027c1c40-fda5-5045-c667-d5f9d1e14c00 /dev/sda
Rebooted and then did an attended sysupgrade from Luci and that worked
so im now on OpenWrt 25.12.2 r32802-f505120278 / LuCI openwrt-25.12 branch 26.094.61984~16167c7 and my packages and configs are all intact including the 1gb root size
Thanks for all the help very happy that i can now just upgrade easily
3 Likes
Excellent sleuthing, guys, thanks for figuring out the root cause. I'll see if I can find some appropriate place in the wiki (suggestions welcome!) to document this, as I'm sure I'll forget in short order...
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.