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

["Kilimci, Caglar" <caglar.kilimci@accenture.com>]

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