In theory, OpenWRT should work reasonably well with OSTree – it’s already designed to be run with an immutable base layer (for squashfs images).
In terms of adapting OpenWRT to run on OSTree, the hardest thing I can think of would be working out how to do the bootloader on embedded devices. I don’t know enough about this space to know what has to be done here. OSTree currently works by putting kernel images and BootLoaderSpec config files into a boot directory, swapping symlinks to switch between them. It can then run extra code to transform that config to a different format, e.g. Fedora Silverblue generates GRUB2 configuration. This last configuration transformation step is the only potentially non-atomic part of the update.
Other than that, some changes needed would be boot script integration for mounting the OSTree root (an overlay fs is not used, since /etc is writable), filesystem layout adjustments (/usr merge, and a wrapper for opkg (opkg-ostree?) that does package installs via an OSTree layer, similar to how rpm-ostree works on Fedora Silverblue.
Much of the existing system upgrade tooling would no longer be needed, since OSTree already preserves /etc (and would preserve /var if it was a real directory rather than symlink to /tmp) during upgrades. The process would be to download the new base image, rebuild the opkg-ostree layer with locally-installed packages, and reboot.
That said, OSTree also requires better storage than is present in many of the older embedded devices that OpenWRT supports – you need enough space for multiple images (albeit common files are shared with hardlinks), and all of the updates are done at the file level, so it has to handle a fair amount of small file writes properly. I run OpenWRT on an x86-64 box with a modern SATA SSD, which would have no issue. It looks like many newer router/ap platforms support eMMC flash, which should work well (maybe use F2FS filesystem).
Leave a Reply