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