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
