On Fri, Jul 30, 2021 at 12:29 PM Jan Lübbe <j...@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: failed 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. Slot A was activated > but not > > booted. But it looks like maybe it was using slot A /etc/rauc/system.conf > > 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 your > case. > > > [slot.appfs.1] > > device=/dev/mapper/crypt_appfs2 > > type=ext4 > > parent=rootfs.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 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 > could > use, though. > > The device= properties will follow symlinks. So you could handle the switch > 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 the > /dev/appfs[12] link to /dev/mapper/crypt_appfs[12]). > > The system.conf would then point to device=/dev/appfs[12]. > > Then add a pre-install handler: > > https://rauc.readthedocs.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! 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 += "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
_______________________________________________ RAUC mailing list
