Hello, I've been using the x86 version of OpenWRT for over 2 years now, and I always fear upgrades as they are tedious and very involved.
The two main issues are:
After upgrading, the space available for installs (the partitioning of the drive) is always returned to 100MB. Considering this is a computer, with a standard harddrive and not an EMMC or a chip, this should not happen.
So after every upgrade I need to manually expand the partition to fit the entire drive.
Suggestion: For the x86 branch, add a check to see what size the partition is before the upgrade, and just use that.
Packages: After an upgrade, even though I click on the save package list, all my packages are gone. For the last 2 upgrades, I manually connected with SSH to the router, ran a quick loop to save the list of installed packages to my computer, then after the upgrade ran another loop to reinstall them.
The config is saved, so my settings for these packages are fine, but I always have to reinstall them manually.
Suggestion: Fix or change the package list flow that exist, as it is clearly not working.
Thanks, and let me know if this needs to be in another category.
OW is not a standard distribution. It is designed for embedded devices with flash memory. X86 is a bit of a niche use case statistically given the thousands of devices that are flash storage.
To your point 1. I recommend that you compile your own image using an alternative rootfs size rather than expanding after the fact. For my x86/64 box, I use a custom value of 1024 MiB.
CONFIG_TARGET_ROOTFS_PARTSIZE=1024
For your point 2. I recommend that when you compile your own image, you add in the packages that you need so they will be part of your image as you wanted. Again, this is how the distribution is designed to work.
It is an optional package you can install and then execute via LuCI or CLI. It leverages the ASU servers to build a custom image containing all your packages, downloads it, and then uses the sysupgrade tool (natively built-in) to upgrade your system to the latest version, all while keeping your configurations, too.
i use on my x86 squashfs image on a small microsd where openwrt is on.
with owut you can configure to get a bigger rootfs size (maximum 1GB) which is more than enough for all my needed packages.
the "Data" is on an separate SSD which is just mounted extra.
to upgrade i only do
owut check
and then
owut upgrade
Thats all.
Why does it work for me?
Squashfs image safes the microsd card more or less from corruption (powerloss etc)
Extra internal SSD for Data which is independent from the OpenWRT image and is not affected by upgrade at all.
NOTE: The ASU server is down this week, so the following won't work (none of the ASU clients -auc, owut, LuCI app, Firmware Selector- will function properly) until it is restored.
That's been in the ASU server API for I think three years now. At present, owut is the only client that exposes it to the user. But, owut is only available on 24.10 and main snapshot, it can't be backported to 23.05 or earlier due to some major added functionality in 24.10 (ucode-mod-uclient).
Quick once over for keeping config, keeping installed packages, and increasing/retaining increased rootfs partition size:
Even if rootfs is not expanded to fill up the rest of the block device and you do something like manually creating an extra partition on the free space for something like an overlay (which I believe is not working yet on x86 ext4) or extra data storage, it would be missing after sysupgrade because the partition table is overwritten on the upgrade process back to the hardcoded original partitions, isn't it?
So disk space is wasted in any case...
No, it remains unless the kernel partition or the rootfs partition size changes. To defend against this, you can create the 3rd partition a number of blocks away from the rootfs partition.
I have pretty strong reservations about doing that at present, for a couple of reasons:
The ability to change rootfs partition size only applies to some targets, at least x86 and usually miniPC/SBC (arm, risc-v, loongarch?) ones, but it's not clear to me which ones. I have worked for a while now to figure out whether it applies using on-device info, but have failed so far. This is necessary so that users don't select it incorrectly and break their builds (ideally, if I could figure out how to detect it on-device, then the LuCI app could just show or hide the option on that device; likewise in owut, which is where I've been working on it to no avail).
Every time you change the rootfs size setting, it appears that sysupgrade can't find the stashed config backup (I suspect it's placed somewhere relative to the end of the original partition, so either gets wiped or lost in space with the bigger/smaller new one). This requires you to make an external back, do the sysupgrade and then manually restore your backup afterward (with access reverted to the default 192.168.1.1, so look out if you've changed it). I've been sporadically digging through the various platform-specific parts of sysupgrade for a couple months trying to figure out what's up and try to fix it, but no luck so far. This one is sort of the deal breaker for me wanting to expose it in LuCI right now, it's pretty fiddly and easy to miss those steps, then you end up with a ton of support questions...
Make an exception so it works for x86 only, which I imagine is >90% of the users looking to change partition size. If there's demand for other targets, they can be trivially added to the exception list in the future.
For now, don't change the Luci UI to expose this functionality. But if the target is x86, and that owut config is present, just silently pass it along.
I guess this is a somewhat narrow use case. But for someone who expands the rootfs partition using the command line and owut, this would make it so that using Luci for future upgrades doesn't inadvertently shrink the partition again. Cause that also generates support issues.
Add setting to LuCI advanced options - too much to explain in the GUI context, can't hide it for the 99% for which it won't work, etc, so just bury it.
Warn whenever rootfs size is non-default - too much noise and I don't want to be continually be answering the question "what does this mean?", "why does it warn me every time?" and so on.
Range validation in LuCI - assume that user has set it according to the documentation in owut, and has tested it with owut, so no validation needed. Also, server does its own validation, owut just does it redundantly to avoid seeing the build-time error.