swupdate_vars.c : swupdate_vars_get : 89 : Failed to get variable action_id
616 views
Skip to first unread message
vincent....@gmail.com
May 31, 2024, 11:27:09 AM5/31/24
to swupdate
Hello,
I'm using suricatta and I have following issue during kirkstone to scarthgap migration.
After successfull install from hawkbit, my board reboots and fails to set OK status back to the server.
I guess it comes from following patch series:
"hawkbit: use stored action_id instead of current"
For what I understand, "action_id" shall be saved into SWUpdate's variable, but I'm not familiar with this "new" feature. I read https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables and maybe the need to set "namespace-vars" but I can't find any example for this simple legacy usecase ?
action_id couldn't be saved in bootloader file? (I use grub)
I'm a bit lost if someone can help?
Thanks by advance,
Vincent
I'm using suricatta and I have following issue during kirkstone to scarthgap migration.
After successfull install from hawkbit, my board reboots and fails to set OK status back to the server.
I guess it comes from following patch series:
"hawkbit: use stored action_id instead of current"
For what I understand, "action_id" shall be saved into SWUpdate's variable, but I'm not familiar with this "new" feature. I read https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables and maybe the need to set "namespace-vars" but I can't find any example for this simple legacy usecase ?
action_id couldn't be saved in bootloader file? (I use grub)
I'm a bit lost if someone can help?
Thanks by advance,
Vincent
Stefano Babic
Jun 1, 2024, 9:00:21 AM6/1/24
to vincent....@gmail.com, swupdate
Hi Vincent,
On 31.05.24 17:27, vincent....@gmail.com wrote:
> Hello,
>
> I'm using suricatta and I have following issue during kirkstone to
> scarthgap migration.
> After successfull install from hawkbit, my board reboots and fails to
> set OK status back to the server.
>
> I guess it comes from following patch series:
> "hawkbit: use stored action_id instead of current"
>
> For what I understand, "action_id" shall be saved into SWUpdate's
> variable,
SWUpdate tries to read action-id from bootloader environment, and it
fallbacks to ask the server in case no variable is found.
> but I'm not familiar with this "new" feature. I read
> https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables and maybe the need to set "namespace-vars" but I can't find any example for this simple legacy usecase ?
>
> action_id couldn't be saved in bootloader file? (I use grub)
>
It is.
Best regards,
Stefano Babic
> I'm a bit lost if someone can help?
>
> Thanks by advance,
> Vincent
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 31.05.24 17:27, vincent....@gmail.com wrote:
> Hello,
>
> I'm using suricatta and I have following issue during kirkstone to
> scarthgap migration.
> After successfull install from hawkbit, my board reboots and fails to
> set OK status back to the server.
>
> I guess it comes from following patch series:
> "hawkbit: use stored action_id instead of current"
>
> For what I understand, "action_id" shall be saved into SWUpdate's
> variable,
fallbacks to ask the server in case no variable is found.
> but I'm not familiar with this "new" feature. I read
> https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables and maybe the need to set "namespace-vars" but I can't find any example for this simple legacy usecase ?
>
> action_id couldn't be saved in bootloader file? (I use grub)
>
Best regards,
Stefano Babic
> I'm a bit lost if someone can help?
>
> Thanks by advance,
> Vincent
>
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer>.
vincent....@gmail.com
Jun 3, 2024, 5:30:35 AM6/3/24
to swupdate
Hello again,
For my understanding, "ustate" and "recovery_status" are saved into bootloader with bootloader_env_set whereas "action_id" uses swupdate_vars_set that calls libuboot_env_store.
In my case, I use grub so I feel it will not work?
Best regards,
In my case, I use grub so I feel it will not work?
Best regards,
Vincent
Stefano Babic
Jun 3, 2024, 5:57:38 AM6/3/24
to vincent....@gmail.com, swupdate
Hi Vincent,
On 03.06.24 11:30, vincent....@gmail.com wrote:
> Hello again,
>
> For my understanding, "ustate" and "recovery_status" are saved into
> bootloader with bootloader_env_set whereas "action_id"
> uses swupdate_vars_set that calls libuboot_env_store.
>
swupdate_vars_set() are again wrapper to libuboot calls like
bootloader_env_set() in case of U-Boot, but they accept a namespace.
This allows to split between bootloader and not bootloader variables.
This is independent from the bootloader.bootloader_env_set() will always
call the respective bootloader implementation, in your case Grub.
In case of Grub, you haven't surely configured libubootenv via
fw_env.config. Due to this and some other new features, the library has
become mandatory.
However, it is thought to be compatible - there should be some issue. In
server_handle_initial_state(), the action_id is first retrieved from the
server as it was done in the past. Only in case action_id is found in
environemnt (not grub environment), the new action_id overwrites the one
from server:
937 result = server_get_deployment_info(server_hawkbit.channel,
938
&channel_data, &action_id);
939
940 /*
941 * Get action_id from env, if any
942 */
943 get_action_id_from_env(&action_id);
get_action_id_from_env() shouldn't touch the value retrieved from
server. So in your case, it shouldn't fix the mismatch in case action_id
is changed on the server, what the patchset is doing, but it should work
as before.
But sure, this was fully tested with U-Boot as bootloader, Maybe somne
other side effects ?
Best regards,
Stefano Babic
> In my case, I use grub so I feel it will not work?
>
> Best regards,
> Vincent
>
> Le samedi 1 juin 2024 à 15:00:21 UTC+2, Stefano Babic a écrit :
>
> Hi Vincent,
>
> On 31.05.24 17:27, vincent....@gmail.com wrote:
> > Hello,
> >
> > I'm using suricatta and I have following issue during kirkstone to
> > scarthgap migration.
> > After successfull install from hawkbit, my board reboots and
> fails to
> > set OK status back to the server.
> >
> > I guess it comes from following patch series:
> > "hawkbit: use stored action_id instead of current"
> >
> > For what I understand, "action_id" shall be saved into SWUpdate's
> > variable,
>
> SWUpdate tries to read action-id from bootloader environment, and it
> fallbacks to ask the server in case no variable is found.
>
> > but I'm not familiar with this "new" feature. I read
> >
> https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables <https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables> and maybe the need to set "namespace-vars" but I can't find any example for this simple legacy usecase ?
On 03.06.24 11:30, vincent....@gmail.com wrote:
> Hello again,
>
> For my understanding, "ustate" and "recovery_status" are saved into
> bootloader with bootloader_env_set whereas "action_id"
> uses swupdate_vars_set that calls libuboot_env_store.
>
bootloader_env_set() in case of U-Boot, but they accept a namespace.
This allows to split between bootloader and not bootloader variables.
This is independent from the bootloader.bootloader_env_set() will always
call the respective bootloader implementation, in your case Grub.
In case of Grub, you haven't surely configured libubootenv via
fw_env.config. Due to this and some other new features, the library has
become mandatory.
However, it is thought to be compatible - there should be some issue. In
server_handle_initial_state(), the action_id is first retrieved from the
server as it was done in the past. Only in case action_id is found in
environemnt (not grub environment), the new action_id overwrites the one
from server:
937 result = server_get_deployment_info(server_hawkbit.channel,
938
&channel_data, &action_id);
939
940 /*
941 * Get action_id from env, if any
942 */
943 get_action_id_from_env(&action_id);
get_action_id_from_env() shouldn't touch the value retrieved from
server. So in your case, it shouldn't fix the mismatch in case action_id
is changed on the server, what the patchset is doing, but it should work
as before.
But sure, this was fully tested with U-Boot as bootloader, Maybe somne
other side effects ?
Best regards,
Stefano Babic
> In my case, I use grub so I feel it will not work?
>
> Best regards,
> Vincent
>
> Le samedi 1 juin 2024 à 15:00:21 UTC+2, Stefano Babic a écrit :
>
> Hi Vincent,
>
> On 31.05.24 17:27, vincent....@gmail.com wrote:
> > Hello,
> >
> > I'm using suricatta and I have following issue during kirkstone to
> > scarthgap migration.
> > After successfull install from hawkbit, my board reboots and
> fails to
> > set OK status back to the server.
> >
> > I guess it comes from following patch series:
> > "hawkbit: use stored action_id instead of current"
> >
> > For what I understand, "action_id" shall be saved into SWUpdate's
> > variable,
>
> SWUpdate tries to read action-id from bootloader environment, and it
> fallbacks to ask the server in case no variable is found.
>
> > but I'm not familiar with this "new" feature. I read
> >
> >
> > action_id couldn't be saved in bootloader file? (I use grub)
> >
>
> It is.
>
> Best regards,
> Stefano Babic
>
> > I'm a bit lost if someone can help?
> >
> > Thanks by advance,
> > Vincent
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> > action_id couldn't be saved in bootloader file? (I use grub)
> >
>
> It is.
>
> Best regards,
> Stefano Babic
>
> > I'm a bit lost if someone can help?
> >
> > Thanks by advance,
> > Vincent
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/c0e8f527-61e3-45af-9fb6-dd5316bd0803n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/c0e8f527-61e3-45af-9fb6-dd5316bd0803n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
vincent....@gmail.com
Jun 3, 2024, 11:55:59 AM6/3/24
to swupdate
Thanks for detailed response,
For the moment, I tried to add this configuration to /etc/swupdate.cfg with an existing empty fw_env.config file:
fwenv-config-location = "/boot/EFI/BOOT/fw_env.config";
namespace-vars = "myrandomns";
namespace-vars = "myrandomns";
But swupdate crashes, so it seems I should dig a bit more ;)
ayoub...@googlemail.com
Jul 6, 2024, 6:29:03 AM7/6/24
to swupdate
Hi,
I get the same error using 2024.05.2 with uboot :
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [TRACE] : SWUPDATE running : [server_get_deployment_info] : Associated Action ID for Update Action is 35
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [ERROR] : SWUPDATE failed [0] ERROR swupdate_vars.c : swupdate_vars_get : 89 : Failed to get variable action_id
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [DEBUG] : SWUPDATE running : [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [TRACE] : SWUPDATE running : [channel_post_method] : POST to https://embetrix.works/hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/-1/feedback: { "id": -1, "time": "20240706T102314", "status": { "result": { "progress": { "cnt" : 0, "of" : 0 }, "finished": "success" }, "execution": "closed", "details" : [ "Update Installed." ] } }
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: RUN [channel_log_reply] : Channel operation returned HTTP status code 200.
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: * Found bundle for host: 0x549da0 [serially]
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: * Re-using existing connection with host embetrix.works
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: > POST /hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/-1/feedback HTTP/1.1
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Host: embetrix.works
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: User-Agent: libcurl-agent/1.0
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Content-Type: application/json
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Accept: application/json
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Authorization: GatewayToken 636c5e69b9528752c748da2c86a7a02c
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Content-Length: 187
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]:
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: * upload completely sent off: 187 bytes
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [ERROR] : SWUPDATE failed [0] ERROR swupdate_vars.c : swupdate_vars_get : 89 : Failed to get variable action_id
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [DEBUG] : SWUPDATE running : [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: [TRACE] : SWUPDATE running : [channel_post_method] : POST to https://embetrix.works/hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/-1/feedback: { "id": -1, "time": "20240706T102314", "status": { "result": { "progress": { "cnt" : 0, "of" : 0 }, "finished": "success" }, "execution": "closed", "details" : [ "Update Installed." ] } }
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[462]: RUN [channel_log_reply] : Channel operation returned HTTP status code 200.
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: * Found bundle for host: 0x549da0 [serially]
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: * Re-using existing connection with host embetrix.works
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: > POST /hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/-1/feedback HTTP/1.1
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Host: embetrix.works
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: User-Agent: libcurl-agent/1.0
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Content-Type: application/json
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Accept: application/json
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Authorization: GatewayToken 636c5e69b9528752c748da2c86a7a02c
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: Content-Length: 187
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]:
Jul 06 10:23:14 stm32mp157f-dk2-e1-8f-12 swupdate[484]: * upload completely sent off: 187 bytes
Stefano Babic
Jul 6, 2024, 8:05:02 AM7/6/24
to ayoub...@googlemail.com, swupdate
Hi,
there is a proposed patch by Dominique to maintain compatibility for
action-id and not be forced to switched to the new method. I merged the
patch today.
Best regards,
Stefano
> https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables <https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables> <https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables <https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables>> and maybe the need to set "namespace-vars" but I can't find any example for this simple legacy usecase ?
there is a proposed patch by Dominique to maintain compatibility for
action-id and not be forced to switched to the new method. I merged the
patch today.
Best regards,
Stefano
> > >
> > > action_id couldn't be saved in bootloader file? (I use grub)
> > >
> >
> > It is.
> >
> > Best regards,
> > Stefano Babic
> >
> > > I'm a bit lost if someone can help?
> > >
> > > Thanks by advance,
> > > Vincent
> > >
> > > --
> > > You received this message because you are subscribed to the
> Google
> > > Groups "swupdate" group.
> > > To unsubscribe from this group and stop receiving emails
> from it,
> > send
> > > an email to swupdate+u...@googlegroups.com
> > > <mailto:swupdate+u...@googlegroups.com>.
> > > To view this discussion on the web visit
> > >
> >
> https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com>> <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/8f5485fa-8132-4d5f-8296-01dc864eadf7n%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
> > > action_id couldn't be saved in bootloader file? (I use grub)
> > >
> >
> > It is.
> >
> > Best regards,
> > Stefano Babic
> >
> > > I'm a bit lost if someone can help?
> > >
> > > Thanks by advance,
> > > Vincent
> > >
> > > --
> > > You received this message because you are subscribed to the
> > > Groups "swupdate" group.
> > > To unsubscribe from this group and stop receiving emails
> from it,
> > send
> > > an email to swupdate+u...@googlegroups.com
> > > <mailto:swupdate+u...@googlegroups.com>.
> > > To view this discussion on the web visit
> > >
> >
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/swupdate/c0e8f527-61e3-45af-9fb6-dd5316bd0803n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/c0e8f527-61e3-45af-9fb6-dd5316bd0803n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/c0e8f527-61e3-45af-9fb6-dd5316bd0803n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/c0e8f527-61e3-45af-9fb6-dd5316bd0803n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> > --
> > You received this message because you are subscribed to the
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion on the web visit
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/f9c7893c-9bf6-497f-812b-e2c97de2dff2n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/f9c7893c-9bf6-497f-812b-e2c97de2dff2n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
ayoub...@googlemail.com
Jul 6, 2024, 9:25:51 AM7/6/24
to swupdate
Hi Stefano,
thanks for the heads up.
much appreciated.
Best regards,
ayoub...@googlemail.com
Jul 8, 2024, 7:10:00 AM7/8/24
to swupdate
Hello Stefano,
I tried the actual master,
still getting:
ul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: Authorization: GatewayToken 636c5e69b9528752c748da2c86a7a02c
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: Content-Length: 187
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]:
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: * upload completely sent off: 187 bytes
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [parse_reply] : Got channel reply: {"id":"39","deployment":{"download":"forced","update":"forced","chunks":[{"part":"os","version":"0.5.0-18-g704a7dc","name":"ozyx-image-qtdemo-update","artifacts":[{"filename":"ozyx-image}
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: [ERROR] : SWUPDATE failed [0] ERROR swupdate_vars.c : swupdate_vars_get : 93 : Failed to get variable action_id
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: [DEBUG] : SWUPDATE running : [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: [TRACE] : SWUPDATE running : [channel_post_method] : POST to https://embetrix.works/hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/39/feedback: { "id": 39, "time": "20240708T110825", "status": { "resul}
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [server_get_deployment_info] : Associated Action ID for Update Action is 39
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: FAILURE ERROR swupdate_vars.c : swupdate_vars_get : 93 : Failed to get variable action_id
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [channel_post_method] : POST to https://embetrix.works/hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/39/feedback: { "id": 39, "time": "20240708T110825", "status": { "result": { "progress": { "cnt" }
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < HTTP/1.1 200 OK
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Server: nginx/1.18.0 (Ubuntu)
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Date: Mon, 08 Jul 2024 11:08:26 GMT
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Transfer-Encoding: chunked
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Connection: keep-alive
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: Content-Length: 187
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]:
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: * upload completely sent off: 187 bytes
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [parse_reply] : Got channel reply: {"id":"39","deployment":{"download":"forced","update":"forced","chunks":[{"part":"os","version":"0.5.0-18-g704a7dc","name":"ozyx-image-qtdemo-update","artifacts":[{"filename":"ozyx-image}
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: [ERROR] : SWUPDATE failed [0] ERROR swupdate_vars.c : swupdate_vars_get : 93 : Failed to get variable action_id
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: [DEBUG] : SWUPDATE running : [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: [TRACE] : SWUPDATE running : [channel_post_method] : POST to https://embetrix.works/hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/39/feedback: { "id": 39, "time": "20240708T110825", "status": { "resul}
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [server_get_deployment_info] : Associated Action ID for Update Action is 39
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: FAILURE ERROR swupdate_vars.c : swupdate_vars_get : 93 : Failed to get variable action_id
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[449]: RUN [channel_post_method] : POST to https://embetrix.works/hawkbit/default/controller/v1/stm32mp157f-dk2-e1-8f-12/deploymentBase/39/feedback: { "id": 39, "time": "20240708T110825", "status": { "result": { "progress": { "cnt" }
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < HTTP/1.1 200 OK
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Server: nginx/1.18.0 (Ubuntu)
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Date: Mon, 08 Jul 2024 11:08:26 GMT
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Transfer-Encoding: chunked
Jul 08 11:08:25 stm32mp157f-dk2-e1-8f-12 swupdate[481]: < Connection: keep-alive
ayoub...@googlemail.com
Jul 8, 2024, 7:11:58 AM7/8/24
to swupdate
nevertheless the update went through, so it should be warning instead of error.
Dominique MARTINET
Jul 8, 2024, 9:22:00 PM7/8/24
to ayoub...@googlemail.com, swupdate
'ayoub...@googlemail.com' via swupdate wrote on Mon, Jul 08, 2024 at 04:11:58AM -0700:
> nevertheless the update went through, so it should be warning instead of
> error.
Yes, I guess we can downgrade it to warning, but I'd suggest setting up
> nevertheless the update went through, so it should be warning instead of
> error.
environments to work on your system -- this pattern (not having env
vars) is not safe if the hawkbit admin cancels and schedules another
update while your system is rebooting, in which case not storing the
last update value will mark the new update as installed despite not
having been installed (and hawkbit will list the wrong version)
@Stefano -- it's a trivial patch, do you want to do it directly?
Should look into the swupdate crash you reported when you tried to set
the config but it's probably the other problem I fixed with
"swupdate_vars: check namespace init worked" the other day -- if your
fw_env.config did not include a section for the section you requested in
swupdate.cfg then it'd crash instead of showing an error.
That's a config problem though, so fixing fw_env.config should work with
current version (and latest master shouldn't crash anymore but print an
error with the bad config)
--
Dominique
Stefano Babic
Jul 9, 2024, 3:59:12 AM7/9/24
to swup...@googlegroups.com
On 09.07.24 03:21, Dominique MARTINET wrote:
> 'ayoub...@googlemail.com' via swupdate wrote on Mon, Jul 08, 2024 at 04:11:58AM -0700:
>> nevertheless the update went through, so it should be warning instead of
>> error.
>
> Yes, I guess we can downgrade it to warning, but I'd suggest setting up
> environments to work on your system -- this pattern (not having env
> vars) is not safe if the hawkbit admin cancels and schedules another
> update while your system is rebooting, in which case not storing the
> last update value will mark the new update as installed despite not
> having been installed (and hawkbit will list the wrong version)
>
> @Stefano -- it's a trivial patch, do you want to do it directly?
>
Sent the small patch.
> 'ayoub...@googlemail.com' via swupdate wrote on Mon, Jul 08, 2024 at 04:11:58AM -0700:
>> nevertheless the update went through, so it should be warning instead of
>> error.
>
> Yes, I guess we can downgrade it to warning, but I'd suggest setting up
> environments to work on your system -- this pattern (not having env
> vars) is not safe if the hawkbit admin cancels and schedules another
> update while your system is rebooting, in which case not storing the
> last update value will mark the new update as installed despite not
> having been installed (and hawkbit will list the wrong version)
>
> @Stefano -- it's a trivial patch, do you want to do it directly?
>
Stefano
ayoub...@googlemail.com
Jul 9, 2024, 6:04:24 AM7/9/24
to swupdate
Hi,
thanks for the patch, but shouldn't swupdate create/add "action_id" to u-boot environment if not available ?
Best regards
Stefano Babic
Jul 9, 2024, 6:06:37 AM7/9/24
to ayoub...@googlemail.com, swupdate
On 09.07.24 12:04, 'ayoub...@googlemail.com' via swupdate wrote:
> Hi,
>
> thanks for the patch, but shouldn't swupdate create/add "action_id" to
> u-boot environment if not available ?
It is done when it is correctly configured, see
> Hi,
>
> thanks for the patch, but shouldn't swupdate create/add "action_id" to
> u-boot environment if not available ?
https://github.com/sbabic/swupdate/blob/master/suricatta/server_hawkbit.c#L1113
Regards,
Stefano
>
> Best regards
> On Tuesday, July 9, 2024 at 9:59:12 AM UTC+2 Stefano Babic wrote:
>
> On 09.07.24 03:21, Dominique MARTINET wrote:
> > 'ayoub...@googlemail.com' via swupdate wrote on Mon, Jul 08, 2024
> at 04:11:58AM -0700:
> >> nevertheless the update went through, so it should be warning
> instead of
> >> error.
> >
> > Yes, I guess we can downgrade it to warning, but I'd suggest
> setting up
> > environments to work on your system -- this pattern (not having env
> > vars) is not safe if the hawkbit admin cancels and schedules another
> > update while your system is rebooting, in which case not storing the
> > last update value will mark the new update as installed despite not
> > having been installed (and hawkbit will list the wrong version)
> >
> > @Stefano -- it's a trivial patch, do you want to do it directly?
> >
>
> Sent the small patch.
>
> Stefano
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
ayoub...@googlemail.com
Jul 9, 2024, 6:16:31 AM7/9/24
to swupdate
Hi Stefano,
I don't understand your statement "correctly configured" ? u-boot env are enabled in my case and "ustate" variable is also updated.
I think the only thing I'd have differently done is that Suricatta is not running as root, could be the problem cause ?
ayoub...@googlemail.com
Jul 9, 2024, 6:23:33 AM7/9/24
to swupdate
It looks like it's the problem origin, suricatta is just calling https://github.com/sbabic/swupdate/blob/master/core/swupdate_vars.c#L102 and using libubootenv which does'nt work if not running as root :-(
shouldn't environment variables setting work over IPC and let swupdate core (running as root) handle it ?
Stefano Babic
Jul 9, 2024, 3:37:14 PM7/9/24
to ayoub...@googlemail.com, swupdate
Hi Ayoub,
On 09.07.24 12:23, 'ayoub...@googlemail.com' via swupdate wrote:
> It looks like it's the problem origin, suricatta is just
> calling https://github.com/sbabic/swupdate/blob/master/core/swupdate_vars.c#L102 and using libubootenv which does'nt work if not running as root :-(
>
I agree - it works until the suricatta daemon can access the environment.
> shouldn't environment variables setting work over IPC and let swupdate
> core (running as root) handle it ?
I think something more is requested. The idea here is to split between
bootloader environment, that is necessary to the bootloader itself, and
variables for generic use cases, like action id. It is not required by
the bootloader, and it is only necessary to make it persistent for
SWUpdate, and that means using another "namespace" for the environemnt,
where the access is not required under root. And just in case no
namespace is set (now it is unused), it should fallback to bootloader's
env using IPC.
Best regards,
Stefano
>
>
>
> On Tuesday, July 9, 2024 at 12:16:31 PM UTC+2 ayoub...@googlemail.com wrote:
>
> Hi Stefano,
>
> I don't understand your statement "correctly configured" ? u-boot
> env are enabled in my case and "ustate" variable is also updated.
>
> I think the only thing I'd have differently done is that Suricatta
> is not running as root, could be the problem cause ?
>
> On Tuesday, July 9, 2024 at 12:06:37 PM UTC+2 Stefano Babic wrote:
>
> On 09.07.24 12:04, 'ayoub...@googlemail.com' via swupdate wrote:
> > Hi,
> >
> > thanks for the patch, but shouldn't swupdate create/add
> "action_id" to
> > u-boot environment if not available ?
>
> It is done when it is correctly configured, see
>
> https://github.com/sbabic/swupdate/blob/master/suricatta/server_hawkbit.c#L1113 <https://github.com/sbabic/swupdate/blob/master/suricatta/server_hawkbit.c#L1113>
> https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
On 09.07.24 12:23, 'ayoub...@googlemail.com' via swupdate wrote:
> It looks like it's the problem origin, suricatta is just
> calling https://github.com/sbabic/swupdate/blob/master/core/swupdate_vars.c#L102 and using libubootenv which does'nt work if not running as root :-(
>
> shouldn't environment variables setting work over IPC and let swupdate
> core (running as root) handle it ?
bootloader environment, that is necessary to the bootloader itself, and
variables for generic use cases, like action id. It is not required by
the bootloader, and it is only necessary to make it persistent for
SWUpdate, and that means using another "namespace" for the environemnt,
where the access is not required under root. And just in case no
namespace is set (now it is unused), it should fallback to bootloader's
env using IPC.
Best regards,
Stefano
>
>
>
> On Tuesday, July 9, 2024 at 12:16:31 PM UTC+2 ayoub...@googlemail.com wrote:
>
> Hi Stefano,
>
> I don't understand your statement "correctly configured" ? u-boot
> env are enabled in my case and "ustate" variable is also updated.
>
> I think the only thing I'd have differently done is that Suricatta
> is not running as root, could be the problem cause ?
>
> On Tuesday, July 9, 2024 at 12:06:37 PM UTC+2 Stefano Babic wrote:
>
> On 09.07.24 12:04, 'ayoub...@googlemail.com' via swupdate wrote:
> > Hi,
> >
> > thanks for the patch, but shouldn't swupdate create/add
> "action_id" to
> > u-boot environment if not available ?
>
> It is done when it is correctly configured, see
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/883b8e1d-09fc-4651-95c7-d17c5a0eff51n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/883b8e1d-09fc-4651-95c7-d17c5a0eff51n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
Stefano Babic
Jul 10, 2024, 3:31:03 AM7/10/24
to ayoub...@googlemail.com, swupdate
Hi Ayoub,
On 09.07.24 21:37, Stefano Babic wrote:
> Hi Ayoub,
>
> On 09.07.24 12:23, 'ayoub...@googlemail.com' via swupdate wrote:
>> It looks like it's the problem origin, suricatta is just
>> calling https://github.com/sbabic/swupdate/blob/master/core/swupdate_vars.c#L102 and using libubootenv which does'nt work if not running as root :-(
>>
>
> I agree - it works until the suricatta daemon can access the environment.
>
I was too quick yesterday without checking the code. The link you
reported surely calls libubootenv, but this is executed by the core.
Processes like suricatta are calling swupdate_vars_set and this sends an
IPC message to the core. So if it does not work, it should be debugged,
but the concept looks ok to me, with the exception that action-id could
be stored in a different namespace while it is now only in bootloader
env (no namespace is given.
Best regards,
Stefano
On 09.07.24 21:37, Stefano Babic wrote:
> Hi Ayoub,
>
> On 09.07.24 12:23, 'ayoub...@googlemail.com' via swupdate wrote:
>> It looks like it's the problem origin, suricatta is just
>> calling https://github.com/sbabic/swupdate/blob/master/core/swupdate_vars.c#L102 and using libubootenv which does'nt work if not running as root :-(
>>
>
> I agree - it works until the suricatta daemon can access the environment.
>
reported surely calls libubootenv, but this is executed by the core.
Processes like suricatta are calling swupdate_vars_set and this sends an
IPC message to the core. So if it does not work, it should be debugged,
but the concept looks ok to me, with the exception that action-id could
be stored in a different namespace while it is now only in bootloader
env (no namespace is given.
Best regards,
Stefano
ayoub...@googlemail.com
Jul 10, 2024, 11:19:24 AM7/10/24
to swupdate
Hi Stefano,
no problem.
I checked quickly again and it seems that action_id is not stored and no warning about is traced in the logs.
this should be further debugged, I can take some time next week and check it in details.
Best regards
Yaroslav Molochko
Nov 8, 2024, 10:39:19 AM11/8/24
to swupdate
Did you have a chance to debug it? I also don't have action_id stored anywhere, I've spent several days trying to find the reason without much luck. If you identified the problem in your case - I would love to hear how you identified it or maybe you already have a solution?
Ayoub Zaki
Nov 8, 2024, 11:00:46 AM11/8/24
to Yaroslav Molochko, swupdate
I don't think it's working...
I did need the action_id to proceed further
To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/swupdate/44c181f1-8bd3-40fe-83e8-8435bbb2d36en%40googlegroups.com.
vincent....@gmail.com
Dec 4, 2024, 8:59:14 AM12/4/24
to swupdate
I didn't see every response but for my problem, I submitted following patch some time ago (usecase using hawkbit and grub):
I can rebase it if there's a will to integrate it, for the moment it applies on 940964.
BR,
Vincent
Oleksandr Andrushchenko
Dec 23, 2024, 5:56:49 AM12/23/24
to swupdate
Hi,
So, I hope this would help someone. In order for action_id to work this is what I did.
1. I switched fw_env.config to YAML: this is needed for namespaces to work
2. I defined an SWUpdate dedicated namespace, so the whole config (fw_env.config) is:
uboot:
size: 0x4000
lockfile: /var/lock/fw_printenv.lock
devices:
- path: /etc/uboot.env
offset: 0x0000
swupdate:
size: 0x4000
lockfile: /var/lock/swupdate_env.lock
devices:
- path: /etc/swupdate.env
offset: 0x0000
3. I instructed SWUpdate to use that namespace:
globals :
{
[snip]
namespace-vars = "swupdate";
};
4. If one of the env files do not exist this is not going to work:
~# fw_printenv
Cannot initialize environment
So, you either need to (re-)create the default environment or just "touch"
those files.
5. After that I can see the following logs after update and reboot:
swupdate.sh[835]: [TRACE] : SWUPDATE running : [server_get_deployment_info] : Associated Action ID for Update Action is 47
swupdate.sh[835]: [TRACE] : SWUPDATE running : [get_action_id_from_env] : Retrieve action_id from previous run: 47
Regards,
Oleksandr
So, I hope this would help someone. In order for action_id to work this is what I did.
1. I switched fw_env.config to YAML: this is needed for namespaces to work
2. I defined an SWUpdate dedicated namespace, so the whole config (fw_env.config) is:
uboot:
size: 0x4000
lockfile: /var/lock/fw_printenv.lock
devices:
- path: /etc/uboot.env
offset: 0x0000
swupdate:
size: 0x4000
lockfile: /var/lock/swupdate_env.lock
devices:
- path: /etc/swupdate.env
offset: 0x0000
3. I instructed SWUpdate to use that namespace:
globals :
{
[snip]
namespace-vars = "swupdate";
};
4. If one of the env files do not exist this is not going to work:
~# fw_printenv
Cannot initialize environment
So, you either need to (re-)create the default environment or just "touch"
those files.
5. After that I can see the following logs after update and reboot:
swupdate.sh[835]: [TRACE] : SWUPDATE running : [server_get_deployment_info] : Associated Action ID for Update Action is 47
swupdate.sh[835]: [TRACE] : SWUPDATE running : [get_action_id_from_env] : Retrieve action_id from previous run: 47
Regards,
Oleksandr
пʼятниця, 8 листопада 2024 р. о 17:39:19 UTC+2 Yaroslav Molochko пише:
AJ Smyth
Jan 13, 2025, 2:20:14 PM1/13/25
to swupdate
This worked for me, thank you! How did you make sure your swupdate.env file was persisted across updates though, did you use a custom post-update script? To keep it simple I just have another (tiny) partition for my swupdate environment. I have no idea if this is idiomatic. My fw_env.config looks something like
uboot:
size: 0x4000
devices:
- path: /dev/mmcblk2
offset: 0x700000
swupdate:
size: 0x4000
devices:
- path: /dev/mmcblk2p4
offset: 0x0000
size: 0x4000
devices:
- path: /dev/mmcblk2
offset: 0x700000
swupdate:
size: 0x4000
devices:
- path: /dev/mmcblk2p4
offset: 0x0000
Cal
Jun 4, 2025, 5:33:54 PM6/4/25
to swupdate
For non-Uboot environments (grub, UEFI, etc.), the expectation is that this action_id persistent storage (across reboots into dual-copy a/b partitions) will not be possible, correct?
I created a UEFI bootloader env variable support patch, and am going to leverage it to handle the action_id in a similar way as was handled in the patch linked by vincent a few messages above this one.
If anyone knows of alternative ways this could be handled, please let me know.
Stefano Babic
Jun 5, 2025, 3:54:35 AM6/5/25
to Cal, swupdate
Hi Cal,
On 04.06.25 23:22, 'Cal' via swupdate wrote:
> For non-Uboot environments (grub, UEFI, etc.), the expectation is that
> this action_id persistent storage (across reboots into dual-copy a/b
> partitions) will not be possible, correct?
Wrong. The library is thought to manage pairs key/value and to store
them into the U-Boot format, but it can be used for other purposes, too.
So the library is now duty in SWUpdate, independently if the bootloader
is U-Boot or not. If you provide a suitable storage for the envirnonment
/ database, SWUpdate will store and retrieve automatically action_id.
The reason to make the library mandatory is really to add this for
devices not having U-Boot as bootloader.
Best regards,
Stefano Babic
> master/core/swupdate_vars.c#L102 <https://
> github.com/sbabic/swupdate/blob/master/core/
> swupdate_vars.c#L102> and using libubootenv which
> server_hawkbit.c#L1113> <https://github.com/sbabic/
> swupdate/blob/master/suricatta/
> server_hawkbit.c#L1113 <https://github.com/sbabic/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>> <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
> groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://
> groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com?
> swupdate/0d5f281b-b948-4124-a8dc-da5d13b45087n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/0d5f281b-b948-4124-a8dc-
> da5d13b45087n%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 04.06.25 23:22, 'Cal' via swupdate wrote:
> For non-Uboot environments (grub, UEFI, etc.), the expectation is that
> this action_id persistent storage (across reboots into dual-copy a/b
> partitions) will not be possible, correct?
them into the U-Boot format, but it can be used for other purposes, too.
So the library is now duty in SWUpdate, independently if the bootloader
is U-Boot or not. If you provide a suitable storage for the envirnonment
/ database, SWUpdate will store and retrieve automatically action_id.
The reason to make the library mandatory is really to add this for
devices not having U-Boot as bootloader.
Best regards,
Stefano Babic
> github.com/sbabic/swupdate/blob/master/core/
> swupdate_vars.c#L102> and using libubootenv which
> swupdate/blob/master/suricatta/
> server_hawkbit.c#L1113 <https://github.com/sbabic/
> >>
> >> --
> >> You received this message because you are
> subscribed to the Google
> >> Groups "swupdate" group.
> >> To unsubscribe from this group and stop
> receiving emails from it, send
> >> an email to swupdate+u...@googlegroups.com
> >> <mailto:swupdate+u...@googlegroups.com>.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com <https://
> groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com> <https://
> >> --
> >> You received this message because you are
> subscribed to the Google
> >> Groups "swupdate" group.
> >> To unsubscribe from this group and stop
> receiving emails from it, send
> >> an email to swupdate+u...@googlegroups.com
> >> <mailto:swupdate+u...@googlegroups.com>.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com <https://
> groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://
> groups.google.com/d/msgid/
> swupdate/883b8e1d-09fc-4651-95c7-
> d17c5a0eff51n%40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> swupdate/0d5f281b-b948-4124-a8dc-da5d13b45087n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/0d5f281b-b948-4124-a8dc-
> da5d13b45087n%40googlegroups.com?utm_medium=email&utm_source=footer>.
vincent....@gmail.com
Jun 5, 2025, 4:28:46 AM6/5/25
to swupdate
For my understanding, noone every had a working example of swupdate using environment variables and another bootloader than uboot?
Last year I spent a lot of time trying to understand how I could manage it, but always failed to, ended by creating that small patch, but I would be glad to use official way to handle this when it works ;)
Cal
Jun 7, 2025, 12:20:38 AM6/7/25
to swupdate
Thanks, Stefano. I got libubootenv working while running a non-uboot bootloader.
Unfortunatly, I still have issues with the suricatta integration that I'll investigate. It happens when a `-c` update confirmation is passed via the suricatta args. The `swupdate_vars_get` IPC call to the core fails, even though previous runs were able to access the variable through libubootenv:
```
Jun 07 03:33:10 eac6000 swupdate[15953]: [WARN ] : SWUPDATE running : [swupdate_vars_get] : Failed to get variable action_id
Jun 07 03:33:10 eac6000 swupdate[15953]: [WARN ] : SWUPDATE running : [get_action_id_from_env] : Action id not in env: action from server sent, possible mismatch
Jun 07 03:33:10 eac6000 swupdate[15953]: [TRACE] : SWUPDATE running : [handle_feedback] : No active update available, nothing to report to server.
Jun 07 03:33:10 eac6000 swupdate[15953]: [WARN ] : SWUPDATE running : [handle_feedback] : Persistent state=2 but no active update on server?
Jun 07 03:33:10 eac6000 swupdate[15953]: [WARN ] : SWUPDATE running : [get_action_id_from_env] : Action id not in env: action from server sent, possible mismatch
Jun 07 03:33:10 eac6000 swupdate[15953]: [TRACE] : SWUPDATE running : [handle_feedback] : No active update available, nothing to report to server.
Jun 07 03:33:10 eac6000 swupdate[15953]: [WARN ] : SWUPDATE running : [handle_feedback] : Persistent state=2 but no active update on server?
```
Example YAML:
Vincent, I spent some time on this today. Oleksandr's answer was correct. Everything I state below is basically a copy of what he said, though I didn't understand it upon first read of his message.
One way to implement the storage for non-uboot is to use the VFAT config structure mentioned here: (https://github.com/sbabic/libubootenv/blob/master/docs/fw_env_config.md#vfat-example) but using the YAML format (https://github.com/sbabic/libubootenv/blob/master/docs/fw_env_config.md#configuration-file-in-yaml) to implement namespaces. (Of course you don't need to use VFAT support if you have devices you could store it on instead.)
Example YAML:
```
swupdate:
size : 0x4000
lockfile : /var/lock/swupdate_env.lock
devices:
size : 0x4000
lockfile : /var/lock/swupdate_env.lock
devices:
- path : /boot/swupdate.env
offset : 0x0
offset : 0x0
```
Example swupdate.cfg:
```
globals:
{
...
namespace-vars = "swupdate";
fwenv-config-location = "/etc/fw_env.config";
};
{
...
namespace-vars = "swupdate";
fwenv-config-location = "/etc/fw_env.config";
};
```
If you're using the VFAT method, the `swupdate.env` file needs to exist before running swupdate or any libubootenv binaries. You can an test environment reading by using `fw_printenv -c <non-default config path>`. If it returns nothing, or the variables, it works. It will print an error if it doesn't work. (The error isn't very clear, when using the VFAT method, when you are missing file at the "devices" environment path. It gives a generic "configuration" error.)
If you're using the VFAT method, the `swupdate.env` file needs to exist before running swupdate or any libubootenv binaries. You can an test environment reading by using `fw_printenv -c <non-default config path>`. If it returns nothing, or the variables, it works. It will print an error if it doesn't work. (The error isn't very clear, when using the VFAT method, when you are missing file at the "devices" environment path. It gives a generic "configuration" error.)
Stefano Babic
Jun 7, 2025, 6:04:07 AM6/7/25
to Cal, swupdate
Hi Cal,
Try to use the default namespace "uboot" instead of swupdate, that is:
uboot:
size : 0x4000
lockfile : /var/lock/swupdate_env.lock
Consider also to have redundant environment to be power-cut safe.
By checking into code, the "action_id" var is retrieved without using
namespace, and this fallbacks to the default namespace "uboot". Just
give it a try.
Best regards,
Stefano Babic
> > >> calling https://github.com/sbabic/swupdate/blob/ <https://
> github.com/sbabic/swupdate/blob/>
> > master/core/swupdate_vars.c#L102 <https://
> > github.com/sbabic/swupdate/blob/master/core/ <http://
> > >> https://github.com/sbabic/swupdate/blob/master/ <https://
> github.com/sbabic/swupdate/blob/master/>
> > suricatta/server_hawkbit.c#L1113 <https://
> > github.com/sbabic/swupdate/blob/master/suricatta/ <http://
> github.com/sbabic/swupdate/blob/master/suricatta/>
> > server_hawkbit.c#L1113> <https://github.com/sbabic/ <https://
> github.com/sbabic/>
> > swupdate/blob/master/suricatta/
> > server_hawkbit.c#L1113 <https://github.com/sbabic/ <https://
> github.com/sbabic/>
> > >> https://groups.google.com/d/msgid/swupdate/ <https://
> groups.google.com/d/msgid/swupdate/>
> > a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <http://40googlegroups.com> <https://groups.google.com/d/msgid/
> swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>>
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>>>
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer> <https://groups.google.com/
> d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer>> <https://groups.google.com/
> d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer> <https://groups.google.com/
> d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>
> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>>
> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>?
> > swupdate/0d5f281b-b948-4124-a8dc-
> da5d13b45087n%40googlegroups.com <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/0d5f281b-
> b948-4124-a8dc- <https://groups.google.com/d/msgid/
> swupdate/0d5f281b-b948-4124-a8dc->
> > da5d13b45087n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> <https://groups.google.com/d/msgid/
> swupdate/7c3bad93-3c3f-42f3-89ad-3a19fc5e63a3n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
uboot:
size : 0x4000
lockfile : /var/lock/swupdate_env.lock
Consider also to have redundant environment to be power-cut safe.
By checking into code, the "action_id" var is retrieved without using
namespace, and this fallbacks to the default namespace "uboot". Just
give it a try.
Best regards,
Stefano Babic
> github.com/sbabic/swupdate/blob/>
> > master/core/swupdate_vars.c#L102 <https://
> > github.com/sbabic/swupdate/blob/master/core/ <http://
> github.com/sbabic/swupdate/blob/master/>
> > suricatta/server_hawkbit.c#L1113 <https://
> > github.com/sbabic/swupdate/blob/master/suricatta/ <http://
> github.com/sbabic/swupdate/blob/master/suricatta/>
> > server_hawkbit.c#L1113> <https://github.com/sbabic/ <https://
> github.com/sbabic/>
> > swupdate/blob/master/suricatta/
> > server_hawkbit.c#L1113 <https://github.com/sbabic/ <https://
> github.com/sbabic/>
> groups.google.com/d/msgid/swupdate/>
> > a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <http://40googlegroups.com> <https://groups.google.com/d/msgid/
> swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>>
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com>>>
> <https://groups.google.com/d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer> <https://groups.google.com/
> d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer>> <https://groups.google.com/
> d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer> <https://groups.google.com/
> d/msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer <https://groups.google.com/d/
> msgid/swupdate/
> a753210d-84b0-415c-9cde-71317fb7be72n%40googlegroups.com?
> utm_medium=email&utm_source=footer>>>>.
> > >>
> > >> --
> > >> You received this message because you are
> > subscribed to the Google
> > >> Groups "swupdate" group.
> > >> To unsubscribe from this group and stop
> > receiving emails from it, send
> > >> an email to swupdate+u...@googlegroups.com
> > >> <mailto:swupdate+u...@googlegroups.com>.
> > >>
> > >> --
> > >> You received this message because you are
> > subscribed to the Google
> > >> Groups "swupdate" group.
> > >> To unsubscribe from this group and stop
> > receiving emails from it, send
> > >> an email to swupdate+u...@googlegroups.com
> > >> <mailto:swupdate+u...@googlegroups.com>.
> > >> To view this discussion on the web visit
> > >> https://groups.google.com/d/msgid/ <https://
> groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>
> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>>
> <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <https://
> > groups.google.com/d/msgid/ <http://groups.google.com/d/msgid/>
> > swupdate/883b8e1d-09fc-4651-95c7-
> > d17c5a0eff51n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> > >
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > >
> >
> > --
> > You received this message because you are subscribed to the
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/
> > swupdate/0d5f281b-b948-4124-a8dc-
> da5d13b45087n%40googlegroups.com <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/0d5f281b-
> b948-4124-a8dc- <https://groups.google.com/d/msgid/
> swupdate/0d5f281b-b948-4124-a8dc->
> > da5d13b45087n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/7c3bad93-3c3f-42f3-89ad-3a19fc5e63a3n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/
> swupdate/7c3bad93-3c3f-42f3-89ad-3a19fc5e63a3n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
Oleksandr Andrushchenko
Jun 8, 2025, 10:42:25 AM6/8/25
to swupdate
It would be good if this is documented somewhere...
Otherwise one needs to dig into discussion threads and sources which is not ok for everyone probably
Otherwise one needs to dig into discussion threads and sources which is not ok for everyone probably
An example with explanations would probably make a huge plus to the project, IMO
Oh, yeah, I know that "patches are welcome"
субота, 7 червня 2025 р. о 13:04:07 UTC+3 Stefano Babic пише:
Reply all
Reply to author
Forward
0 new messages