From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gU9Tk-0000K1-EL for rauc@pengutronix.de; Tue, 04 Dec 2018 13:07:04 +0100 Received: by mail-io1-xd35.google.com with SMTP id r9so5943151ioa.1 for ; Tue, 04 Dec 2018 04:07:04 -0800 (PST) MIME-Version: 1.0 References: <454fb88a-2909-acfc-5c63-e139d5fccb34@pengutronix.de> In-Reply-To: <454fb88a-2909-acfc-5c63-e139d5fccb34@pengutronix.de> From: Abhishek Kumar Rai Date: Tue, 4 Dec 2018 17:36:51 +0530 Message-ID: Subject: Re: [RAUC] Query regarding rauc List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1942992194==" Errors-To: rauc-bounces@pengutronix.de Sender: "RAUC" To: Enrico Joerns Cc: rauc@pengutronix.de --===============1942992194== Content-Type: multipart/alternative; boundary="0000000000007aa187057c311aa9" --0000000000007aa187057c311aa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Enrico, Thanks for the prompt response! Please find our responses inline (blue colored) Regards, Abhishek Rai On Tue, Dec 4, 2018 at 4:54 PM Enrico Joerns wrote: > Hi Abhishek, > > On 12/4/18 12:12 PM, Abhishek Kumar Rai wrote: > > Hi Team, > > > > > > To achieve a specific requirement for us the "rauc install" command > won't work i.e due to a configuration that we have the rauc install would > fail. Though we would still like to go ahead and flashload to that > partition. We would like to know if the approach below is correct > > > > > > Our understanding of rauc install suggests that it does the following > things: > > > > 1. Verify signature of the bundle > > 2. Run partition selection algorithm > > 3. Extract the tar balls from the bundle > > 4. Create new ext4 FS on the selected partition > > 5. Write appropriate tar ball to the partition > > > > > > Since "rauc install" would give us errors due to our configuration we > plan to achieve this using the steps below: > > > > 1. Verify signature of the bundle (rauc info ...) > > 2. Partition selection algorithm (we would like to skip this) > > 3. Extract the tar balls from the bundle (rauc extract ..) > > 4. Create new ext4 FS on the selected partition + Write appropriate ta= r > ball to the partition (rauc write-slot ... ....) > > how do you trigger the custom installation? Do you use the full-custom > RAUC install handler? > No for now we have replaced the "rauc install" call with the calls to the > commands "rauc info + rauc extract + rauc write-slot". We were thinking > that we might not get control due to slot selection algorithm. But we wil= l > explore this further starting today. Get a feeling it would be what we > want. Though we read in the documentation that the pre/post install hooks > would not work with full custom install. We might need them. Not too sure > though. We might be able to merge the "post-install" hook work with the > "install" hook > > Extracting the tar's should not be required in all cases. With the > full-custom handler you > will already have it mounted, otherwise you can simply mount the bundle > after verification > as it is basically a squashfs. > Sure.. > > For rauc write-slot you also rely on parts of the system.conf, but not in > the fixed scheme. > If that is where your issue resides, you should be fine with that. > Sure. We were also considering referring to the manifest file when the > bundle gets mounted > > Could you give me a hint what forces you to do this kind of manual > handling? > Maybe then we can think about a possible solution more targeted. > - For now, we have 4 partitions containing rfs.0, rfs.1, appfs.0 and appfs.1. We would like to have a scheme where only the partition that ha= s been flashed with bundle data is changed i.e lets say currently we are using rfs.0 and appfs.0. Now if we flash a bundle containing appfs, on n= ext reboot, system should use rfs.0 and appfs.*1*. Similarly for rfs. - To achieve this we started without a parent child relationship in system.conf. So when we are executing from appfs.0 and rfs.0 and we try = to flash a bundle containing appfs, it would try to write to appfs.0 which would already be in use and hence we would get errors. So we introduced = the parent child relationship - Now *with* parent child relationship the issue above would be resolved. Now when we boot from "rfs.0" and execute apps from "appfs.0" = and flash a appfs bundle it would write to appfs.1. On reboot, as per our scheme we would boot from "rfs.0" and execute apps from "appfs.1". Now w= hen we try to do a rauc install it would write to "appfs.1" as it would consider appfs.0 as active partition due to parent-child relationship. - Hence as we were running into all these issues we felt that it would help our cause if we had our own slot selection logic. Hence the deviati= on to rauc info + rauc extract + rauc write-slot. > But basically it should work as described above, yes. > One thing will miss, depending on what you actually try to do. > The key for atomic updates is to deactivate the bootable slot you > write your image to before writing and set it as primary after successful > writing. > > You can achieve this behavior with > > rauc status mark-bad > > [ perform update ] > > rauc status mark-active > Sure.. we will include this in our scheme.. > > Best regards, Enrico > > -- > Pengutronix e.K. | Enrico J=C3=B6rns = | > 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 = | > > --=20 The information contained in this e-mail message (including=20 any=C2=A0 attachments) may be confidential, proprietary, privileged, or=20 otherwise exempt from disclosure under applicable laws. It is intended to=20 be=C2=A0 conveyed only to the designated recipient(s). Any use, dissemination,=C2=A0 distribution, printing, retaining or copying of this e-mail (including=20 its=C2=A0 attachments) by unintended recipient(s) is strictly prohibited and=20 may=C2=A0 be unlawful. If you are not an intended recipient of this e-mail, or=20 believe=C2=A0 that you have received this e-mail in error, please notify the=20 sender=C2=A0 immediately (by replying to this e-mail), delete any and all=20 copies of=C2=A0 this e-mail (including any attachments) from your system, and=20 do not disclose the content of this e-mail to any other person. Thank you=20 for your cooperation. --=20 _This e-mail message (including any=C2=A0attachments) may be confidential,= =20 proprietary, privileged, or otherwise=C2=A0exempt from disclosure under=20 applicable laws. If you are not an intended recipient, please delete this= =20 message. Thank you. _ --0000000000007aa187057c311aa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Enrico,

