From: Enrico Joerns <ejo@pengutronix.de>
To: "Middelschulte, Leif" <Leif.Middelschulte@klsmartin.com>
Cc: "rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: Re: [RAUC] file slot type
Date: Tue, 9 May 2017 12:12:03 +0200 [thread overview]
Message-ID: <6682feee-fc10-85e4-13cf-9dbcd590e2ca@pengutronix.de> (raw)
In-Reply-To: <1494322830.7276.1.camel@klsmartin.com>
Hi Leif,
On 05/09/2017 11:40 AM, Middelschulte, Leif wrote:
> Hi,
>
> I was wondering about the 'file' slot type.
>
> Though it's mentioned in the tests, `rauc bundle` complains about an invalid manifest.
>
> Entries like '[file.uctrl]' within the manifest lead to failure during compilation, while '[image.uctrl]' are accepted.
>
> Is it supposed to work at this point?
no, it is not.
The [file] entries seem to be a bit confusing, I agree with you. We just
have a similar discussion on GitHub [1].
When starting with RAUC, we had two major operation modes in mind; 1)
the one that became the standard one now with signed bundles that
contain image artifacts and 2) a so-called 'network' operation mode that
allows to download the manifest and the artifacts described in it
separately from a server. This mode is rarely used and we plan to
replace it with a network mode that works with streaming bundles over
network.
Now, for the network mode aimed to use files instead of images as it
targeted a setup with placing files in an existing file system instead
of writing whole fs images.
To sum up: Using [file.slot/name] is not possible with bundle
installations and migh also become obsolete for the old network
installation mode.
But, in RAUC, everything you can describe as a path in your system could
also be used as a slot for updating. Thus if you need to place (for
whatever reason) files under a special path, you could simply make this
path a slot:
[slot.uctrl]
device=/fs/path/to/your/uctrl.img
...
But also note that in most cases this is an unnecessary hack. You can
simply place your uctrl code withing your rootfs that you update. This
has the great advantage that you will not accidentally update a system
with a uctrl image that is not tested to work properly with the rootfs
installed on that system. Installing only well-tested combinations of
software is an important building block for a robust update strategy!
Best regards
Enrico
[1] https://github.com/rauc/rauc/issues/114
--
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
prev parent reply other threads:[~2017-05-09 10:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 9:40 Middelschulte, Leif
2017-05-09 10:12 ` Enrico Joerns [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=6682feee-fc10-85e4-13cf-9dbcd590e2ca@pengutronix.de \
--to=ejo@pengutronix.de \
--cc=Leif.Middelschulte@klsmartin.com \
--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