Sysupgrade options in x86 with enlarged partitions?

Is there any option available for upgrading OpenWrt on x86 if your are using a different partition layout than the original image?
I'm running OpenWrt on Proxmox (QEMU virtualization), I just enlarged the original img and resized the sda2 partition to have a little bit more space and when I tried to do a sysupgrade with the generic-squashfs-rootfs.img.gz it didnt work:

root@openwrt02:/tmp# sysupgrade -T openwrt-21.02-snapshot-r16247-60fad8f82b-x86-64-generic-squashfs-rootfs.img.gz
Wed Jul 21 00:09:20 CEST 2021 upgrade: Image metadata not present
Wed Jul 21 00:09:20 CEST 2021 upgrade: Invalid image type

If I use the full generic-squashfs-combined.img.gz sysupgrade detects the partition layout has changed and insists on rewriting the whole disk image:

root@openwrt02:/tmp# sysupgrade -i -v  openwrt-21.02-snapshot-r16247-60fad8f82b-x86-64-generic-squashfs-combined.img.gz
Wed Jul 21 00:10:15 CEST 2021 upgrade: Image metadata not present
Wed Jul 21 00:10:15 CEST 2021 upgrade: Reading partition table from bootdisk...
Wed Jul 21 00:10:16 CEST 2021 upgrade: Extract boot sector from the image
Wed Jul 21 00:10:16 CEST 2021 upgrade: Reading partition table from image...
Wed Jul 21 00:10:16 CEST 2021 upgrade: Partition layout has changed. Full image will be written.

So there is no way to sysupgrade a x86 openwrt installation that doesnt have the same partition size as the original image?
Is there any other option, like copying the squashfs img manually?
I havent tried the ext4 variety but I suspect it will be the same...

1 Like

'no way' is a little absolute... there is no build-in/default way...

modify the default sizes with a buildroot (or imagebuilder .config) from day one...

1 Like

https://openwrt.org/docs/guide-user/installation/openwrt_x86#upgrading

3 Likes

I guess thats an option but it would mean building a new image for each new point version.
But I was talking about using official images, running the stable version as main home router on virtualized hardware and how to keep it up to date with the minimum effort.

I've tried to sysupgrade my system with enlarged sda2 partition with the generic-squashfs-combined.img.gz and the command posted above and the result was a working system with all my configs (just password, hostname and network) kept. I just get this messages in the log about overlay not formatted / initialized but like I say my config was kept.

[    6.128814] mount_root: rootdisk overlay filesystem has not been formatted yet
[    6.167074] random: mkfs.f2fs: uninitialized urandom read (16 bytes read)
[    7.087127] F2FS-fs (loop0): Found nat_bits in checkpoint
[    7.098682] F2FS-fs (loop0): Mounted with checkpoint version = 1c1c7bc5
[    7.104234] mount_root: overlay filesystem has not been fully initialized yet
[    7.106341] mount_root: switching to f2fs overlay
[    7.111553] overlayfs: "xino" feature enabled using 32 upper inode bits.
[    7.216135] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)

It only changed my sda2 partition and loop0 device to the original official img sizes.

BTW, why did the default img sizes were reduced in this release? Its less than half than previous versions

OpenWRT Software size
This is smaller than many embeded routers nowadays...

Why does sysupgrade insists on overwriting the partition table? If I understand it right, you have a boot partition, a squashfs partition and a f2fs loop device. Shouldnt it be designed to just write individual partitions instead of the whole raw image?

Thanks, I've read that, its an excellent guide, but I think it just covers ext4 sysupgrade right?

You can use imagebuilder to build your custom version of the official release.

Since you're using x86, I'd replaces squashfs with ext4.

It's easier to resize/manipulate, can be done while running, but requires a reboot.

I'm afraid the same error happens with ext4:

root@openwrt04:/tmp# sysupgrade -T openwrt-19.07.7-x86-64-combined-ext4.img.gz
Image metadata not found
Reading partition table from bootdisk...
Reading partition table from image...
Partition layout has changed. Full image will be written.

