X86 long term strategy (upgradability with expanded storage)

I know there are a lot lof topics on the sysupgrade of x86 openwrt.
I've read many of them, but I'm still trying to understand how one should really setup and use their x86 openwrt, in regards to long term upgradability, whilst fully utilizing the SSD storage.
I bought an x86 device because I wanted the main router to be futureproof with high performance.
the x86 devices usually come with quite a substantial SSD storage, for various use cases.
taking all of this under consideration, what should be the strategy of storage type (ext4, squashfs), or partitioning, to allow for easy future sysupgrade of the x86 device?

this topic mentions possible solutions for x86 devices with expanded root partition, but that setup is still far from being the easy sysupgrade route, because even with attented sysupgrade taking care of the packages (and the auto reize script taking care of the root partition resize), one should still copy the data (e.g. docker container data) before the sysupgrade, and restore it afterwards, and as the data grows, this will be a bigger issue.

creating another partition means that there's no easy sysupgrade according to the docs, since the only partition preserving options require extracting boot partition image, etc.

so what's the win-win strategy?

2 Likes

DIY

this is my setup, if this is good for you or being future proof i don't know ... anyhow:

i am using ext4 image. which i built with imagebuilder to have a 512MB root partition instead of the default 106MB. i have two ( ! ) root partitions as you can see below

# lsblk
NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda        8:0    0 119.2G  0 disk
├─sda1     8:1    0    16M  0 part /boot
│                                  /boot
├─sda2     8:2    0   512M  0 part /   # <- active root partition
├─sda3     8:3    0   512M  0 part     # <- inactive root partition
├─sda4     8:4    0 118.2G  0 part /storage/opt/docker # <- this is fixed partition
│                                  /storage            # <- mounted as /storage and also used by docker, but it is preserved between switching root or upgrade
└─sda128 259:0    0   239K  0 part

the first root partition is created when i dd the ext4-combined image, and i create the 2nd root partition manual afterwards and format to ext4 as well. then i can install the rootfs image onto it.

this way i can easily do upgrades with fallback option as rootfs image can be for different version, only have to copy the related kernel to /boot and modify the /boot/grub/grub.cfg accordingly. i also immediately change grub.cfg after install to use partition numbering instead of UUID. e.g.

menuentry "OpenWrt - 23.05.2 - sda2" {
        linux /boot/openwrt-23.05.2-x86-64-generic-kernel.bin root=/dev/sda2 rootwait   console=tty0 console=ttyS0,115200n8 noinitrd
}
menuentry "OpenWrt - 23.05.0 - sda3" {
        linux /boot/openwrt-23.05.0-x86-64-generic-kernel.bin root=/dev/sda3 rootwait   console=tty0 console=ttyS0,115200n8 noinitrd
}
5 Likes

I use image builder to create an image with all packages. The first time, you have to boot from a live Ubuntu or something similar, unzip and burn the sysupgrade image to SSD. Then it is just a regular sysupgrade.
The additional space is partitioned and mounted from fstab. As long as OpenWrt partitions do not change, you additional partition is safe.

as data drive? or for more opkg packages?

does specifying the root partition size prevent existing the data from being deleted?

I've read about the dual partitions option, but can you explain please how do you perform the upgrades?

reading the docs for x86 upgrading, it only says that:

The last two options require more steps to execute but have the advantage of leaving the Master Boot Record and partition table intact. This preserves the boot, rootfs, and any extra partitions you may have added.

meaning using regular sysupgrade (even if all openwrt partitions sizes left as default) do not preserve any additional partitions, no?

.

both actually, also docker container data

I am in the same situation as you. I love everything about OpenWRT except for the upgrade process. It is so inconvenient. I've installed mine a month ago and already there are tons of updates. You would think that running OpenWRT x86 would be the easiest and most flexible but ironically it isn't.

1 Like

usually you can upgrade by using sysupgrade tool, which roughly does the following:

  • deploy a new image file,
  • keep settings (=configuration files) but no additional packages.

deployment is basically writing the image file onto disk, with whatever the image is, not doing any smart check or respecting any manual changes you have done in partitioning. it simply overwrites partition layout and size with the content of the image file.

while it does overwrite the regular first two partitions (boot + root) but otherwise leaves the disk content as is, so partition management tools still can recover your extra partition with their content intact.

