Hi,
please keep the mailing list in CC so everyone could benefit from our
discussion :)
On 04/05/2017 01:40 PM, dilip yadav wrote:
With your kind help, Ihave successfully updated the minimal rootfs with
rauc.
I have following concerns:
1.How can I automate the "rauc status mark-good", What if installation
returned with error and it makes the partition good.
To clarify, the `rauc status mark-good` is meant to be executed during
the start of your system, not after an installation. Selecting the
appropriate slot for the next boot is done by RAUC automatically after a
successful installation.
What the mark-good command does is preventing you from starting a
non-booting system over and over. The bootloader should decrease a
counter or set a flag that indicates that this slot might be bad.
Then from your system, at the point where your are really sure all your
components came up as intended, you invoke the `status mark-good` that
resets the bootloaders flag/counter.
If your system reboots before this good-marking is performed, this
mechanism allows you to assure that the bootloader will not forever
attempt to select the same (non-working) slot.
2.Is there any provision of delta updates only?
We definitely have plans for this on paper, but they are not realized,
yet. Because currently development is mainly driven from what customers
require and the need for this was not high enough, yet, this item is
still on our wish list.
3.How to integrate it with remote updating server like hawkbit?
Well, you typically need a custom application for this that talks to
RAUC vi D-Bus on one side and talks with hawkBit via the DDI REST API on
the other side. This is not part of RAUC as we focus on being an update
client and update bundle generator. Integration into a system is very
individual and many users already have an application component.
What we did for a Demo is creating a small python service that acts as a
bridge between RAUC and hawkBit. But despite it is planned to provide
some of its components as Open Source software, we did not find the time
to refactor it.
4.What if I want to update only the app? Should I create new partition
for that?
Yes, that would be an option, RAUC supports this. Also grouping them
together with giving the appfs slot a `parent` attribute (see [1]). But
let me point out two things about this:
1. Also if you have a separate application, you always want to assure
that you only install you application along the exact base system it was
tested to work with.
2. On the bright side: On *this* level, we support some kind of
Delta-Updates. If you provide an update bundle with a rootfs and an
appfs image, and you already have the exact appfs image installed on the
targets slot you intend to update, only the appfs image will be written.
Well, this still requires you to have both images in the bundle, but it
will decrease the time required to perform the update while still
assuring you only install well tested software states. It depends on
what your critical factor is (storage capacity vs. space) if that helps you.
Hope I could point out our current state of the art about the points you
mentioned.
Best regards
Enrico
[1]
http://rauc.readthedocs.io/en/latest/reference.html#system-configuration-file
--
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
