mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: Enrico Joerns <ejo@pengutronix.de>
To: dilip yadav <yadav.dilip582@gmail.com>
Cc: "rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: Re: [RAUC] Update Installation failed
Date: Wed, 5 Apr 2017 15:57:04 +0200	[thread overview]
Message-ID: <32484f46-deb8-439c-a3aa-393d19f8e112@pengutronix.de> (raw)
In-Reply-To: <CALC1k0BVs1iB9XwdWwftxdZzWxLXguix2S9pFZCJasTS2PoTkg@mail.gmail.com>

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

      parent reply	other threads:[~2017-04-05 13:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 10:29 dilip yadav
2017-04-05 10:40 ` Enrico Joerns
     [not found]   ` <CALC1k0CxfGXAEAf4WKJfm6PjahfLyf5W3quwbyn7dfHZ+VeZnQ@mail.gmail.com>
     [not found]     ` <CALC1k0BVs1iB9XwdWwftxdZzWxLXguix2S9pFZCJasTS2PoTkg@mail.gmail.com>
2017-04-05 13:57       ` 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=32484f46-deb8-439c-a3aa-393d19f8e112@pengutronix.de \
    --to=ejo@pengutronix.de \
    --cc=rauc@pengutronix.de \
    --cc=yadav.dilip582@gmail.com \
    /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