[RAUC] Rauch usage hints needed

[RAUC] Rauch usage hints needed

[Mauro Condarelli]

Hi All,
I'm trying to decide if rauch is the right tool for my project.

My target is an embedded Linux with:
- SPI Flash for booting (paleolithic version of U-Boot) and possibly a
initramfs/recovery (16M total)
- A sizable SD card (8G).

Bad problem is SD is very sensitive to "unexpected" shutdowns which I
cannot prevent.

Slots should include:

- uboot (possibly never updated)
  allocated in first Flash partition: /dev/mtd1

- linux kernel (rarely upgraded, if ever)
  allocated in third Flash partition: /dev/mtd3

- recovery (possibly never updated)
  allocated in fourth Flash partition: /dev/mtd4
  probably a SquashFS, but could also be a initramfs (cpio)
  copies of rauc modules could be stored in first SD partition (vfat)
/dev/mmcblk1

- system (rarely upgraded)
  allocated in SD, redundant probably /dev/mmcblk0p2 and /dev/mmcblk0p3
  ext4
 
- application (often upgraded)
  allocated in SD, redundant probably /dev/mmcblk0p5 and /dev/mmcblk0p6
  ext4 mounted on /home

- accumulated data (initially empty; should be preserved at all cost)
  allocated in SD, not redundant, but possibly backed-up before upgrade.
  ext4 mounted on /srv

At first documentation perusal I saw no direct support for MTD.
My current "solution" relies on a bunch of scripts that are rapidly growing
and a rather complex usage of OverlayFS.
I am thus looking for a "more structured" solution, possibly rauch.

Can someone advise?
I am available to give more info, if needed.

Thanks in Advance
Mauro

_______________________________________________
RAUC mailing list

Re: [RAUC] Rauch usage hints needed

[Enrico Jörns]

Hi Mauro,

sorry for being a bit late in answering. It turns out that the less of
the year remains, the more is still to be done until it ends ;)

Am 01.12.19 um 11:55 schrieb Mauro Condarelli:
> Hi All,
> I'm trying to decide if rauch is the right tool for my project.

Please, says 'rauc' (or even better 'RAUC'). 'rauch' in german means
'smoke' and this should not be the connotation :D

> My target is an embedded Linux with:
> - SPI Flash for booting (paleolithic version of U-Boot) and possibly a
> initramfs/recovery (16M total)
> - A sizable SD card (8G).
> 
> Bad problem is SD is very sensitive to "unexpected" shutdowns which I
> cannot prevent.
> 
> Slots should include:
> 
> - uboot (possibly never updated)
>   allocated in first Flash partition: /dev/mtd1

Never say never, as bootloaders may fail updating more recent kernels
depending on how much they interact with device tree loading etc.

> - linux kernel (rarely upgraded, if ever)
>   allocated in third Flash partition: /dev/mtd3
> 
> - recovery (possibly never updated)
>   allocated in fourth Flash partition: /dev/mtd4
>   probably a SquashFS, but could also be a initramfs (cpio)
>   copies of rauc modules could be stored in first SD partition (vfat)
> /dev/mmcblk1

Note that because of security concerns, it might require being updated,
too. But from the general concept of a recovery system, yes it should be
rarely updated.

What about saving one partition and using a kernel with built-in initramfs?

> - system (rarely upgraded)
>   allocated in SD, redundant probably /dev/mmcblk0p2 and /dev/mmcblk0p3
>   ext4

Does that bring its own kernel or the one from /dev/mtd3?
Updating the kernel is a definitive use case!

> - application (often upgraded)
>   allocated in SD, redundant probably /dev/mmcblk0p5 and /dev/mmcblk0p6
>   ext4 mounted on /home
> 
> - accumulated data (initially empty; should be preserved at all cost)
>   allocated in SD, not redundant, but possibly backed-up before upgrade.
>   ext4 mounted on /srv
> 
> At first documentation perusal I saw no direct support for MTD.

There were patches from ladis on this list recently that you might have
seen if you're subscribed. Otherwise you could use a hook script first
of all.

> My current "solution" relies on a bunch of scripts that are rapidly growing
> and a rather complex usage of OverlayFS.
> I am thus looking for a "more structured" solution, possibly rauch.

Yes, that is the exact reason why one wants to use an (open source)
framework for these kind of things. And RAUC should be able to cover
your use case of asymmetric A+recovery update. See minimal example:

https://rauc.readthedocs.io/en/latest/scenarios.html#asymmetric-slots

The good on this is, that even if there is some small aspect still
missing, it could be implemented and then be maintained in a shared and
more well-tested environment than a custom script can be.

> Can someone advise?
> I am available to give more info, if needed.

Your general concept looks reasonable. Do my hints already give you the
answers you require?

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

Re: [RAUC] Rauc usage hints needed

[Mauro Condarelli]

Thanks Joerns,
I'm also very late answering, but I've been very busy (see below)

On 12/12/19 12:50 AM, Enrico Jörns wrote:
> Hi Mauro,
>
> sorry for being a bit late in answering. It turns out that the less of
> the year remains, the more is still to be done until it ends ;)
I know ;)

