Hi Abhishek,
On 12/4/18 12:12 PM, Abhishek Kumar Rai wrote:
> Hi Team,
>
>
> To achieve a specific requirement for us the "rauc install" command won't work i.e due to a configuration that we have the rauc install would fail. Though we would still like to go ahead and flashload to that partition. We would like to know if the approach below is correct
>
>
> 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
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.Sure. We were also considering referring to the manifest file when the bundle gets mounted
If that is where your issue resides, you should be fine with that.
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.
Sure.. we will include this in our scheme..
But basically it should work as described above, yes.
One thing will miss, depending on what you actually try to do.
The key for atomic updates is to deactivate the bootable slot you
write your image to before writing and set it as primary after successful writing.
You can achieve this behavior with
rauc status mark-bad <slot-to-update>
[ perform update ]
rauc status mark-active <slot-to-update>
Best 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 |
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for your cooperation. |