mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: Martin Hollingsworth <Martin.Hollingsworth@itk-engineering.de>
To: "Jan Lübbe" <jlu@pengutronix.de>
Cc: "rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: AW: [RAUC] Bootloader updates
Date: Fri, 19 May 2017 12:13:57 +0000	[thread overview]
Message-ID: <1adc417ef97d434984d6e67b58254bbb@itk-engineering.de> (raw)
In-Reply-To: <1495114488.2513.78.camel@pengutronix.de>

Hallo Jan,
thanks for your detailed suggestions. I would like to add my thoughts to your proposal.

>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

I totally agree with you, that these are the only two options I have. The first one implies a lot of testing, especially when the bootloader changes often. 

The second one can be simply achieved by disabling fallback support, but ONLY when the update includes a new bootloader. In this case I would do all update steps regularly, and only at very last step disabling fallback and exchanging the bootloader. This would give me fallback support about most of the time during update, only the last step and the reboot into new system is unprotected. (No risk no fun ^^).

> For the second option I can think of several variants:
> The one I'd suggest is:
>- Store a copy of the bootloader in the RootFS.
>- Use RAUC only to update the only the RootFS.
>- Reboot into the new system.
>- On boot, before starting the application, check that the current slotis 'sane'. 
>- Disable the old rootfs slot and update the bootloader (directly or via barebox_update).
>- Reboot
>- Start the application.

I see one major downside to this. The new kernel must be booted by the old bootloader. What if the new kernel needs major differences in the kernel bootargs? How likely is it, that such a change then cannot be booted with the old bootloader anymore and hence my whole update system may be unfit for the desired kernel changes? (Actually how often do kernel bootargs change in real life...?).

I have one other idea:
- Make a raw memory copy of the current bootloader sections into a designated file.
- Update the bootloader.
- Update the RootFS, while keeping the old slot still active as fallback (regular RootFS update using RAUC).
- If we successfully reboot into new system, all is fine, disable fallback slot, run new system.
- If the update fails, we fallback to the old linux slot, with the new bootloader active. 
The new bootloader should then detect the designated bootloader backup file, stop the regular startup process and overwrite itself with the backup of the bootloader.
After a reboot the old bootloader is running again with the old linux slot.

However I am not sure yet if this is a feasible solution, and technical possible. Furthermore this introduces the risk, that the bootloader overwrites itself with a file from filesystem. This could be dangerous.

Seems like there is no simple solution to this. Cheers and best regards,
Martin


      reply	other threads:[~2017-05-19 12:13 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
2017-05-19 12:13       ` Martin Hollingsworth [this message]

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=1adc417ef97d434984d6e67b58254bbb@itk-engineering.de \
    --to=martin.hollingsworth@itk-engineering.de \
    --cc=jlu@pengutronix.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