[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