SWUpdate v2024.05.2 LUAstackDump

[ayoub...@googlemail.com]

hello, 

I'm getting a new error since I updated swupdate to v2024.05.2:

Jul 02 17:03:35 ccuv2 swupdate[442]: RUN [LUAstackDump] : (1) [string] [string "..."]:4: attempt to call a nil value (field 'get_bootenv')
Jul 02 17:03:35 ccuv2 swupdate[442]: FAILURE ERROR lua_interface.c : lua_parser_fn : 1623 : ERROR Calling Lua set_active_system
Jul 02 17:03:35 ccuv2 swupdate[442]: RUN [parse_json] : Parsing config file /tmp/sw-description
Jul 02 17:03:35 ccuv2 swupdate[442]: FAILURE ERROR parser.c : parse : 167 : JSON File corrupted
Jul 02 17:03:35 ccuv2 swupdate[442]: FAILURE ERROR parser.c : parse : 171 : no parser available to parse sw-description!
Jul 02 17:03:35 ccuv2 swupdate[442]: FAILURE ERROR stream_interface.c : extract_files : 182 : Compatible SW not found
Jul 02 17:03:35 ccuv2 swupdate[442]: FATAL_FAILURE Image invalid or corrupted. Not installing ...
Jul 02 17:03:35 ccuv2 swupdate[442]: FAILURE ERROR mongoose_interface.c : upload_handler : 637 : Writing to IPC fails due to Broken pipe
Jul 02 17:03:35 ccuv2 swupdate[442]: RUN [network_initializer] : Main thread sleep again !

following is my sw-description :

software =
{
        version = "@@OS_VERSION@@";

embedded-script = "

function set_active_system(image)
active_system = swupdate.get_bootenv('active_system')
print(\"active_system:\" .. tostring(active_system))
if active_system == \"A\" then
image.version= \"B\"
else
image.version= \"A\"
end
swupdate.trace(\"image.version: \" .. image.version)
return true, image
end
"

images:  (
{
name = "rootfs";
version = "@@OS_VERSION@@";
filename = "@@IMAGE@@.ext4.dmverity.gz";
device = "/dev/update";
compressed=true;
type = "raw";
installed-directly=true;
encrypted = true;
sha256 = "$swupdate_get_sha256(@@IMAGE@@.ext4.dmverity.gz)";
},
{
name = "bootloader";
version = "@@OS_VERSION@@";
filename = "BOOT.BIN";
mtdname = "boot";
type = "flash";
encrypted = true;
sha256 = "$swupdate_get_sha256(BOOT.BIN)";

}
);
files: (
{
name = "kernel";
version = "@@OS_VERSION@@";
filename = "image.bin";
path = "/media/mnt/kernel_update/image.bin";
encrypted = true;
sha256 = "$swupdate_get_sha256(image.bin)";
},
{
name = "fpga";
version = "@@OS_VERSION@@";
filename = "fpga.bin";
path = "/media/mnt/kernel_update/fpga.bin";
encrypted = true;
sha256 = "$swupdate_get_sha256(fpga.bin)";
}
);
bootenv: (
{
name = "active_system";
value = "X"; //dummy;
hook = "set_active_system";
},
{
name = "upgrade_available";
value = "1";
}
);
}

this worked with previous version.

 did uboot interface in LUA changed recently ? Any idea, what should be fixed ?

[Stefano Babic]

Hi Ayoub,

No, it wasn't changed. But are you sure that you can access the
environment from Linux ? Error is simply telling us that the variable
"active_system" is not set. If you run fw_printenv active_system from
shell, do you get what you expect ?

At first glance it does not seem an issue inside SWUpdate, but in the
environment's configuration (fw_env.config or the variable is simply
unset). And maybe you should switch to use swupdat.getroot instead of
relying on a U-Boot variable, it is much safer.

Best regards,
Stefano

[ayoub...@googlemail.com]

Hello Stefano,

fw_setenv/printenv are working fine.

the only thing that was changed is to update meta-swupdate from:

commit: f1266f66b4d245c56e334f1be1694a307c0f09d0

to

commit: a924d4bfd9dd54638ac8348d3f2845339f789770

Best regards,

Ayoub

[ayoub...@googlemail.com]

by the way the getroot won't work in case since I use device mappers.

[ayoub...@googlemail.com]

I saw there were a bunch of LUA Changes recently from the 2024.05 to 2024.05.2 probably one of them introduced a regression.

On Tuesday, July 2, 2024 at 5:27:43 PM UTC+2 Stefano Babic wrote:

[Stefano Babic]

Hi Ayoub,

On 03.07.24 08:57, 'ayoub...@googlemail.com' via swupdate wrote:
> I saw there were a bunch of LUA Changes recently from the 2024.05 to
> 2024.05.2 probably one of them introduced a regression.
>

I see - it seems the bootenv functions are not registered anymore.

I wrote a simple patch to fix this, I think we can simply add the
bootenv to the list of functions provided by the library. Anyway, added
Christian in CC, in last time we have both made several changes to the
Lua interface, and it is better to take a look together.

Can you at least test this on your side ?

From c6126e1d7e84946bb9f19eafa7a8236dcff36160 Mon Sep 17 00:00:00 2001
From: Stefano Babic <stefan...@swupdate.org>
Date: Wed, 3 Jul 2024 10:37:35 +0200
Subject: [PATCH] BUG: bootenv functions not available

commit f8153 introduced a regression bug. The bootenv functions are not
registered anymore and they cannot be called from scripts. They were
handled separately, but after switching to a Lua Session State, there is
no need for this and the function can be added together with the rest of
the interface.

Signed-off-by: Stefano Babic <stefan...@swupdate.org>
---
corelib/lua_interface.c | 6 ------
1 file changed, 6 deletions(-)

diff --git a/corelib/lua_interface.c b/corelib/lua_interface.c
index 74590ab6..86c2112d 100644
--- a/corelib/lua_interface.c
+++ b/corelib/lua_interface.c
@@ -1195,10 +1195,6 @@ static const luaL_Reg l_swupdate[] = {
{ "getversion", lua_get_swupdate_version },
{ "progress", lua_notify_progress },
{ "emmcbootpart", l_get_emmc_bootpart },
- { NULL, NULL }
-};
-
-static const luaL_Reg l_swupdate_bootenv[] = {
{ "get_bootenv", l_get_bootenv },
{ "set_bootenv", l_set_bootenv },
{ "get_selection", l_get_selection },
@@ -1319,7 +1315,6 @@ static int l_handler_wrapper(struct img_type *img,
void *data,
}
struct dict **udbootenv = lua_newuserdata(L, sizeof(struct dict*));
*udbootenv = img->bootloader;
- luaL_setfuncs(L, l_swupdate_bootenv, 1);
lua_pop(L, 1);
}

@@ -1549,7 +1544,6 @@ lua_State *lua_session_init(struct dict *bootenv)
luaL_requiref(L, "swupdate", luaopen_swupdate, 1 );
struct dict **udbootenv = lua_newuserdata(L, sizeof(struct dict*));
*udbootenv = bootenv;
- luaL_setfuncs(L, l_swupdate_bootenv, 1);
lua_pop(L, 1); /* remove unused copy left on stack */

lua_handlers_init(L);
--
2.34.1

Best regards,
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/fb8ab8cb-bff3-4d6b-a4bb-f26896699f93n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/fb8ab8cb-bff3-4d6b-a4bb-f26896699f93n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Stefano Babic]

