mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: "Jan Lübbe" <jlu@pengutronix.de>
To: Martin Hollingsworth <Martin.Hollingsworth@itk-engineering.de>
Cc: rauc@pengutronix.de
Subject: Re: [RAUC] Bootloader updates
Date: Thu, 18 May 2017 15:34:48 +0200	[thread overview]
Message-ID: <1495114488.2513.78.camel@pengutronix.de> (raw)
In-Reply-To: <cf19356bcdd14acbbd1055e6092fcf0d@itk-engineering.de>

Hi Martin,

thanks for your interesting question!

On Do, 2017-05-18 at 11:29 +0000, Martin Hollingsworth wrote:
> Ok, so let me rephrase my worries. So during an update, that includes
> a new bootloader, the following steps are done in the following order:
> 1) Update Bootloader by overwriting it (RAUC config stays intact).
> 2) Install RootFS onto second slot (say Slot B).
> 
> When 1) succeeds and 2) fails / is interrupted (power cut, etc.), the
> bootchoser configuration will decide to boot from Slot A again (the
> old linux system).
> 
> Hence now we have a newer version of the bootloader, running with the
> previous (older) linux system. Hence we have a software combination,
> that was not intended to run together, probably not tested during
> development, but potentially running on a field device.
As long as you have only a single bootloader (which is consequently the
component which decides whether to boot A or B), I see only two possible
options:
- ensure and test that newer bootloaders can boot older kernels
or
- make sure that the new bootloader never boots the old system

> This is the main concern of this question. Could this lead to trouble?
> Is there a mechanism in RAUC to prevent falling into this situation?
> (Maybe my question is more a conceptual question than a RAUC
> question).
Which option is acceptable for you depends on your use-case and whether
you can test the fallback combinations sufficiently.

For the second option I can think of several variants:
- Deactivate the current slot before updating the bootloader.
  This basically means you don't have fallback support at all.
- Check the installed bootloader version matches the one tested with 
  the rootfs before launching the main application. On error, you can
  at least notify the user.

The one I'd suggest is:
- Store a copy of the bootloader in the RootFS.
- Use RAUC only to update the only the RootFS. The combinations to test 
  can limited by restringing which old versions are supported by an 
  update.
- Reboot into the new system.
- On boot, before starting the application, check that the current slot 
  is 'sane'. Then check if the installed bootloader is older than the 
  version shipped in the (new) rootfs. In that case:
  - Disable the old rootfs slot and update the bootloader (directly or 
    via barebox_update).
  - Reboot
- Start the application.

This way you still have fallback support for the rootfs upgrade and need
to test only:
- sanity check and bootloader installation when started from old 
  bootloader and new rootfs
- normal operation when started from new bootloader and new rootfs

The case of new bootloader with old rootfs can never happen, because you
disable the old one from the new before installing a new bootloader.

This also means that the actual bootloader update is handled outside of
the RAUC update installation during bootup (perhaps as a systemd
service).


If your system boots from an eMMC, you can usually also make the
bootloader update atomic (but not with fallback) by using the special
boot partitions.

Regards,
Jan Lübbe
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
RAUC mailing list

  reply	other threads:[~2017-05-18 13:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18  9:45 Martin Hollingsworth
2017-05-18 10:38 ` Enrico Joerns
2017-05-18 11:29   ` Martin Hollingsworth
2017-05-18 13:34     ` Jan Lübbe [this message]
2017-05-19 12:13       ` AW: " Martin Hollingsworth

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=1495114488.2513.78.camel@pengutronix.de \
    --to=jlu@pengutronix.de \
    --cc=Martin.Hollingsworth@itk-engineering.de \
    --cc=rauc@pengutronix.de \
    /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