3 ms·

I'm not an OpenWrt developer either, but I was thinking about this recently (how to handle autoupdates on OpenWrt). How about if OpenWrt was running on a hyperv

I'm not an OpenWrt developer either, but I was thinking about this recently (how to handle autoupdates on OpenWrt). How about if OpenWrt was running on a hypervisor? It'd have to be small enough to fit in the EEPROM constraints, which probably rules out Xen, but KVM could work. With a hypervisor in place, you could install an image alongside a working one, then do a warm reboot to start the new image. The user would be presented with a website to confirm that they'd like to keep this new image. If the user doesn't confirm this within a fixed time period, the router would roll back to the old image. As for the space requirements for keeping two images on the router, I wonder if anything could be done there. For example, I wonder if the new image could be applied as a 'patch' on top of the old one, stored as file diffs rather than as a standalone image. Does that sound workable?

jlgaddis 11y ago
Your hypervisor scenario wouldn't work out, assuming auto-updates. What happens when the image is updated (automatically), the router reboots, and the user isn't aware of that (and, therefore, can't log into the web interface to "confirm" the update). It'd just get rolled back and reboot again. On another note, if I had something with a hypervisor available, I'd run something other than OpenWRT on it. The primary use case of OpenWRT is these small embedded devices where such a hypervisor isn't available.
- ZenoArrow 11y ago
  > " the user isn't aware of that (and, therefore, can't log into the web interface to "confirm" the update)." The website would be presented automatically to the user, similar to how a login page is displayed when you connect to some public WiFi networks. > "On another note, if I had something with a hypervisor available, I'd run something other than OpenWRT on it. The primary use case of OpenWRT is these small embedded devices where such a hypervisor isn't available." Yes, it'd almost certainly help with broadening the range of options. Until I realised I was too big I was drawn to the idea of using Xen as I'd like to see OpenMirage running on home router hardware, it seems like a natural fit. A minimal QubesOS image could also be good.

jlgaddis 11y ago

Your hypervisor scenario wouldn't work out, assuming auto-updates. What happens when the image is updated (automatically), the router reboots, and the user isn't aware of that (and, therefore, can't log into the web interface to "confirm" the update). It'd just get rolled back and reboot again. On another note, if I had something with a hypervisor available, I'd run something other than OpenWRT on it. The primary use case of OpenWRT is these small embedded devices where such a hypervisor isn't available.

ZenoArrow 11y ago
> " the user isn't aware of that (and, therefore, can't log into the web interface to "confirm" the update)." The website would be presented automatically to the user, similar to how a login page is displayed when you connect to some public WiFi networks. > "On another note, if I had something with a hypervisor available, I'd run something other than OpenWRT on it. The primary use case of OpenWRT is these small embedded devices where such a hypervisor isn't available." Yes, it'd almost certainly help with broadening the range of options. Until I realised I was too big I was drawn to the idea of using Xen as I'd like to see OpenMirage running on home router hardware, it seems like a natural fit. A minimal QubesOS image could also be good.