Re: [RAUC] [External] Re: Custom Installation

["Kilimci, Caglar" <caglar.kilimci@accenture.com>]

Hi Enrico,

Thank you for your reply.

>> rauc:ERROR:../git/src/install.c:294:determine_target_install_group:
>> assertion failed (slotclasses->len > 0): (0 > 0) Jul 12 11:03:20 phyboard-regor-am335x-1 daemon.notice systemd[1]: rauc.service: Main process exited, code=killed, status=6/ABRT Jul 12 11:03:20 phyboard-regor-am335x-1 daemon.notice systemd[1]: rauc.service: Unit entered failed state.
>> Jul 12 11:03:21 phyboard-regor-am335x-1 daemon.warn systemd[1]: rauc.service: Failed with result 'signal'.
>
>hm, it looks as if you have a system.conf that does not have any slots defined, yet. Is that true?

Actually there are 2 stots. Here is the system.conf:
root@phyboard-regor-am335x-1:~# cat /etc/rauc/system.conf
[system]
compatible=Phytec
bootloader=barebox

[keyring]
path=ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system1

[slot.rootfs.1]
device=/dev/mmcblk0p3
type=ext4
bootname=system2


>RAUC is not designed for this very special case it seems and I am not sure if it should support this.
It would be so good and introduce new functiality. As an example, a deployment server for updates is already requirement. With this functionality, this deployment server can deploy a custom script, too. In addition, there is not so much development involved because RAUC already has "this" function.

>> PS: By the way, documentation of handler [1] is out of date, I guess. Group name is changed from handlers to handler and does not accept key value of *install. If you explain more, I can update and send you pull request.
>>
>> Thank you for your help.
>
>Well, this can truely be a bit confusing, but I thing everything is fine for now.
>
>
>* [handler]
>  This section is for the Bundle *Manifest* and its only purpose is to
>define a full-custom installation behavior (something that should be
>used for debugging or system fixing, only)
>
>* [handlers]
>  This section is for the *System Configuration* and allows to specify
>some handler scripts that can be called during the default installation
>routine, for example as pre- or post-install handlers.
>
>Finally, the similar mechanism as [handlers] exists for Bundle
>*Manifests*, too. Here they are referred to as [hooks] (to not confuse
>too much with then [handler] section).
>
>
>Hope that pointed it out a bit more clearly?

Yes, thank you.

Best Regards,
Caglar Kilimci

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
_______________________________________________
RAUC mailing list