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
