[LEDE-DEV] Support for more than a single overlay, which is selected at boot time

Philip Prindeville philipp_subx at redfish-solutions.com
Wed Mar 8 20:04:45 PST 2017


> On Mar 7, 2017, at 6:15 AM, Jurgen Van Ham <juvanham.tc at gmail.com> wrote:
> 
> Hi all,
> 
> I want to support multiple (currently just two) configurations on a
> single device. One of these configurations is chosen at boot time.
> Instead of saving and restoring the configuration each time, I came up
> with a solution that relies on extending the overlay by splitting it
> into two banks. There can be more than two, but I only need two called
> 'bank_0' and 'bank_1'
> 
> This relies on splitting the overlay file system into two (or more)
> different banks, which are implemented as directories in the root of
> the overlay file system. Separate file systems would require a
> decision how to split the size of the single overlay into two overlays
> that do not always have the same size.

Um…. maybe I’m missing something but you could also have:

/etc/config1/
/etc/config2/

and have /etc/config/ be a symlink to ../config1 or ../config2.

Or is that too simple to possibly work?

-Philip


> 
> Until now the writable /overlay (jffs2 or other) partition is mounted
> as the upperdir over the /rom squashfs partition as its lowerdir.
> Instead, I consider to replace this /overlay mount by the subdirs
> /overlay/bank_1 or /overlay_bank_2 by modifying the code of mount_root
> from the fstools package.
> 
> The mount_root program read the environment variable 'OVERLAY_BANK'
> that is set by modifying two files:  /lib/preinit/80_mount_root' and
> '/etc/init.d/done'  base-files/files. Using an environment variable
> keeps the selection of the overlay bank in scripts. The alternative
> would be require to integrate the selection of the bank at boot time
> into the mount_root program, but that ties the implementation to
> specific hardware.
> 
> At a high level, I modified the mount_root program to use
> '/overlay/${OVERLAY_BANK}/' instead of '/overlay/'. When /overlay does
> not yet contain the directory ${OVERLAY_BANK}, it creates this
> directory.
> 
> I can imagine that this can also be useful to test new firmware and
> make it possible to revert the upgrade by moving back to the previous
> overlay bank.
> 
> Before polishing my experimental implementation and sending it as a
> patch to the mailinglist, I'd like to know whether someone else had to
> deal with such requirement, or sees different ways to create a device
> that can boot with one out of several configurations.
> 
> Regards,
> 
> Jurgen




More information about the Lede-dev mailing list