mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: "Enrico Jörns" <ejo@pengutronix.de>
To: Mauro Condarelli <mc5686@mclink.it>
Cc: rauc@pengutronix.de
Subject: Re: [RAUC] Rauch usage hints needed
Date: Thu, 12 Dec 2019 00:50:25 +0100	[thread overview]
Message-ID: <bb28bf4c-a04b-920d-f4f4-354a5d1787b2@pengutronix.de> (raw)
In-Reply-To: <633061c8-9eae-9232-f30b-dd430174dd4c@mclink.it>

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

  reply	other threads:[~2019-12-11 23:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-01 10:55 Mauro Condarelli
2019-12-11 23:50 ` Enrico Jörns [this message]
2020-01-22 12:57   ` [RAUC] Rauc " Mauro Condarelli

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=bb28bf4c-a04b-920d-f4f4-354a5d1787b2@pengutronix.de \
    --to=ejo@pengutronix.de \
    --cc=mc5686@mclink.it \
    --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