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

Hi Enrico,
thanks for the quick answer. I am using barebox with bootchoser and PTXdist for my linux.

> despite the fact that you might not want to update you bootloader with each rootFS update.
Indeed! I have to figure out a way to compare the installed bootloader with the shipped one and only update if necessary.

> Thus, after having updated your bootloader, it will read your previous configuration and know in which state you are!
Good to know, let's keep that in mind for the next section.
 
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.

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).

Hope this made my thoughts more clear. Thanks for the discussion and cheers,
Martin
_______________________________________________
RAUC mailing list

  reply	other threads:[~2017-05-18 11:29 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 [this message]
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=cf19356bcdd14acbbd1055e6092fcf0d@itk-engineering.de \
    --to=martin.hollingsworth@itk-engineering.de \
    --cc=RAUC@pengutronix.de \
    --cc=ejo@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