Thanks for the pr= ompt response!

Please find our responses inli= ne (blue colored)

Regards,
Abhishek = Rai

On Tue,= Dec 4, 2018 at 4:54 PM Enrico Joerns <ejo@pengutronix.de> wrote:
Hi Abhishek,

On 12/4/18 12:12 PM, Abhishek Kumar Rai wrote:
> Hi Team,
>
>
> To achieve a specific requirement for us the "rauc install" = command won't work i.e due to a configuration that we have the rauc ins= tall would fail. Though we would still like to go ahead and flashload to th= at partition. We would like to know if the approach below is correct
>
>
> Our understanding of rauc install suggests that it does the following = things:
>
>=C2=A0 1. Verify signature of the bundle
>=C2=A0 2. Run partition selection algorithm
>=C2=A0 3. Extract the tar balls from the bundle
>=C2=A0 4. Create new ext4 FS on the selected partition
>=C2=A0 5. Write appropriate tar ball to the partition
>
>
> Since "rauc install" would give us errors due to our configu= ration we plan to achieve this using the steps below:
>
>=C2=A0 1. Verify signature of the bundle (rauc info ...)
>=C2=A0 2. Partition selection algorithm (we would like to skip this) >=C2=A0 3. Extract the tar balls from the bundle (rauc extract ..)
>=C2=A0 4. Create new ext4 FS on the selected partition + Write appropri= ate tar ball to the partition (rauc write-slot ... ....)

