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...
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
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?
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
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?
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.
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.
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.)
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.