[RAUC] Only Application FS Update

[RAUC] Only Application FS Update

[Kilimci, Caglar]

Hi all,

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?

Here are my manifest file and system configuration:

# cat bundle/manifest.raucm
[update]
compatible=Phytec
version=2

[image.appfs]
sha256=05f23d6b732519342f265ed2605276585d487e34555be5ae927328164cd83c26
size=135
filename=appfs.tar.gz

# 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.appfs.0]
device=/dev/mmcblk0p5
type=ext4

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

Thank you for your time.
Sincerely,
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

Re: [RAUC] Only Application FS Update

[Enrico Jörns]

Hi Caglar,

Am 18.10.2017 um 14:45 schrieb Kilimci, Caglar:
> Hi all,
> 
> 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?
> 
> Here are my manifest file and system configuration:
> 
> # cat bundle/manifest.raucm
> [update]
> compatible=Phytec
> version=2
> 
> [image.appfs]
> sha256=05f23d6b732519342f265ed2605276585d487e34555be5ae927328164cd83c26
> size=135
> filename=appfs.tar.gz
> 
> # 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.appfs.0]
> device=/dev/mmcblk0p5
> type=ext4
> 
> [slot.appfs.1]
> device=/dev/mmcblk0p6
> type=ext4

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? Or do you have another 'factory' slot you can
run RAUC from to update you rootfs?

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.


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?
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.

But, to lead you in the right way it would help to know a bit more about
your motivations for the design you made.


Best regards

Enrico

_______________________________________________
RAUC mailing list

Re: [RAUC] [External] Re: Only Application FS Update

[Kilimci, Caglar]

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

Re: [RAUC] [External] Re: Only Application FS Update

[Enrico Jörns]

Hi Caglar,

Am 19.10.2017 um 12:41 schrieb Kilimci, Caglar:
>> 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.

Ok. So you are building a system to be attacked by using the latest
security holes in your rootfs? ;)

> 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)

Yes, you misconfigured something. The bootname argument expects the
parents slot name, thus

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

RAUC warns about system1 not found, but it definitely should error and
abort here instead...

>> 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.

Ok, from this point of view, the selection logic must either be in the
bootloader or in the rootfs. It switches between the appfs used and thus
cannot be in the appfs itself. But I guess this is what you ment.

>> 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.

Your logic is based on using redundant rootfs atm, and, of course this
will not work with a single one.


Well, the initial question is not how you detect which appfs is running,
it is how you actually choose which appfs to use.

You can use bootchooser for it, of course, make a special boot target
that contains a command line option that is specific to which appfs to use.
Or you could manipulate mount configuration in the rootfs somehow...

Did you already specify how this will work?


Regards, Enrico

_______________________________________________
RAUC mailing list

Re: [RAUC] [External] Re: Only Application FS Update

[Kilimci, Caglar]

Hi Enrico

>>> 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.
>
>Ok. So you are building a system to be attacked by using the latest security holes in your rootfs? ;)

Exactly what I think so, but.. :)

>> 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:
>
>Yes, you misconfigured something. The bootname argument expects the parents slot name, thus
>
>  [slot.appfs.0]
>  device=/dev/mmcblk0p5
>  type=ext4
>- parent=system2
>+ parent=rootfs.0
>
>RAUC warns about system1 not found, but it definitely should error and abort here instead...

I guess, there is still misconfiguration or a bug. RAUC still installs to the "next" slot. Here:

# rauc status
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=rootfs.1, mountpoint=(none)
  appfs.1: class=appfs, device=/dev/mmcblk0p6, type=ext4, bootname=(null)
      state=active, description=, parent=rootfs.0, mountpoint=(none)

# 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=rootfs.1

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

# rauc install bundle_v2.raucb
trying to contact rauc service
rauc-Message: installing /home/root/update/bundle_v2.raucb: installing
[   79.751471] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
[   81.348642] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
[   81.496995] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
installing `/home/root/update/bundle_v2.raucb` succeeded


Even if I remove slot.rootfs.1, nothing changes.


>>> 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.
>
>Ok, from this point of view, the selection logic must either be in the bootloader or in the rootfs. It switches between the appfs used and thus cannot be in the appfs itself. But I guess this is what you ment.

Yes.


>>> 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.
>
>Your logic is based on using redundant rootfs atm, and, of course this will not work with a single one.
>
>
>Well, the initial question is not how you detect which appfs is running, it is how you actually choose which appfs to use.
>
>You can use bootchooser for it, of course, make a special boot target that contains a command line option that is specific to which appfs to use.
>Or you could manipulate mount configuration in the rootfs somehow...

Alright.


>Did you already specify how this will work?

Not exactly. I am now investigating how I can manage and implement.

Thank you so much.

Sincerely,
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

Re: [RAUC] [External] Re: Only Application FS Update

[Enrico Jörns]

Hi Caglar,

Am 23.10.2017 um 17:24 schrieb Kilimci, Caglar:
> I guess, there is still misconfiguration or a bug. RAUC still installs to the "next" slot. Here:
> 
> # rauc status
> 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=rootfs.1, mountpoint=(none)
>   appfs.1: class=appfs, device=/dev/mmcblk0p6, type=ext4, bootname=(null)
>       state=active, description=, parent=rootfs.0, mountpoint=(none)

This is before or after updating? The update group rootfs.0 and appfs.1
is active. If it is before, RAUC should write the next update into
'appfs.0' (and rootfs.1 if there was an image for).


Regards, Enrico


> # 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=rootfs.1
> 
> [slot.appfs.1]
> device=/dev/mmcblk0p6
> type=ext4
> parent=rootfs.0
> 
> # rauc install bundle_v2.raucb
> trying to contact rauc service
> rauc-Message: installing /home/root/update/bundle_v2.raucb: installing
> [   79.751471] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
> [   81.348642] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
> [   81.496995] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
> installing `/home/root/update/bundle_v2.raucb` succeeded
> 
> 
> Even if I remove slot.rootfs.1, nothing changes.


-- 
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

Re: [RAUC] [External] Re: Only Application FS Update

[Kilimci, Caglar]

Hi Enrico,

>> I guess, there is still misconfiguration or a bug. RAUC still installs to the "next" slot. Here:
>>
>> # rauc status
>> 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=rootfs.1, mountpoint=(none)
>>   appfs.1: class=appfs, device=/dev/mmcblk0p6, type=ext4, bootname=(null)
>>       state=active, description=, parent=rootfs.0, mountpoint=(none)
>
>This is before or after updating? The update group rootfs.0 and appfs.1 is active. If it is before, RAUC should write the next update into 'appfs.0' (and rootfs.1 if there was an image for).

This was before updating. So I got that. Thank you so much and have a nice day.

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