how do you trigger the custom installation? Do you use the full-custom RAUC= install handler?
No for now we have replaced the "ra= uc install" call with the calls to the commands "rauc info + rauc= extract + rauc write-slot". We were thinking that we might not get co= ntrol due to slot selection algorithm. But we will explore this further sta= rting today. Get a feeling it would be what we want. Though we read in the = documentation that the pre/post install hooks would not work with full cust= om install. We might need them. Not too sure though. We might be able to me= rge the "post-install" hook work with the "install" hoo= k
=C2=A0
Extracting the tar's should not be required in all cases. With the full= -custom handler you
will already have it mounted, otherwise you can simply mount the bundle aft= er verification
as it is basically a squashfs.
Sure..
=C2= =A0
For rauc write-slot you also rely on parts of the system.conf, but not in t= he fixed scheme.
If that is where your issue resides, you should be fine with that.
Sure. We were also considering referring to the manifest file when the bund= le gets mounted

Could you give me a hint what forces you to do this kind of manual handling= ?
Maybe then we can think about a possible solution more targeted.
<= /blockquote>
  • For now, we hav= e 4 partitions containing rfs.0, rfs.1, appfs.0 and appfs.1. We would like = to have a scheme where only the partition that has been flashed with bundle= data is=C2=A0 changed i.e lets say currently we are using rfs.0 and appfs.= 0. Now if we flash a bundle containing appfs, on next reboot, system should= use rfs.0 and appfs.1. Similarly for rfs.
  • To achieve this we starte= d without a parent child relationship in system.conf. So when we are execut= ing from appfs.0 and rfs.0 and we try to flash a bundle containing appfs, i= t would try to write to appfs.0 which would already be in use and hence we = would get errors. So we introduced the parent child relationship
    =
  • Now with= parent child relationship the issue above would be resolved. Now when = we boot from "rfs.0" and execute apps from "appfs.0" an= d flash a appfs bundle it would write to appfs.1. On reboot, as per our sch= eme we would boot from "rfs.0" and execute apps from "appfs.= 1". Now when we try to do a rauc install it would write to "appfs= .1" as it would consider appfs.0 as active partition due to parent-chi= ld relationship.
  • Hence as we were running into all these issues we felt that it = would help our cause if we had our own slot selection logic. Hence the devi= ation to rauc info + rauc extract + rauc write-slot.

But basically it should work as described above, yes.
One thing will miss, depending on what you actually try to do.
The key for atomic updates is to deactivate the bootable slot you
write your image to before writing and set it as primary after successful w= riting.

You can achieve this behavior with

=C2=A0 =C2=A0rauc status mark-bad <slot-to-update>

=C2=A0 =C2=A0[ perform update ]

=C2=A0 =C2=A0rauc status mark-active <slot-to-update>
Sure.. we will include this in our scheme..

Best regards, Enrico

--
Pengutronix e.K.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Enrico J=C3=B6rns=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
Industrial Linux Solutions=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| http://www.pengutronix.de/=C2=A0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |<= br> Amtsgericht Hildesheim, HRA 2686=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Fax:=C2=A0 =C2=A0+49-5121-206917-5555 |


The information contained in this e-mail message (including any=C2= =A0

attachments) may be confidential, proprietary, privileged, or othe= rwise

exempt from disclosure under applicable laws. It is intended to be= =C2=A0

conveyed only to the designated recipient(s). Any use, disseminati= on,=C2=A0

distribution, printing, retaining or copying of this e-mail (inclu= ding its=C2=A0

attachments) by unintended recipient(s) is strictly prohibited and= may=C2=A0

be unlawful. If you are not an intended recipient of this e-mail, = or believe=C2=A0

that you have received this e-mail in error, please notify the sen= der=C2=A0

immediately (by replying to this e-mail), delete any and all copie= s of=C2=A0

this e-mail (including any attachments) from your system, and do n= ot

disclose the content of this e-mail to any other person. Thank you= for your cooperation.


This e-mail message (including any=C2=A0attachments) may be= confidential, proprietary, privileged, or otherwise=C2=A0exempt from discl= osure under applicable laws. If you are not an intended recipient, please d= elete this message. Thank you.
--0000000000007aa187057c311aa9-- --===============1942992194== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUkFVQyBtYWls aW5nIGxpc3Q= --===============1942992194==--