From: Mariano Lopez <mariano.lopez@linux.intel.com>
To: openembedded-devel@lists.openembedded.org,
OE-core <openembedded-core@lists.openembedded.org>,
yocto@yoctoproject.org
Subject: RFC: Reference updater filesystem
Date: Mon, 23 Nov 2015 15:41:28 -0600 [thread overview]
Message-ID: <56538808.5050606@linux.intel.com> (raw)
There has been interest in an image based software updater in Yocto
Project. The proposed solution for a image based updater is to use
Stefano Babic's software updater (http://sbabic.github.io/swupdate).
This software do a binary copy, so it is needed to have at least two
partitions, these partitions would be the rootfs and the maintenance
partition. The rootfs it's the main partition used to boot during the
normal device operation, on the other hand, the maintenance will be used
to update the main partition.
To update the system, the user has to connect to device and boot in the
maintenance partition; once in the maintenance partition the software
updater will copy the new image in the rootfs partition. A final reboot
into the rootfs it is necessary to complete the upgrade.
As mentioned before the the software will copy an image to the
partition, so everything in that partition will be wiped out, including
custom configurations. To avoid the loss of configuration I explore
three different solutions:
1. Use a separate partition for the configuration.
a. The pro of this method is the partition is not touched during the
update.
b. The con of this method is the configuration is not directly in
rootfs (example: /etc).
2. Do the backup during the update.
a. The pro is the configuration is directly in rootfs.
b. The con is If the update fail most likely the configuration would
be lost.
3. Have an OverlayFS for the rootfs or the partition that have the
configuration.
a. The pro is the configuration is "directly" in rootfs.
b. The con is there is need to provide a custom init to guarantee the
Overlay is mounted before the boot process.
With the above information I'm proposing to use a separate partition for
the configuration; this is because is more reliable and doesn't require
big changes in the current architecture.
So, the idea is to have 4 partitions in the media:
1. boot. This is the usual boot partition
2. data. This will hold the configuration files. Not modified by updates.
3. maintenance. This partition will be used to update rootfs.
4. rootfs. Partition used for normal operation.
Mariano
next reply other threads:[~2015-11-23 21:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 21:41 Mariano Lopez [this message]
2015-11-24 6:06 ` RFC: Reference updater filesystem Anders Darander
2015-11-24 18:39 ` [yocto] " Lopez, Mariano
2015-11-24 7:32 ` Randy Witt
2015-11-24 17:19 ` Lopez, Mariano
2015-11-24 10:39 ` [oe] " Roman Khimov
2015-11-24 13:47 ` Mark Hatle
2015-11-24 17:02 ` [yocto] " Lopez, Mariano
2015-11-24 17:13 ` Mark Hatle
2015-11-24 18:05 ` Roman Khimov
2015-11-24 18:27 ` Mark Hatle
2015-11-24 18:47 ` Roman Khimov
2015-12-03 16:45 ` Mariano Lopez
2015-12-06 11:34 ` Jens Rehsack
[not found] ` <60350861.Ng52JMGuMb@bancha.hex>
2015-11-24 16:30 ` Lopez, Mariano
2015-11-24 18:10 ` Roman Khimov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56538808.5050606@linux.intel.com \
--to=mariano.lopez@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox