From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: MIME-Version: 1.0 References: <1fa4195021526f8ef22b79c11ce5f1b39f0ebbaa.camel@pengutronix.de> <7a45d808c119e373c55163492003751229b4aab0.camel@pengutronix.de> In-Reply-To: <7a45d808c119e373c55163492003751229b4aab0.camel@pengutronix.de> From: Brian Hutchinson Date: Mon, 2 Aug 2021 11:22:09 -0400 Message-ID: Content-Type: multipart/alternative; boundary="000000000000a0a96a05c8952265" Subject: Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it To: =?UTF-8?Q?Jan_L=C3=BCbbe?= , rauc@pengutronix.de List-ID: --000000000000a0a96a05c8952265 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 30, 2021 at 12:29 PM Jan L=C3=BCbbe wrote: > Hi Brian, > > On Fri, 2021-07-30 at 10:20 -0400, Brian Hutchinson wrote: > > > 100% Installing failed. > > > LastError: Installation error: Failed updating slot appfs.1: failed t= o > run > > > mkfs.ext4: Child process exited with code 1 > > > Installing `/tmp/./update-myboard.raucb` failed > > > > > > But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and > the > > > filesystem is fine. > > > > > > Looks like I'm missing something still. > > Hmm, you should have more logs on the rauc service side, possible also > with an > error message from mkfs.ext4. > > > > > So I think my issue was because I was nfs booted. Slot A was activated > but not > > booted. But it looks like maybe it was using slot A /etc/rauc/system.co= nf > > instead of the currently running nfs instance /etc/rauc/system.conf > because what > > I tried before worked once I mounted /dev/mmcblk2gp0p2 and changed that > > /etc/rauc/system.conf to: > > It should use /etc/rauc/system.conf from the mounted rootfs, so NFS in yo= ur > case. > > > [slot.appfs.1] > > device=3D/dev/mapper/crypt_appfs2 > > type=3Dext4 > > parent=3Drootfs.1 > > > > So this brings up a question. If I have boards out in the field and > appfs goes > > from plain ext4 to encrypted, I somehow need to update the currently > running > > /etc/rauc/system.conf file first before performing an update??? How to > handle > > system.conf changes? > > The system.conf contents should describe the details of the system than > don't > change during updates. Generally, partitioning changes are not possible i= n > an > atomic A/B way, so those are not really in scope for RAUC. :/ > > Getting such a migration correct in the field is difficult. Something you > could > use, though. > > The device=3D properties will follow symlinks. So you could handle the sw= itch > between unencrypted and encrypted in a script before starting the rauc > service > and before mounting the current appfs. > > For both sides, you'd check if it already contains a luks header. If not, > it's > an old version which doesn't support encryption yet, so you link > /dev/mmcblk... > to /dev/appfs[12]. > If if already contains that header, attach the crypt device. The setup th= e > /dev/appfs[12] link to /dev/mapper/crypt_appfs[12]). > > The system.conf would then point to device=3D/dev/appfs[12]. > > Then add a pre-install handler: > > https://rauc.readthedocs.io/en/latest/using.html#system-based-customizati= on-handlers > It can check if the target slot link still points to the unencrypted > device. In > that case, it can setup the crypt device and change the link. RAUC > should(*) > then follow the updated link to the encrypted device when installing. > > Hope that helps... :) > > Hi Jan, Yes! Thanks. Now my problem is I have a very small 32M NOR flash and I have a 11M SquashFS rootfs based off core-image-minimal. I added packagegroup-luks and it blew size up to 47M. I then just tried to CORE_IMAGE_EXTRA_INSTALL +=3D "cryptsetup" and that was still a 35M rootfs so now I'm stumped trying to figure out if it's possible to get encryption support in my NOR flash image we boot from :( Regards, Brian --000000000000a0a96a05c8952265 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 30, 2021 at 12:29 PM Jan L=C3=BCbbe <jlu@pengutronix.de> wrote:
Hi Brian,

On Fri, 2021-07-30 at 10:20 -0400, Brian Hutchinson wrote:
> > 100% Installing failed.
> > LastError: Installation error: Failed updating slot appfs.1: fail= ed to run
> > mkfs.ext4: Child process exited with code 1
> > Installing `/tmp/./update-myboard.raucb` failed
> >
> > But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it = and the
> > filesystem is fine.
> >
> > Looks like I'm missing something still.

Hmm, you should have more logs on the rauc service side, possible also with= an
error message from mkfs.ext4.

>
> So I think my issue was because I was nfs booted.=C2=A0 Slot A was act= ivated but not
> booted. But it looks like maybe it was using slot A /etc/rauc/system.c= onf
> instead of the currently running nfs instance /etc/rauc/system.conf be= cause what
> I tried before worked once I mounted /dev/mmcblk2gp0p2 and changed tha= t
> /etc/rauc/system.conf to:

It should use /etc/rauc/system.conf from the mounted rootfs, so NFS in your=
case.

> =C2=A0[slot.appfs.1]
> device=3D/dev/mapper/crypt_appfs2
> type=3Dext4
> parent=3Drootfs.1
>
> So this brings up a question.=C2=A0 If I have boards out in the field = and appfs goes
> from plain ext4 to encrypted, I somehow need to update the currently r= unning
> /etc/rauc/system.conf file first before performing an update???=C2=A0 = How to handle
> system.conf changes?

The system.conf contents should describe the details of the system than don= 't
change during updates. Generally, partitioning changes are not possible in = an
atomic A/B way, so those are not really in scope for RAUC. :/

Getting such a migration correct in the field is difficult. Something you c= ould
use, though.

The device=3D properties will follow symlinks. So you could handle the swit= ch
between unencrypted and encrypted in a script before starting the rauc serv= ice
and before mounting the current appfs.

For both sides, you'd check if it already contains a luks header. If no= t, it's
an old version which doesn't support encryption yet, so you link /dev/m= mcblk...
to /dev/appfs[12].
If if already contains that header, attach the crypt device. The setup the<= br> /dev/appfs[12] link to /dev/mapper/crypt_appfs[12]).

The system.conf would then point to device=3D/dev/appfs[12].

Then add a pre-install handler:
https://rauc.rea= dthedocs.io/en/latest/using.html#system-based-customization-handlers It can check if the target slot link still points to the unencrypted device= . In
that case, it can setup the crypt device and change the link. RAUC should(*= )
then follow the updated link to the encrypted device when installing.

Hope that helps... :)


Hi Jan,

Yes!= =C2=A0 Thanks.

Now my problem is I have a very sma= ll 32M NOR flash and I have a 11M SquashFS rootfs based off core-image-mini= mal.=C2=A0 I added packagegroup-luks and it blew size up to 47M.=C2=A0 I th= en just tried to CORE_IMAGE_EXTRA_INSTALL += =3D "cryptsetup" and that was still a 35M rootfs so now I'm s= tumped trying to figure out if it's possible to get encryption support = in my NOR flash image we boot from :(

Regards,
<= span style=3D"color:rgb(0,0,0);background-color:rgb(255,255,255)">
Brian
--000000000000a0a96a05c8952265--