* [RAUC] Only Application FS Update @ 2017-10-18 12:45 Kilimci, Caglar 2017-10-18 21:30 ` Enrico Jörns 0 siblings, 1 reply; 7+ messages in thread From: Kilimci, Caglar @ 2017-10-18 12:45 UTC (permalink / raw) To: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Only Application FS Update 2017-10-18 12:45 [RAUC] Only Application FS Update Kilimci, Caglar @ 2017-10-18 21:30 ` Enrico Jörns 2017-10-19 10:41 ` [RAUC] [External] " Kilimci, Caglar 0 siblings, 1 reply; 7+ messages in thread From: Enrico Jörns @ 2017-10-18 21:30 UTC (permalink / raw) To: Kilimci, Caglar; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] [External] Re: Only Application FS Update 2017-10-18 21:30 ` Enrico Jörns @ 2017-10-19 10:41 ` Kilimci, Caglar 2017-10-22 13:07 ` Enrico Jörns 0 siblings, 1 reply; 7+ messages in thread From: Kilimci, Caglar @ 2017-10-19 10:41 UTC (permalink / raw) To: Enrico Jörns; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] [External] Re: Only Application FS Update 2017-10-19 10:41 ` [RAUC] [External] " Kilimci, Caglar @ 2017-10-22 13:07 ` Enrico Jörns 2017-10-23 15:24 ` Kilimci, Caglar 0 siblings, 1 reply; 7+ messages in thread From: Enrico Jörns @ 2017-10-22 13:07 UTC (permalink / raw) To: Kilimci, Caglar; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] [External] Re: Only Application FS Update 2017-10-22 13:07 ` Enrico Jörns @ 2017-10-23 15:24 ` Kilimci, Caglar 2017-10-25 11:29 ` Enrico Jörns 0 siblings, 1 reply; 7+ messages in thread From: Kilimci, Caglar @ 2017-10-23 15:24 UTC (permalink / raw) To: Enrico Jörns; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] [External] Re: Only Application FS Update 2017-10-23 15:24 ` Kilimci, Caglar @ 2017-10-25 11:29 ` Enrico Jörns 2017-10-25 11:44 ` Kilimci, Caglar 0 siblings, 1 reply; 7+ messages in thread From: Enrico Jörns @ 2017-10-25 11:29 UTC (permalink / raw) To: Kilimci, Caglar; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] [External] Re: Only Application FS Update 2017-10-25 11:29 ` Enrico Jörns @ 2017-10-25 11:44 ` Kilimci, Caglar 0 siblings, 0 replies; 7+ messages in thread From: Kilimci, Caglar @ 2017-10-25 11:44 UTC (permalink / raw) To: Enrico Jörns; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-10-25 11:44 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-18 12:45 [RAUC] Only Application FS Update Kilimci, Caglar 2017-10-18 21:30 ` Enrico Jörns 2017-10-19 10:41 ` [RAUC] [External] " Kilimci, Caglar 2017-10-22 13:07 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox