X86 long term strategy (upgradability with expanded storage)

My personal preferences:

  • squashfs, as that's the only option that would allow installing Docker without resizing partitions
  • a gap between the end of the stock partition and the beginning of the data partition
  • upgrades via attended-sysupgrade (and yes, Docker fits)
4 Likes
  • I am using the squashfs OpenWRT image on SD card, currently ignoring the unused SD space
  • ext4 on my 1 data serving SSD (1 large partition for OpenWRT hosted SAMBA 4)
  • without UPS. BIOS is set to autoboot on power reconnect, no issues so far, almost 2 years now since purchase
  • both Samsung and Sandisk offer extra durable SD cards with also a bit higher write throughout.
  • Sandisk USB SD adapter (i think it was the mobilemate)
2 Likes

I think this applies to any wifi router capable device that can boot off SSD/NVME/SDcard. I.e. a large amount of disk storage.
There are a number of different approaches to this:

  1. Install normal Linux OS such as debian and port luci and any other useful packages over to it.
  2. Have openwrt be installable on a SDD/NVME/SDcard and automatically expand itself to fill the storage space, much like the Raspberry PI install image does.

I think option 1 would probably be the approach that would work best for a majority of users.
openwrt is great when one is very limited on storage space, but when storage space is not so limiting, one could just install a Linux distro and install luci on top of it.
Has anyone tried porting luci to a normal Linux distro like debian?

I believe it needs more work than all the methods discussed so far in this thread combined so I'd say a strong NOGO

2 Likes

Yeah, you'd also need to adapt the init system, uci, ubus, waaaay too much other stuff. It would be easier to start with OpenWrt and change its approach to file system management.

Some people run openwrt in a container (in my case, I run it in a VM), so no need to really port luci to debian! :slight_smile:

1 Like

Hi,

@malahal

I assume by container you mean a docker image. Sounds good to me.
Please can you point me to a url / wiki on how to build a docker image with openwrt inside it.
Do you have a docker compose file for it?

[Guide] Run OpenWrt as a container in Proxmox. As far as I know, this isn't recommended method as openwrt may have some kernel features incompatible with host kernel. So I chose to run in a VM.

1 Like

Personally, I find the default 100MB partition size ludicrously small. One time I made the mistake of trying to install tailscale on my router ā€” imagine my surprise when my next firewall edit took down the whole network by truncating /etc/config/firewall to zero bytes! I had to connect the usually headless machine to a monitor and keyboard and copy the config from a flash drive.

I use the ext4 EFI image, and attended-sysupgrade works fine, but it's not safe for me to resize the ext4 partition: what happens if I make it bigger, then use more space, and then the next sysupgrade reverts the partition size like it did when I tried it in the past? If I were to use imagebuilder, I still wouldn't be able to use attended-sysupgrade. On top of that, it can't even be resized online: resize2fs: Invalid argument While trying to add group #3.

Please make the default partition size something bigger, such as 256MB* or 512MB! What sort of x86-64 device doesn't have at least that much disk space these days?

*Perhaps subtract a bit to leave room for the boot partition and the MB-vs-MiB difference.

3 Likes

I am little worried after reading this Tailscale story. I have once updated my x86 and then resized without problems. Now I have also installed Tailscale and everything is dependent on it. I hope I can update OpenWRT again.

I agree with this, though, it's GB now, not MB.
Also need a shutdown command.

I seem to recall reading that with the way things are built, the image files have to be the actual size of the filesystems they include. For the short term, best to keep the size something that's still easy to download, such as just under 1GB ā‰ˆ 0.93GiB total.

The true fix should be for the running OS to have a way to resize the filesystem, and keep it resized, for every type of image, even if you perform a sysupgrade. With modern multi-gigabyte drives, it ought to also allow you to use the rest of the drive for other partitions, without deleting them on sysupgrade. But that's more work than just making the images a reasonable size.

EDIT: Incidentally, there is no shutdown, but there is poweroff.

1 Like

True but compression should take care the download size over the internet.

1 Like

I have run OpenWRT in a container and VM on Proxmox. I did land on using it in a VM, as OpenWRT is very resource-light and I wanted the additional security that a VM provides. If a container had a bug that could be exploited to get root access to Proxmox, that could be very bad, and for an interface that is your firewall, having it in a VM gives another barrier to get through.

1 Like

Cameback here after two weeks since OP posted. After reading all the replies since, I still think upgrading x86 is a hot mess.

That's fairly hyperbolic. Upgrading itself is as straightforward as with any other target.

The only potential issue are additional partitions. While I agree that sysupgrade could benefit from mitigating it, that particular issue takes one command and about twenty seconds to prepare for and, in case it happens, a minute to rectify.

2 Likes

there were a few possibilities that others have presented here, and it ultimately depends on your needs and willingness to "work".
in my opinion, most of the users that have dedicated x86 running openwrt, have much more storage than the default images allow, for packages and data.
for these users one of these will work best:

  1. use ext4, create another "data" partition, monitor installed packages, build your own images (using imagebuilder, modifying CONFIG_TARGET_ROOTFS_PARTSIZE as needed (on a debian VM hosted on my N5105 openwrt machine, this takes 7-8 minutes), some more important info here)
    using this approach with enough space in the root partition, and a separate data partition, ensures subsequent upgrades will not delete the partitions (as mentioned, they should be the same between upgrades), and that the data partition can be used for whatever.
  2. same, but running openwrt from sdcard or usb storage, thus replacing the data partition with the entire ssd, but probably means you'd want the rootfs expansion script running after upgrade, to fill the sdcard.
  3. use squashfs, as it allows more packages without the need to resize the root partition, and a data partition (as mentioned), no need for imagebuilder.
  4. same, but running openwrt from sdcard or usb storage

.

some users have more powerful x86, and can run openwrt virtualized:

  1. as VM (under Proxmox or other host)
  2. as a docker container, but is not recommended

I feel this should be discouraged for most users, as it can present issues and build dangerous dependencies.
dedicated hardware is considered a more robust solution.

.

there are also these options:

  1. if your data is very dynamic (and you don't need to be persistent between upgrades), you can use the regular x86 ext4 partitions, and run the rootfs expansion script
  2. upgrades with fallback option - also documented in other forum posts (e.g. Sysupgrade help for x86_64 - #20 by grrr2)
  3. if your x86 box allows, use different drives (ssd) for the openwrt system and the data storage.
    in my opinion it's not a very good option - the openwrt system, with installed packages, probably won't take more than 1-2 GB in most cases. so this have to mean either drive will be very under utilized.

.

it does seem that there's no easy way out, and it'll definitely be a bigger issue as time goes by, and x86 boxes become a more populare choice for openwrt boxes

1 Like

Given the root partition size issues with x86-64 images, I'm actually considering buying a Traverse Ten64 (ARM64) to replace my x86-64 OpenWrt router.

Running OpenWrt as a VM guest seems like a house of cards, but Traverse's OpenWrt fork (ĀµVirt) is a VM host.

Given how much horsepower x86-64 machines have, I wish OpenWrt's x86-64 builds supported more sensible drive usage and some sort of LUCI-based VM management!

Thank you very much for this extensive description of alternatives. It is very useful for us X86 users. I just wonder, do we really need this many decisions and research before we can upgrade the most mission critical system at our homes. This is not for sissies.

unfortunately, seems so.. x86 users are apparently a (loud) minority, and I can understand the situation.
if you search for "x86 sysupgrade" in the openwrt forums you'll find many many posts, and most of them complain on the wiki (which is lacking on the subject).