Thanks @efahl, it worked with apk --update-cache upgrade.
Amazing work!
Kr
K
1 Like
The fix got merged this morning in snapshot and backported to 24.10 branch, so this should be resolved in a day or two in main snapshot and 24.10-SNAPSHOT, and then on the next rev of 24.10 (-rc4 or .0 or whatever it ends up being...). The 24.10.0-rc[123] builds will have this issue forever, as they won't ever be rebuilt.
FWIW, just upgraded a BPI R4 from 24.10.0-rc2 to rc3 and a mt3000
Version-from 24.10-SNAPSHOT r28200-9f76cda378 (kernel 6.6.66)
Version-to 24.10.0-rc3 r28202-8667ca841b (kernel 6.6.66) DOWNGRADE
without any issues (later one expectedly needed --force but otherwise totally smooth).
AX6s seems not to be ready yet.
1 Like
I tried using owut on my Raspberry Pi 4 and version 24.10.0-rc4 today, and I have to say, fantastic job! Thanks, @efahl. Unfortunately, I am not seeing the expected output for rootfs_size='1024'.
Here's what I found when I ran the command:
# uci show attendedsysupgrade.owut
attendedsysupgrade.owut=owut
attendedsysupgrade.owut.verbosity='1'
attendedsysupgrade.owut.rootfs_size='1024'
However, when I check the disk usage with df -h, I get the following result:
Filesystem Size Used Available Use% Mounted on
/dev/root 30.3M 30.3M 0 100% /rom
tmpfs 928.0M 56.0M 872.0M 6% /tmp
/dev/loop0 223.8M 46.5M 177.2M 21% /overlay
overlayfs:/overlay 223.8M 46.5M 177.2M 21% /
/dev/mmcblk0p1 63.9M 19.0M 44.9M 30% /boot
tmpfs 512.0K 0 512.0K 0% /dev
/dev/sda1 119.5G 992.4M 118.5G 1% /opt
Surprisingly, when I run the command cfdisk /dev/mmcblk0, everything appears to be as expected. Have a look at the screenshot.
Additionally, when I try the command resize2fs /dev/loop0, I receive the following error message:
'resize2fs: bad magic number in super-block while trying to open /dev/loop0'
Interestingly, without the rootfs_size parameter, I can resize successfully.
Any help?
Merry Christmas!
No promises, as I'm not a file system gooroo, but we'll give it the old college try. 
The df output looks strange, it's more like what you'd expect with rootfs_size=256... Do you perchance happen to have the /tmp/firmware-manifest.json that was produced for this install? (Side note: you can stash them automatically with a pre-install script.)
I think resize2fs only works on ext4 file systems, so your error on a f2fs partition does not surprise me. Do you have fdisk installed? One of my test machines has a similar config (squashfs with bigger rootfs_size=512MB), here's what I see there:
$ df -h /overlay
Filesystem Size Used Available Use% Mounted on
/dev/loop0 491.4M 66.0M 425.4M 13% /overlay
$ fdisk -l
Disk /dev/loop0: 493.38 MiB, 517341184 bytes, 1010432 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
GPT PMBR size mismatch (1081887 != 488397167) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/nvme0n1: blah blah blah...
Device Start End Sectors Size Type
/dev/nvme0n1p1 512 33279 32768 16M Linux filesystem
/dev/nvme0n1p2 33280 1081855 1048576 512M Linux filesystem
/dev/nvme0n1p128 34 511 478 239K BIOS boot
Partition table entries are not in disk order.
Thank you for your reply, @efahl. You did a fantastic job avoiding the painful OpenWrt update, especially the remote updates.
Until now, I have been using the entire SD card capacity as the rootfs size, which in my case is about 56 GB. However, I now understand that this doesn't make much sense, and the provided 1 GB would be ideal.
I used resize2fs to resize the SquashFS as recommended here. Importantly, I can still do this if I download the firmware directly from OpenWrt. The issue only arises when I use owut.
Separately, someone needs to check the cached images because this morning, I tried the rootfs_size=256 variation, and every time I repeated the update, both of my RPi 4 devices installed the 256 MB images, even though I had requested the 1024 MB variation. After taking a break for a few hours, I magically received the 1024 MB version.
Please review the screenshot showing 1 GB, while the df command indicates only 256 MB.
Currently, I don't have the tmp/firmware-manifest.json, but I can collect it next time.
Finally, here is the output of my df command now:
# df -h /overlay
Filesystem Size Used Available Use% Mounted on
/dev/loop0 991.6M 74.3M 917.4M 7% /overlay
Kind regards from Germany.
This line from my fdisk output makes me wonder if rebooting fixes mismatches... I think I've seen odd partition sizes immediately after changing the rootfs_size, but I never kept track and I reboot/update so often that I'm sure I miss things.
1 Like
I have another fun issue on my Xiaomi Redmi AX6000 (using the non-stock layout, ie, ubootmod variant):
I originally rooted and flashed it using 23.05.5, then sysupgraded to 24.10.0-rc2 using the a releaseimage (not auc or owut). It's been good. Today I tried to upgrade it to 24.10.0-rc4 with owut.
owut seems to have successfully generated an image, the router rebooted, and ... came back with 24.10.0-rc2 (OpenWrt 24.10.0-rc2, r28161-ea17e958b9, kernel 6.6.63).
I tried owut download instead, then scp'ing the image and using sysupgrade from Luci with it, same result.
I tried downloading the image from the web browser and sysupgrading and same result, image URL is:
https://sysupgrade.openwrt.org/store/613e361ca4bf0ef501097a259249fd8a4a8aa4c7dbb0a688c1e6ab4016a50304/openwrt-24.10.0-rc4-b493cdd71979-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-squashfs-sysupgrade.itb
It just reboots and comes back with -rc2.
Is there a way to get some logs out of sysupgrade ? It really doesn't say much in ssh before it disconnects me and I don't have a serial port setup on this unit.
That sounds like a dual partition flash that's failing back to recovery mode. Or something???
The sysupgrade tool has the --test option, which does some stuff with fwtool to see if the image is valid.
Here's what it looks like on an x86 image, but it will probably be different for your target.
$ sysupgrade --test /tmp/firmware.bin
Wed Dec 25 17:32:26 PST 2024 upgrade: Image metadata not present
Wed Dec 25 17:32:26 PST 2024 upgrade: Reading partition table from bootdisk...
Wed Dec 25 17:32:26 PST 2024 upgrade: Extract boot sector from the image
Wed Dec 25 17:32:26 PST 2024 upgrade: Reading partition table from image...
The layout is:
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "BL2"
mtd1: 00040000 00020000 "Nvram"
mtd2: 00040000 00020000 "Bdata"
mtd3: 00200000 00020000 "Factory"
mtd4: 00200000 00020000 "FIP"
mtd5: 07a80000 00020000 "ubi"
root@OpenWrt:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mtdblock0 31:0 0 1M 1 disk
mtdblock1 31:1 0 256K 0 disk
mtdblock2 31:2 0 256K 0 disk
mtdblock3 31:3 0 2M 1 disk
mtdblock4 31:4 0 2M 1 disk
mtdblock5 31:5 0 122.5M 0 disk
ubiblock0_3 254:0 0 11M 0 disk
fit0 259:0 0 5.5M 1 disk /rom
And the command line is
console=ttyS0,115200n8 console_msg_format=syslog root=/dev/fit0 rootwait
I don't see anything about recovery in there. It's definitely my old image since it has things in it like lsblk that I installed manually with opkg.
sysupgrade --test doesn't show anything:
root@OpenWrt:/tmp# sysupgrade --test -v /tmp/openwrt-24.10.0-rc4-b493cdd71979-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-squashfs-
sysupgrade.itb
root@OpenWrt:/tmp# echo $?
0
root@OpenWrt:/tmp#```It must be something going on with sysupgrade, as your image looks fine inside. I downloaded it and extracted the rootfs with binwalk, shows that it's exactly what you think it is.
I'd suggest you start a new thread on this and get some wider visibility; see if anyone else with this device has any clue.
$ cd _openwrt-24.10.0-rc4-b493cdd71979-mediatek-filogic-xiaomi_redmi-router-ax6000-ubootmod-squashfs-sysupgrade.itb.extracted/squashfs-root/
$ cat etc/os-release
NAME="OpenWrt"
VERSION="24.10.0-rc4"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 24.10.0-rc4"
VERSION_ID="24.10.0-rc4"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r28211-d55754ce0d"
OPENWRT_BOARD="mediatek/filogic"
OPENWRT_ARCH="aarch64_cortex-a53"
OPENWRT_TAINTS=""
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt 24.10.0-rc4 r28211-d55754ce0d"
OPENWRT_BUILD_DATE="1734915335"
I apologize for my confusion regarding the OpenWrt file system. Thanks to @efahl and ChatGPT for explaining the issue.
When I download the firmware directly from OpenWrt, the /overlay partition is, by default, formatted as ext4. However, when I use owut, it is by default formatted as f2fs, which, as you mentioned, cannot be resized with resize2fs. I appreciate your patience while I sorted that out.
Now, my question is: is it possible to customize the /overlay partition type when using owut?
After reading about the pros and cons of f2fs and ext4, I realize that with my SD card setup, it makes more sense to stick with f2fs, even though resizing it isn't as straightforward as with ext4. I just want to know what my options are.
Thanks again 
Thanks, I've started Xiaomi Redmi AX6000 24.10 rc2->rc4 owut/upgrade problem
1 Like
Yes, you can choose the fstype from the command line (by default, it uses the value from the currently installed image).
$ ubus call system board | jsonfilter -e '$.rootfs_type'
squashfs
$ owut -h
...
-F/--fstype FSTYPE - Desired root file system type (squashfs, ext4, ubifs, jffs2).
$ owut download --fstype ext4
...
Be aware that not all fstypes are available on all platforms, you can try them out and owut will let you know:
$ owut download --fstype jffs2
owut - OpenWrt Upgrade Tool 2024.12.10~e38844ae-r1 (/usr/bin/owut)
ERROR: File system type 'jffs2' should be one of [ "ext4", "squashfs" ]
Oh, I should also add that it's probably best to put such things in the config file, so that any "non-standard" settings are applied by default on the device every time you download/upgrade.
$ tail /etc/config/attendedsysupgrade
config owut 'owut'
# option verbosity 1
# option keep true
option fstype 'ext4'
option rootfs_size 1024
I found the option in the owut documentation to select the root filesystem, as you mentioned earlier as well. Similarly, the /overlay filesystem can also be configured.
The SquashFS based root filesystem can have an /overlay filesystem configured as either f2fs or ext4.
The precompiled firmware image that can be downloaded directly from the OpenWrt website comes by default with the SquashFS + ext4 option. After updating with owut, the image is changed to SquashFS + F2FS.
Please take a look at the screenshot of the filesystem downloaded from OpenWrt. Additionally, I've included a screenshot of the image after updating with owut.
My question is: Is it possible to influence the configuration of the overlay filesystem (not the root filesystem) to use ext4 instead of f2fs or vice versa?
Like:
config owut 'owut'
# option verbosity 1
# option keep true
option fstype 'squashfs'
option overlay_fstype 'ext4' # <-- new
option rootfs_size 1024
Oops, my bad. I was completely unaware of the ability to select/change the overlay fs types.
Could you give me some links to more about this? Like, where that table came from... I've dug through the ToH entry, the downloads page, the Pi 4 Makefiles and several other places, can't find anything that would change the overlay fs.
I am also asking ChatGPT for help regarding the choice between F2FS and EXT4 for CONFIG_TARGET_ROOTFS_OVERLAY. If I have more information, I will share it here.
For F2FS:
CONFIG_TARGET_ROOTFS_PARTSIZE=256
CONFIG_PACKAGE_kmod-fs-f2fs=y
CONFIG_PACKAGE_f2fs-tools=y
For EXT4:
CONFIG_TARGET_ROOTFS_PARTSIZE=256
CONFIG_PACKAGE_kmod-fs-ext4=y
CONFIG_PACKAGE_e2fsprogs=y
I hope you can understand more than I do, as I am really new to this topic.
That appears to be a hallucination, as I have never seen it before and there is nothing in the repo with ROOTFS_OVERLAY.
In the OpenWrt Makefiles, when you pick a rootfs type, that determines what the working file system looks like. As far as I can tell, this is all there is in the repo:
$ grep TARGET_ROOTFS_ include/image.mk
fs-types-$(CONFIG_TARGET_ROOTFS_SQUASHFS) += squashfs
fs-types-$(CONFIG_TARGET_ROOTFS_JFFS2) += $(addprefix jffs2-,$(JFFS2_BLOCKSIZE))
fs-types-$(CONFIG_TARGET_ROOTFS_JFFS2_NAND) += $(addprefix jffs2-nand-,$(NAND_BLOCKSIZE))
fs-types-$(CONFIG_TARGET_ROOTFS_EXT4FS) += ext4
fs-types-$(CONFIG_TARGET_ROOTFS_UBIFS) += ubifs
fs-subtypes-$(CONFIG_TARGET_ROOTFS_JFFS2) += $(addsuffix -raw,$(addprefix jffs2-,$(JFFS2_BLOCKSIZE)))
ROOTFS_PARTSIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))
When you pick rootfs type = squashfs, then it makes an overlay and as far as I can tell, it's always f2fs.
When you choose rootfs type = ext4, there is no overlay (as there is no squashed /rom partition that needs overlaying), so you see something like this (from an x86 ext4 with default rootfs_size).
$ df -hT
Filesystem Type Size Used Available Use% Mounted on
/dev/root ext4 98.3M 82.3M 14.0M 85% /
tmpfs tmpfs 492.3M 41.1M 451.2M 8% /tmp
/dev/sda1 vfat 16.0M 6.2M 9.7M 39% /boot
/dev/sda1 vfat 16.0M 6.2M 9.7M 39% /boot
tmpfs tmpfs 512.0K 0 512.0K 0% /dev
I'm still trying to figure out how your 23.05.2 image was built with an ext4 overlay, since it looks like all current overlays are f2fs. I wonder if that has changed somewhere in the kernel config in the past couple of years or something.
As I mentioned early still the current stable 23.05.5 and 24.10.0-rc4 direct download by default comes with the ext4 overlay. Because I resized it yesterday with resize2fs successfully.
The f2fs comes into the play once you update with owut. I can post the screenshot tomorrow.