mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: Enrico Joerns <ejo@pengutronix.de>
To: Kevin Golding <kevin@kgolding.co.uk>
Cc: RAUC@pengutronix.de
Subject: Re: [RAUC] Rescue system
Date: Thu, 17 May 2018 17:22:37 +0200	[thread overview]
Message-ID: <521e1223-eba4-5055-150b-fdec89452a1a@pengutronix.de> (raw)
In-Reply-To: <42727149-5594-a49e-a3cd-f631b462a32d@kgolding.co.uk>

Hi Kevin,

On 05/17/2018 04:29 PM, Kevin Golding wrote:
> Hello,
> 
> Am just getting my head around RAUC, and wondered if I'm right in thinking that a rescue system is not included with RAUC? i.e. I would need to find or create a small bootable rescue system that would run the RAUC update command say via say from a file on a USB stick?

conceptually RAUC is a generic update framework that can run on your Linux device and handle safe and atomic updates of partitions etc.
It does neither provide any ready-to-use distribution nor depend on any specific.

Thus building a system is always a task that should be solved outside of an update tool. With OE/Yocto, PTXdist and buildroot good build system exists for this that allow you to generate well defined customized systems in versioned and reproducible manner.

RAUC also does not depend on any specific source for its update artifacts. Neither on the production system nor on any rescue system. You can fetch your update from USB / network / storage media or whatever fits your concept or platform.

Nevertheless, conceptually a rescue system is surely supported. A slot configuration for your rescue system (and the default ones, too) would look like

   [slot.rootfs.0]
   device=/dev/mmcblk0p1
   ...

   [slot.rootfs.1]
   device=/dev/mmcblk0p1
   ...

   [slot.rescue.0]
   device=/dev/sda1
   ...


This would allow detecting RAUC that it is not running from one of the normal rootfs partitions but from the rescue partition instead and that it can safely upate the others.

> If I am right, are there any examples of a rescue system available?

No. A rescue system can be as small as only a minimal kernel+initramfs+dtb with RAUC binary + dependencies which will result in a few kB. Most of the build systems above provide a minimal rootfs configuration that you can simply extend with RAUC.

https://rauc.readthedocs.io/en/latest/integration.html


Did that roughly point you in the right direction?


Best regards, Enrico


-- 
Pengutronix e.K.                           | Enrico Jörns                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
RAUC mailing list

  reply	other threads:[~2018-05-17 15:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 14:29 Kevin Golding
2018-05-17 15:22 ` Enrico Joerns [this message]
2018-05-17 22:12   ` Kevin Golding

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=521e1223-eba4-5055-150b-fdec89452a1a@pengutronix.de \
    --to=ejo@pengutronix.de \
    --cc=RAUC@pengutronix.de \
    --cc=kevin@kgolding.co.uk \
    /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