mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: "Kilimci, Caglar" <caglar.kilimci@accenture.com>
To: "Enrico Jörns" <enricojoerns@web.de>
Cc: "rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: Re: [RAUC] [External] Re:  Only Application FS Update
Date: Thu, 19 Oct 2017 10:41:44 +0000	[thread overview]
Message-ID: <BN6P114MB006807018F00BBA200EB57A89D420@BN6P114MB0068.NAMP114.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <16f903d6-f04d-032b-4ed6-2bec37c24f2e@web.de>

Hi Enrico,

Thank you for your reply.

>> I would like to use RAUC to update just my application FS so I do not have double root FS. In other words, only one root FS but double application FS. If I create an update bundle and install it, RAUC only install "slot.appfs.0". How can I configure RAUC to install different slots?
>>
>
>well, different things.
>First of all, I recommend to install only well-tested software states.
>I.e. an appfs tested together with a specific rootfs state.
>Now, this does not mean that the rootfs necessarily changes over different iterations of the appfs and that not each update of an appfs requires a (real) update of the rootfs.
>
>But, with your design you seem to pin the rootfs to a fixed state that cannot be changed anymore. It is only possibly to change the appfs.
>Is that assumption true?

Yes, absolutely true.

> Or do you have another 'factory' slot you can run RAUC from to update you rootfs?

No, Just one root FS that does basic stuff.

>Now, the normal way RAUC determines how to update a specific slot is by detecting the booted slot and all other slots being 'active' at the same time. RAUC will detect your booted rootfs slot and all other slots having this slot mentiond as their 'parent' as active slots.
>
>In your config, you (intentionally) do not have any relation set between the appfs and rootfs. This way, RAUC cannot detect that any of your appfs is 'active' an thus chooses the 'next' one to install.
>
>At the moment, 'next' means the next inactive slot of same class listed in the system configuration. There is no further metric atm. Thus, you cannot manually select appfs.1 for installation if that is what you intended to do.

I guess, I misconfigure something. Even if I assign parent to both appfs, RAUC installs to the "next" slot. Here is the configuration to test this:
# cat /etc/rauc/system.conf
[system]
compatible=Phytec
bootloader=barebox

[keyring]
path=ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system1

[slot.rootfs.1]
device=/dev/mmcblk0p2
type=ext4
bootname=system2

[slot.appfs.0]
device=/dev/mmcblk0p5
type=ext4
parent=system2

[slot.appfs.1]
device=/dev/mmcblk0p6
type=ext4
parent=system1

# rauc status
Parent system1 not found!
Parent system2 not found!
Compatible:  Phytec
booted from: system1
slot states:
  rootfs.0: class=rootfs, device=/dev/mmcblk0p2, type=ext4, bootname=system1
      state=booted, description=, parent=(none), mountpoint=(none)
  rootfs.1: class=rootfs, device=/dev/mmcblk0p2, type=ext4, bootname=system2
      state=inactive, description=, parent=(none), mountpoint=(none)
  appfs.0: class=appfs, device=/dev/mmcblk0p5, type=ext4, bootname=(null)
      state=inactive, description=, parent=(none), mountpoint=(none)
  appfs.1: class=appfs, device=/dev/mmcblk0p6, type=ext4, bootname=(null)
      state=inactive, description=, parent=(none), mountpoint=(none)


>Now, the key aspect is, if you have only a single rootfs, you must have a different switching point than 'conventional' approaches.
>Thus, my question is where and how you do select which appfs to use?

In my opinion, this selection logic will be in the appfs. As an example, rootfs.0, appfs.0 and appfs.1 (both appfs are same) will be shipped by default and let assume appfs.0 is mounted and working wikt rootfs.0 without any problem. An update will be written in appfs.1. After reboot rootfs.0 and appfs.1 will be working. If there is an error on rootfs.0 and appfs.1 combination, we can reboot and again rootfs.0 and appfs.0 work together.

>Here is the point to a) let the RAUC boot selection algorithm interact with and to b) perform the detection of the slot booted.
>
>If you do not intend to update your rootfs, remove it from the slot list and set appropriate bootnames for appfs 0 and 1.

I guess, this one I am looking for. **How to set a bootname?** On the state framework? Because my bootname on bootchooser is "system1" but I changed /etc/rauc/system.conf as "system2" but still considers as "system1". If then, I can remove state framework and test it, I do not have to use state framework.

# cat /etc/rauc/system.conf
[system]
compatible=Phytec
bootloader=barebox

[keyring]
path=ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system2

[slot.appfs.0]
device=/dev/mmcblk0p5
type=ext4
parent=system1

[slot.appfs.1]
device=/dev/mmcblk0p6
type=ext4
parent=system2

# rauc status
Parent system2 not found!
Parent system1 not found!
Failed to determine slot states: Did not find booted slot

# barebox-state -d
New state registered 'state'
bootchooser.system1.boot=system1
bootchooser.system1.default_attempts=3
bootchooser.system1.default_priority=16
bootchooser.system1.remaining_attempts=2
bootchooser.system1.priority=20
bootchooser.system2.boot=system2
bootchooser.system2.default_attempts=3
bootchooser.system2.default_priority=15
bootchooser.system2.remaining_attempts=3
bootchooser.system2.priority=10
bootchooser.last_chosen=1

Thank you for your time and sorry for the long mail.

Best Regards,
Caglar

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
_______________________________________________
RAUC mailing list

  reply	other threads:[~2017-10-19 10:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18 12:45 [RAUC] " Kilimci, Caglar
2017-10-18 21:30 ` Enrico Jörns
2017-10-19 10:41   ` Kilimci, Caglar [this message]
2017-10-22 13:07     ` [RAUC] [External] " Enrico Jörns
2017-10-23 15:24       ` Kilimci, Caglar
2017-10-25 11:29         ` Enrico Jörns
2017-10-25 11:44           ` Kilimci, Caglar

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=BN6P114MB006807018F00BBA200EB57A89D420@BN6P114MB0068.NAMP114.PROD.OUTLOOK.COM \
    --to=caglar.kilimci@accenture.com \
    --cc=enricojoerns@web.de \
    --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