Re: [RAUC] Query regarding rauc

[Enrico Joerns <ejo@pengutronix.de>]

Hi Abhishek,

On 12/4/18 1:06 PM, Abhishek Kumar Rai wrote:
> Hi Enrico,
> 
> Thanks for the prompt response!
> 
> Please find our responses inline (blue colored)

you're lucky that I've a graphical mailer... ;)
Better use standard mail quoting.

>> 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 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
> "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 will 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

You want to have a look at this sections:

https://rauc.readthedocs.io/en/latest/using.html#full-custom-update

> 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
> has 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 next 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 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-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 deviation to rauc info + rauc extract + rauc write-slot.

Ok, I think I got your base motivation.

What do you do to assure that the right appfs is used?
Is that mechanism atomic? I.e. when you are interrupted between update
of appfs, does it still boot the valid one?

In general, as you might have read, our strict design case and
recommendation is that you only install well-tested sets of all pieces
of software. If you use it as an 'app store' maybe that is note a task
for RAUC?

But, what speaks against having both rootfs and appfs updated together?
Is that installation time / bundle size?

Note that RAUC will skip the actual update of the rootfs anyway if the
slot's hash matches the hash of the image to install. Thus if you do not
change the rootfs content across multiple instalations, it will skip
the rootfs writing, anyway.


Another concept to thinks about is (if you insist on updating the
appfs separately), if you do not move the switching point entirely to
be in the rootfs. Then RAUC would incorporate with the appfs-selection
logic you currently use. Might need some extension for using custom boot
selection scripts, but this is on our list anyway.

The open question would be if you also intend to update your rootfs and
if it is ok to never update the appfs and rootfs together, as this would
not work with my approach.


Regards, Enrico

-- 
Pengutronix e.K.                           | Enrico Jörns                |
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 |


_______________________________________________
RAUC mailing list