> Am 01.12.19 um 11:55 schrieb Mauro Condarelli:
>> Hi All,
>> I'm trying to decide if rauch is the right tool for my project.
> Please, says 'rauc' (or even better 'RAUC'). 'rauch' in german means
> 'smoke' and this should not be the connotation :D
Fully understood (I should have known, clumsy fingers...)


>> My target is an embedded Linux with:
>> - SPI Flash for booting (paleolithic version of U-Boot) and possibly a
>> initramfs/recovery (16M total)
First good news is I managed to port current (actually "next"!)
u-boot to my board and thus many of the limitations are lifted.


>> - A sizable SD card (8G).
>>
>> Bad problem is SD is very sensitive to "unexpected" shutdowns which I
>> cannot prevent.
>>
>> Slots should include:
>>
>> - uboot (possibly never updated)
>>   allocated in first Flash partition: /dev/mtd1
> Never say never, as bootloaders may fail updating more recent kernels
> depending on how much they interact with device tree loading etc.
Agreed.

- two very small (4k) partitions holding fallback U-Boot ENV and
  serialization data (serial#, MAC addr, ...).
>> - linux kernel (rarely upgraded, if ever)
>>   allocated in third Flash partition: /dev/mtd3
It will become /dev/mtd4.
This Linux kernel is for exclusive use of the recovery system,
in case SD card is completely unusable.

>> - recovery (possibly never updated)
>>   allocated in fourth Flash partition: /dev/mtd4
>>   probably a SquashFS, but could also be a initramfs (cpio)
>>   copies of rauc modules could be stored in first SD partition (vfat)
>> /dev/mmcblk1
> Note that because of security concerns, it might require being updated,
> too. But from the general concept of a recovery system, yes it should be
> rarely updated.
>
> What about saving one partition and using a kernel with built-in initramfs?
As said: recovery system should not be actually used (hopefully ;) )
I don't think to provide updates for that is a priority: if we touch it
we face chance to brick the system, quite the opposite of what a
recovery system is meant to be.

My system (mips MT7628) can see part (first 4MiB) of the SPI NOR
as memory and thus I'm "booting from RAM". InitramFS has limited
size while using SquashFS I can cram much more data in it.

>> - system (rarely upgraded)
>>   allocated in SD, redundant probably /dev/mmcblk0p2 and /dev/mmcblk0p3
>>   ext4
> Does that bring its own kernel or the one from /dev/mtd3?
> Updating the kernel is a definitive use case!
Of course!
Idea would be to have multiple copies of Kernel (along with some
backup copies of RootFS) in the first (FAT formatted) SD partition
(/dev/mmcblk0p1) easily accessible from both U-Boot and Linux.

I also moved U-Boot ENV to this partition so that "normal" (non
recovery) boot could have a completely different environment.
Recovery should mainly rely on "compiled-in" default ENV.
Moving to SD also benefits from Wear-Leveling, so I can update
ENV at each boot attempt to keep the boot-counter needed for
automatic fallback (I'm still unsure on how to implement this in
U-Boot; if there are "best practices" available...).

>> - application (often upgraded)
>>   allocated in SD, redundant probably /dev/mmcblk0p5 and /dev/mmcblk0p6
>>   ext4 mounted on /home
It could be quite small.


>> - accumulated data (initially empty; should be preserved at all cost)
>>   allocated in SD, not redundant, but possibly backed-up before upgrade.
>>   ext4 mounted on /srv
We could allocate a small partition just to store RAUC Update
Artifacts without any interference with "live" system. Would this
buy us some added robustness, in practice?

>> At first documentation perusal I saw no direct support for MTD.
> There were patches from ladis on this list recently that you might have
> seen if you're subscribed. Otherwise you could use a hook script first
> of all.
I just recently subscribed, I'll search the archives.

>> My current "solution" relies on a bunch of scripts that are rapidly growing
>> and a rather complex usage of OverlayFS.
>> I am thus looking for a "more structured" solution, possibly rauch.
> Yes, that is the exact reason why one wants to use an (open source)
> framework for these kind of things. And RAUC should be able to cover
> your use case of asymmetric A+recovery update. See minimal example:
>
> https://rauc.readthedocs.io/en/latest/scenarios.html#asymmetric-slots
I've seen that.
As I'm resuming work now on update system I will send my
tentative architecture (and RAUC Configuration Files) to
have an expert advise.

> The good on this is, that even if there is some small aspect still
> missing, it could be implemented and then be maintained in a shared and
> more well-tested environment than a custom script can be.
>
>> Can someone advise?
>> I am available to give more info, if needed.
> Your general concept looks reasonable. Do my hints already give you the
> answers you require?
Most of them.
I'm still not very sure about how to proceed, but I hope a few
tests will enable me to get a firmer grip unto the matter.

> Best regards
>
> Enrico
>
Regards and Many Thanks
Mauro


_______________________________________________
RAUC mailing list