On 03.07.24 08:37, 'ayoub...@googlemail.com' via swupdate wrote:
> by the way the getroot won't work in case since I use device mappers.
>

I use device mappers and it works. That means we have a different view
what getroot should return. What I need is not the dm volume, but the
underlying block device. And this what the function returns. What is
then your use case ?

Best regards,
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/63a3258f-96e9-4f86-a4ba-7249bdd3965en%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/63a3258f-96e9-4f86-a4ba-7249bdd3965en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[ayoub...@googlemail.com]

Hi Stefano,

I confirm that the patch solve this issue.

2024.05.02 is broken I believe a new minor version should be released.

Thanks for the support :-)

best regards,

Ayoub

[ayoub...@googlemail.com]

you are right I tested it it should also be working, thanks for the hint :-)

[Stefano Babic]

Hi Ayoub,

On 03.07.24 12:52, 'ayoub...@googlemail.com' via swupdate wrote:
> Hi Stefano,
>
> I confirm that the patch solve this issue.
>

Uff...

> 2024.05.02 is broken I believe a new minor version should be released.
>

I am not so happy...

I send the patch to the ML first.

Best regards,
Stefano

> https://groups.google.com/d/msgid/swupdate/fb8ab8cb-bff3-4d6b-a4bb-f26896699f93n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/fb8ab8cb-bff3-4d6b-a4bb-f26896699f93n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/fb8ab8cb-bff3-4d6b-a4bb-f26896699f93n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/fb8ab8cb-bff3-4d6b-a4bb-f26896699f93n%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/c0683123-424d-4ad6-8eb9-97420450ce7dn%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/c0683123-424d-4ad6-8eb9-97420450ce7dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Storm, Christian]

Hi,

>> I saw there were a bunch of LUA Changes recently from the 2024.05 to
>> 2024.05.2 probably one of them introduced a regression.
>>
>
> I see - it seems the bootenv functions are not registered anymore.

