I had tried to run OpenWRT as an Incus container about a year ago as my home lab’s router, and after a day or two of tinkering with it, I hit quite hard a dead end. I basically learned that OpenWRT in containers is a unviable setup and an extremely bad idea for many reasons.
Containers are ideal for user-land applications that are kernel agnostic and use a common kernel API, while a kernel itself belongs to a host and is shared among all containers, so containerized apps shall not do its heavy tweaking if any at all; otherwise, containerization is pointless.
OpenWRT is a router system where management apps configure kernel modules and network subsystems, expecting that the whole kernel is their exclusive responsibility. This violates a fundamental concept of containers “being a kernel agnostic” as it requires the host’s kernel to be modified beyond acceptable limits. As a result, I had a dozen issues related to missing modules in the kernel, like VPNs, PPP, tunnels, etc. All of them you must bring to the host kernel, and some of them even passthrough into a container, which is bad setup in many ways. Furthermore, OpenWRT does patching some modules for its own kernel, so using a host’s kernel with different modules may result in unpredictable behavior and bugs. Finally, I was unable to set up NTP client/server daemons as they require access to manage kernel’s time, and the kernel doesn’t allow this for containers out of security reasons.
At this moment Incus does not have OpenWRT VM images, and related activities are more than year in progress. Given that, I don’t see why OpenWRT as Incus container image should exist at all and confuse people, as it’s barely usable for real-world scenarios. It must be only in a form of a VM with its own isolated kernel.