Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

swupdate_vars.c : swupdate_vars_get : 89 : Failed to get variable action_id

372 views
Skip to first unread message

vincent....@gmail.com

unread,
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

Stefano Babic

unread,
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>.

vincent....@gmail.com

unread,
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,
Vincent

Stefano Babic

unread,
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 ?
> >
> > 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>>.
>
> --
> 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>.

vincent....@gmail.com

unread,
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";

But swupdate crashes, so it seems I should dig a bit more ;)

ayoub...@googlemail.com

unread,
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

Stefano Babic

unread,
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 ?
> > >
> > > 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>>>.
> >
> > --
> > 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 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>.

ayoub...@googlemail.com

unread,
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

unread,
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

ayoub...@googlemail.com

unread,
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

unread,
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
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

unread,
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.

Stefano

ayoub...@googlemail.com

unread,
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

unread,
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

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>.

ayoub...@googlemail.com

unread,
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

unread,
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

unread,
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>>.
>
> --
> 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>.

Stefano Babic

unread,
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

ayoub...@googlemail.com

unread,
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

unread,
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

unread,
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

unread,
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

unread,
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

пʼятниця, 8 листопада 2024 р. о 17:39:19 UTC+2 Yaroslav Molochko пише:

AJ Smyth

unread,
Jan 13, 2025, 2:20:14 PMJan 13
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
Reply all
Reply to author
Forward
0 new messages