On Wed, Jun 16, 2021 at 1:06 AM Enrico Jörns wrote: > Hi Brian, > > Am Dienstag, dem 15.06.2021 um 17:32 -0400 schrieb Brian Hutchinson: > > Ok, I think I figured out my problems. Appears that I was using busybox > > version of tar so I switched to the real thing (GNU Tar) and that fixed > one > > problem then I ran into a mkfs.vfat problem and I added dosfstools to my > image > > and that took care of that so now my bundle is updating correctly now > ... so > > sorry for the noise! > > glad you solved it! > > You could actually use busybox tar, too. But then you need to make sure > to have > enabled format autodetection and the required compression algorithm, see: > > https://rauc.readthedocs.io/en/latest/integration.html#required-target-tools > > About your original questions: > > > So I should use "parent" to tie both kernel and appfs slots to the > rootfs? > > Your system.conf (and parent relations) looked good from what I saw. > > > And for now, the rootfs is r/w on a ext4 filesystem, but in the future > it will > > be a squashfs. So once that happens would 'type=ext4' then change to > > 'type=raw'? > > Yes, 'raw' will be fine for squashfs as there is an explicit handler > available > for it. The 'raw' type ensures RAUC does not think it could mount the > bundle for > writing. > > 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 located > inside > the slot anymore when having "ro by design"): > > [system] > ... > statusfile=/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. 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 guys are faster? Thanks again! Regards, Brian