If partitions are modified sysupgrade stops in any case.

Incidentally I found it easier to enlarge the squashfs img, at least when installing from scratch, you just resize the sda2 partition and on first boot it seems the loop0 device is configured to use all the remaining space available for the f2fs overlay.

Regarding the loop0 device:

root@openwrt02:~# losetup
NAME       SIZELIMIT  OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0         0 4128768         1  0 /sda2       0     512

Is it posible to change the backing file from /dev/sda2 to a different partition with some config option or is it hardcoded when the system is first boot?

Well it seems there is no solution apart from building your own image :frowning_face:
It wouldnt be a big problem if the default images were not so small and inadequate for x86 hardware, and for 21.02 they were even halved in size for no apparent reason?
What's the logic for having the f2fs filesystem living in the same partition as the rootfs?
I understand this is desirable for embedded devices where you have to live within the constrained partition table set up by the manufacturer, but if you are free to use any partition layout like its the case in x86 wouldnt it make much more sense to put the f2fs filesystem on its own third "rootfs_data" partition (and given that its formatted on first boot it could be as tiny or large as the user desires)
instead of hiding it in the unused sectors of the rootfs partition that already has another filesystem?

1 Like

The default rootfs size is 256 MB (I believe it will be 128 MB in the future, though). What is "small and inadequate" about that? I'm going out on a limb and say that if you need packages that need so much space, you're probably looking into a full-sized linux distro anyway.

If it's only data you want to store, why not keep the default partitions, create an additional partition and mount it to where you need it? This is how my NAS boxen do.

1 Like

21.02 default images are already down to 104 Mb

Disk /var/lib/vz/template/img/openwrt-21.02.0-rc3-x86-64-generic-squashfs-combined.img: 121MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start    End      Size     Type     File system  Flags
        0.03MiB  0.25MiB  0.22MiB           Free Space
 1      0.25MiB  16.2MiB  16.0MiB  primary  ext2         boot
        16.3MiB  16.5MiB  0.25MiB           Free Space
 2      16.5MiB  120MiB   104MiB   primary

(parted)

Only about 39 Mb are available in f2fs

openwrt-2102-squashfs

With this kind of problems, your choice of distribution is likely suboptimal if not wrong.
To be frank, I also used OpenWrt on my main x86 router, but eventually replaced it with a general-purpose Linux distribution to extend functionality and minimize issues with maintenance and upgrades.

Hi,

If you are using Proxmox why don't you add another disk (sdb) and use that for whatever purpose you want? You can even opkg install -d <alt_root> pointing to that new disk. Any system upgrade will not impact this new disk.

58 MB used space seems excessive, I assume you already have some heavy packages installed there.

For comparison, the ext4 19.07 I run at the moment, already with several packages installed, just weighs in at ~30 MB:

root@Pogo:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               252.0M     29.8M    217.0M  12% /

Even so, I stand by my point: If, on x86, ~100 MB is not enough space for packages for you, realistically you are probably trying to replace a full blown Linux distro with OpenWrt. Which, you know, you can do, and I actually sympathize with the sentiment, but it's really not ideal.

But if you just want to store data, create another partition and mount it to where you need it. This way you retain sysupgrade functionality (worst case, if partition sizes change again, you have to recreate the partition data after sysupgrade, so it would be smart not to create the additional partition completely flush behind the default ones.)

Are there more detailed instructions for step 3 and 4?

Oof, what an old thread to resurrect.

I think at this point I would suggest a completely different method: Get the x86-64 imagebuilder, build an image (and maybe include the luci package for ease of use and to bring it up to par with a release image), and use the brand new ROOTFS_PARTSIZE parameter to extend the rootfs to whatever, 1024 (it's stated in megabytes) or so.

Latest version by @nc1 [HOWTO] Resizing root partition on x86 (March 2023 edition)

Inspecting an image (firmware) without installing - #2 by vgaetera

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.