Openembedded Core Discussions
 help / color / mirror / Atom feed
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


             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