mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: Enrico Joerns <ejo@pengutronix.de>
To: Martin Hollingsworth <Martin.Hollingsworth@itk-engineering.de>
Cc: "RAUC@pengutronix.de" <RAUC@pengutronix.de>
Subject: Re: [RAUC] Bootloader updates
Date: Thu, 18 May 2017 12:38:01 +0200	[thread overview]
Message-ID: <07ece2de-259f-67a3-f9ba-2349ae7e40a6@pengutronix.de> (raw)
In-Reply-To: <4a0389f5ec894cac88bd34a17893fc26@itk-engineering.de>

Hello Martin,

On 05/18/2017 11:45 AM, Martin Hollingsworth wrote:
> Hello RAUC Team,
>
> I am currently implementing software update on my embedded target and
> evaluating the usage of RAUC. But I have trouble finding a solution for
> the following scenario, which needs a little explanation, but can be
> summerized as: „How does Rauc handle Bootloader Updates?”
>
> Here is what I want to achieve:
>
> A software release is a combination of multiple software components in
> specific versions, that have been tested and defined fit for usage
> together on an embedded target. Lets say a simple example would be a
> bootloader and a rootFS (which includes linux and some custom software
> pre-installed).

that sounds rational to me (despite the fact that you might not want to 
update you bootloader with each rootFS update).

> When I update my system, I secure my linux operating system using a
> symmetric A/B setup. If the update fails, I can always jump back to the
> last slot and continue regular device operation.

Yes, that is one of the common Scenarios RAUC will be able to handle for 
you.

> But when I update my bootloader AND my linux system together, after
> exchanging the bootloader I cannot jump back to the last running linux,
> because now the bootloader configuration might not match the
> configuration expected from the previous bootloader.
>
> How does RAUC approach this issue?

this is not something that really touches RAUC and I am not sure if I 
got you problem right.

You intend to exchange the bootloader, but this should not have any 
consequence for the stored update configuration. The information about 
which slot has which priority, remaining attempts, etc. will normally be 
persisted in a different storage location than your bootloader itself. 
E.g. a different partition on your FLASH or a distinct EEPROM location, etc.

Thus, after having updated your bootloader, it will read your previous 
configuration and know in which state you are!

The only scenario where you will get into troubles is when the new 
bootloader is unable to read the storage format your old one used. But 
1) this should not happen or is an issue that is really out of scope of 
what an update tool can do for you.

If I did not really get what your worries are, please let me know.

May I ask which bootloader you are using?


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:[~2017-05-18 10:38 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 [this message]
2017-05-18 11:29   ` Martin Hollingsworth
2017-05-18 13:34     ` Jan Lübbe
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=07ece2de-259f-67a3-f9ba-2349ae7e40a6@pengutronix.de \
    --to=ejo@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