Well,
parser/parser.c :: parser(parsertype p, void *cfg, struct swupdate_cfg *swcfg)
[https://github.com/sbabic/swupdate/blob/master/parser/parser.c#L1031]
calls
corelib/lua_interface.c :: lua_session_init(struct dict *bootenv)
[https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1550-L1552]
and this calls
lua_handlers_init(L);

In there, we're upgrading an embedded script context to a handler context which needs to get special treatment in luaopen_swupdate(lua_State *L) {}.
To make this upgrade work, we have to reload the swupdate module [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1550-L1552].
Hence, you don't have the bootloader functions anymore.

So, inserting the bootloader Lua functions into the swupdate module after lua_session_init()'s call to lua_handlers_init() should fix that problem.

Note: A handler's bootloader context is set when calling, here: https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1320-L1322

> I wrote a simple patch to fix this, I think we can simply add the
> bootenv to the list of functions provided by the library. Anyway, added
> Christian in CC, in last time we have both made several changes to the
> Lua interface, and it is better to take a look together.

We can also do this but need special treatment then for l_handler_wrapper() [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1314-L1324] since it conditionally inserts the bootloader functions into the swupdate module...

Either way, I'm fine with propagating the bootloader functions to be always present and error out if they don't have a proper context.


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T CED OES-DE
Friedrich-Ludwig-Bauer-Str. 3, 85748 Garching, Germany

[Stefano Babic]

Hi Christian,

On 03.07.24 13:16, 'Storm, Christian' via swupdate wrote:
> Hi,
>
>>> I saw there were a bunch of LUA Changes recently from the 2024.05 to
>>> 2024.05.2 probably one of them introduced a regression.
>>>
>>
>> I see - it seems the bootenv functions are not registered anymore.
>
> Well,
> parser/parser.c :: parser(parsertype p, void *cfg, struct swupdate_cfg *swcfg)
> [https://github.com/sbabic/swupdate/blob/master/parser/parser.c#L1031]
> calls
> corelib/lua_interface.c :: lua_session_init(struct dict *bootenv)
> [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1550-L1552]
> and this calls
> lua_handlers_init(L);
>
> In there, we're upgrading an embedded script context to a handler context which needs to get special treatment in luaopen_swupdate(lua_State *L) {}.
> To make this upgrade work, we have to reload the swupdate module [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1550-L1552].
> Hence, you don't have the bootloader functions anymore.
>
> So, inserting the bootloader Lua functions into the swupdate module after lua_session_init()'s call to lua_handlers_init() should fix that problem.
>
> Note: A handler's bootloader context is set when calling, here: https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1320-L1322
>

Thanks for your analyses.

>
>> I wrote a simple patch to fix this, I think we can simply add the
>> bootenv to the list of functions provided by the library. Anyway, added
>> Christian in CC, in last time we have both made several changes to the
>> Lua interface, and it is better to take a look together.
>
> We can also do this but need special treatment then for l_handler_wrapper() [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1314-L1324] since it conditionally inserts the bootloader functions into the swupdate module...
>
> Either way, I'm fine with propagating the bootloader functions to be always present and error out if they don't have a proper context.
>

Then do we need the special handling for the bootenv anymore in
l_handler_wrapper ? After propagating the functions, they should always
be present. I am not sure, but it seems to me safe to drop the following
code :

https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1314-L1324

Best regards,
Stefano

[Storm, Christian]

Hi Stefano,

>>>> I saw there were a bunch of LUA Changes recently from the 2024.05 to
>>>> 2024.05.2 probably one of them introduced a regression.
>>>>
>>>
>>> I see - it seems the bootenv functions are not registered anymore.
>>
>> Well,
>> parser/parser.c :: parser(parsertype p, void *cfg, struct swupdate_cfg *swcfg)
>> [https://github.com/sbabic/swupdate/blob/master/parser/parser.c#L1031]
>> calls
>> corelib/lua_interface.c :: lua_session_init(struct dict *bootenv)
>> [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1550-L1552]
>> and this calls
>> lua_handlers_init(L);
>>
>> In there, we're upgrading an embedded script context to a handler context which needs to get special treatment in luaopen_swupdate(lua_State *L) {}.
>> To make this upgrade work, we have to reload the swupdate module [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1550-L1552].
>> Hence, you don't have the bootloader functions anymore.
>>
>> So, inserting the bootloader Lua functions into the swupdate module after lua_session_init()'s call to lua_handlers_init() should fix that problem.
>>
>> Note: A handler's bootloader context is set when calling, here: https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1320-L1322
>>
>
> Thanks for your analyses.

You're welcome.

>>> I wrote a simple patch to fix this, I think we can simply add the
>>> bootenv to the list of functions provided by the library. Anyway, added
>>> Christian in CC, in last time we have both made several changes to the
>>> Lua interface, and it is better to take a look together.
>>
>> We can also do this but need special treatment then for l_handler_wrapper() [https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1314-L1324] since it conditionally inserts the bootloader functions into the swupdate module...
>>
>> Either way, I'm fine with propagating the bootloader functions to be always present and error out if they don't have a proper context.
>>
>
> Then do we need the special handling for the bootenv anymore in
> l_handler_wrapper ? After propagating the functions, they should always
> be present. I am not sure, but it seems to me safe to drop the following
> code :
>
> https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1314-L1324

Well, this code injects img->bootloader as upvalue to the bootloader functions.
Then, that must match the bootloader injected as upvalue in https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L1551.
If this is the case, I think it's safe to drop it.


Kind regards
Christian