but as the default image size imho is much smaller than should be for an x86 host, as i said am using the imagebuilder to resize the image file (/root to 512MB in my case) and as part of image build process not just the ext4-combined file is created (which includes the /boot and /root as well) but also rootfs image (just /root) is created. then i can deploy the latter onto my inactive partition.

which gives me a fresh new basic system but i can mount this inactive filesystem (as it is too an ext4) and copy over my settings, plus copy the new kernel to /boot & updated grub.cfg. then reboot. and voila i have a new owrt with my old settings.

1 Like

It does on the subsequent updates. The sys upgrade process verifies that the partition schema on SSD matches the one in the sys upgrade image and does not alter it. It only updates the partition contents.

sounds like options 3/4 from the docs, but still that's not as easy as I'd like (comparing not non x86 openwrt)

.

so this should be the best approach (or attented sysupgrade for also keeping packages) while it's the most discouraged option in the docs - why?
do you use this approach? is your second partition intact after sysupgrades?

Honestly and with all due respect, how many time does the same question need to be answered?..

with all due respect, if the same questions gets asked so many times (which question is that btw?), it's probably poorly answered or documented....
I'm not really bored to open redundant topics... anyway I do appreciate your response so would still like to know practically -

before I take the leap (right now my x86 installation is on 22.03), because I didn't see many posts mentioning this upgrade path on x86 and the extra partition docs say:

But attention must be taken for future upgrades. If extra partitions are added, you cannot use -combined.img.gz images anymore, because writing this type of image will override the drive's partition table and delete any existing extra partition, and also revert boot and rootfs partitions back to default size.

and the general sysupgrade docs don't mention other partitions at all.

from what I gathered so far, it seems that a typical x86 openwrt installation nowadays with standard storage (128GB plus?) should:

  • use imagebuilder, or post install script, to resize root to 512MB or so
  • upon first boot create the "data" partition, which should stay intact when:
  • use imagebuilder/attented sysupgrade for sysupgrades, maintaining settings and packages
3 Likes

I believe that section is both confused and confusing. Sysupgrade (at least of a somewhat recent OpenWrt version) resets the partition table only if the boot and rootfs partitions differ. If they are the same in the new version, their contents will be replaced but the partition table stays intact -- including any additional partitions.

And even if the partition table has been reset, additional partitions can be restored by re-inserting them into the partition table. That's why one should always take down the partition cornerstone data before sysupgrading.

I generally recommend additional partitions not to start completely flush to the rootfs partition, so there's some leeway for future expansion of the default partitions. This hasn't happened yet, in fact the rootfs size shrunk in one of the recent releases, but the default partitions' sizes should be regarded as somewhat volatile. Personally, I start additional partitions a gigabyte into the drive, it's a nice even number.

3 Likes

I don't run an x86 openwrt but would probably use different disks for root and data if internal connectors allow it or run the root off an microsd or usb stick with regular backups or better with psu in a ups to minimize sd/usb corruption

thanks for clarifying!

what do you mean "take down the partition cornerstone data before sysupgrading"? (why should you do anything, if one line earlier you wrote that the partition can be restored if the partition table is reset?)

.

I run openwrt from a compact mini-PC with passive cooling, and the NVME runs hot even with heatsink and reasonable ambient temp exposure, so adding another air blocking SATA disk is discouraged.
depending on the USB stick, it might stand out too much, but a micro sd could be a valid solution.

seems to me, that an external partition with a custom, big enough, root partition should allow the sysupgrade with minimal effort over a few years at least.
the only downside I see, is that I'll need to manually create the sysupgrade images going forward, unless there's an option to specify CONFIG_TARGET_ROOTFS_PARTSIZE on the online imagebuilder frontend

Just keep a copy of the output of fdisk -l /dev/sdx.

To restore a partition you need to recreate its partition table entry with the exact same values: start sector, end sector, and partition type.

1 Like

My personal preference for this is, to boot OpenWRT from an USB-attached SD card and use the device SSD exclusively for data. That way, any OpenWRT update does not risk messing with my data disk partition table. I can also have a new version on a different SD card without touching the existing setup. USB sticks work as well, but often tend to be of less quality, also might want to check your BIOS for possible boot options.

2 Likes

Any issues during power outages? What about filesystem ext4 or squashfs? Do you have a ups? Hopefully I'm not out of topic with my questions