From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: MIME-Version: 1.0 References: <592943eab0a32f9e1b892960e84e0524a6f56c14.camel@pengutronix.de> <15aea096a6b8e1a533d9d8069118889fb2dd5d81.camel@pengutronix.de> In-Reply-To: <15aea096a6b8e1a533d9d8069118889fb2dd5d81.camel@pengutronix.de> From: Brian Hutchinson Date: Thu, 17 Jun 2021 08:42:09 -0400 Message-ID: Content-Type: multipart/alternative; boundary="000000000000c02a4b05c4f589ab" Subject: Re: [RAUC] Create bundles from command line outside of yocto? To: =?UTF-8?Q?Enrico_J=C3=B6rns?= Cc: rauc@pengutronix.de, =?UTF-8?Q?Jan_L=C3=BCbbe?= List-ID: --000000000000c02a4b05c4f589ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Enrico, On Thu, Jun 17, 2021 at 6:20 AM Enrico J=C3=B6rns wrot= e: > Hi Brian, > > Am Mittwoch, dem 16.06.2021 um 08:45 -0400 schrieb Brian Hutchinson: > > > If you have a separate shared data partition, then I would recommend = to > > > configure RAUC to use this for its status file (which cannot be locat= ed > > > inside > > > the slot anymore when having "ro by design"): > > > > > > [system] > > > ... > > > statusfile=3D/path/to/datapart/rauc.status > > > > > > See https://rauc.readthedocs.io/en/latest/reference.html#statusfile > > > > > > > > > I'll check that out. I'm using u-boot so I "thought" all the status > stuff was > > being done with u-boot environment variables via fw_setenv/fw_printenv. > > u-boot is used for the partition/slot switching only. > This is sufficient for basic functionality of of RAUC. > > In the status file we store some additional information, like when and ho= w > often > a slot was updated, or which bundle version it is running. > You get this for example when running "rauc status --detailed". > > > Was it my imagination or did RAUC populate my rootfs during the update > faster > > than when I just mount and manually untar my rootfs? How is it you guy= s > are > > faster? > > Sounds interesting, but I cannot tell because I don't know what you did t= o > untar > ;) > But actually there is no magic. We simply call 'tar' to unpack. Maybe > you've > used a slower (de)compression algorithm when testing manually? > I bet it's because I'm in the habit of using xvf ... the 'v' is slowing it down. B --000000000000c02a4b05c4f589ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Enrico,

On Thu, Jun 17, 2021 at 6:20 AM Enrico = J=C3=B6rns <ejo@pengutronix.de= > wrote:
Hi B= rian,

Am Mittwoch, dem 16.06.2021 um 08:45 -0400 schrieb Brian Hutchinson:
> > If you have a separate shared data partition, then I would recomm= end to
> > configure RAUC to use this for its status file (which cannot be l= ocated
> > inside
> > the slot anymore when having "ro by design"):
> >
> > =C2=A0 [system]
> > =C2=A0 ...
> > =C2=A0 statusfile=3D/path/to/datapart/rauc.status
> >
> > See=C2=A0https://rauc.readt= hedocs.io/en/latest/reference.html#statusfile
> >
>
>
> I'll check that out.=C2=A0 I'm using u-boot so I "thought= " all the status stuff was
> being done with u-boot environment variables via fw_setenv/fw_printenv= .

u-boot is used for the partition/slot switching only.
This is sufficient for basic functionality of of RAUC.

In the status file we store some additional information, like when and how = often
a slot was updated, or which bundle version it is running.
You get this for example when running "rauc status --detailed".
> Was it my imagination or did RAUC populate my rootfs during the update= faster
> than when I just mount and manually untar my rootfs?=C2=A0 How is it y= ou guys are
> faster?

Sounds interesting, but I cannot tell because I don't know what you did= to untar
;)
But actually there is no magic. We simply call 'tar' to unpack. May= be you've
used a slower (de)compression algorithm when testing manually?

I bet it's because I'm in the habit of usin= g xvf ... the 'v' is slowing it down.

B


--000000000000c02a4b05c4f589ab--