On Sun, Jan 08, 2017 at 02:16:55PM +0100, Stefan Lippers-Hollmann wrote: > Using imagebuilder (and keeping the existing configs, which is the > default for sysupgrade) seems to tick all of your boxes, doesn't it? > not quite. obviously, wrapping the image builder into a script solves the upgrade problem i started out with, and is in fact functionally equivalent with the browser-based proposal i made (except that it requires expertize most "regular" users won't have). however, this thread is concerned with _interactive_ use. the idea is to make management of the device as comfortable as of a desktop system. the question how changes are committed to the device is of secondary concern from a user perspective.
On Sun, Jan 08, 2017 at 02:39:05PM +0100, Stefan Lippers-Hollmann wrote: > On the other end of the spectrum, high-end (mostly armhf based) devices > are starting to roll up the market with flash in the multiple hundreds > or even gigabyte regions[1], finally making full in-place upgrades and > on-device package management an option (only limited by opkg's abilities > and the in-place upgrade/ downgrade paths provided by the current > packaging practices (maintainer scripts, library versioning, etc.), so > for these you might even want/ need a(n even) more universal package > manager on the devices themselves). > packaging practices aren't a concern here. typically, an upgrade would start out with creating a new volume inside a CoW file system, doing all modifications inside it, and later switching to it atomically. the limiting factor here is the boot loader, as with the above model, the kernel needs to be within that file system if it's supposed to be covered as well. a less ambitious approach is deploying the kernel to separate ubi volumes, which is what is actually already being done by some devices. _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
