GX update shellscript specification in sw-description fails

Question

question

davep asked Dec 10, '20

GX update shellscript specification in sw-description fails

Hello Everyone,

I'm new to the Victron GX device and am starting a journey to create some custom SW for it. I've been experimenting with delivering some dummy content to the device in the form of an update file and have hit a snag. The sw-description specification for my script seems to be bad, but according to any examples I can find, it looks correct:

sw-description:

software =
{
    venus-version = "20200906142058 v2.60";
    version = "0.1.0";
        files: (
                {
                        filename = "dummy.txt";
                        path = "/data/dummy.txt";
                }
        );
        scripts: (
                {
                        filename = "dummy.sh";
                        type = "shellscript";
                }
        );
}

I get the following error upon install:

2020-12-10 18:48:30.761547500 Version 0.1.0
2020-12-10 18:48:30.762287500 [NOTIFY] : SWUPDATE running :  [parse_scripts] : Found Script: dummy.sh
2020-12-10 18:48:30.763127500 
2020-12-10 18:48:30.763808500 [NOTIFY] : SWUPDATE running :  [parse_files] : Found File  : dummy.txt --> /data/dummy.txt (ROOTFS) 
2020-12-10 18:48:30.767148500 
2020-12-10 18:48:30.767420500 ERROR core/parser.c : parse : 95 : feature 'shellscript' required for script 'dummy.sh' in sw-description is absent!
2020-12-10 18:48:30.769409500 [NOTIFY] : SWUPDATE failed [0] ERROR core/parser.c : parse : 95 : feature 'shellscript' required for script 'dummy.sh' in sw-description is absent!
2020-12-10 18:48:30.775105500 ERROR core/swupdate.c : install_from_file : 311 : failed to parse sw-description!
2020-12-10 18:48:30.777870500 
2020-12-10 18:48:30.778062500 [NOTIFY] : SWUPDATE failed [0] ERROR core/swupdate.c : install_from_file : 311 : failed to parse sw-description!

I think I'm doing what it says is required. Any ideas?

Thanks.

firmware update

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Modifications Space

Node Red Space

Answer 1 · 2020-12-10T21:30:33Z

jeroen answered · Dec 10, 2020 at 09:30 PM

ok, you dare... Please don't do such things with a Color Control, you can completely brick it. (Well it can be restored, but involves moving SMD resistors and knowledge what to do). And please make sure you have a debug console..

That said, see https://github.com/victronenergy/meta-victronenergy/blob/master/meta-venus/recipes-support/swupdate/files/sunxi/defconfig#L60, that option is not enabled in normal builds. But you can enable it of course...

Regards,

Jeroen

6

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

davep commented · Dec 11, 2020 at 02:23 AM

Jeroen,

Thanks for the pointer. That error makes much more sense now.

So, I can simply ftp stuff over as I develop, but I was trying to think ahead to something more production suitable. If this is not a safe approach, is there a better or "best practice" way to accomplish delivery of add-on SW?

Thanks.

Dave

0 ·

jeroen ♦ davep commented · Dec 11, 2020 at 02:55 PM

Well swupdate on a Color Control can also program the bootloader / MLO. That is normally not done, but if you manage to corrupt the bootloader it cannot easily be recovered. The other devices can boot from SD-card etc, so they can always be recovered.

But by itself modifying the swu can be done. I wrote it down at https://github.com/victronenergy/venus/wiki/modifying-a-cerbo-swu-file. Feel free to add a text explaining what it is about.

0 ·

davep jeroen ♦ commented · Dec 11, 2020 at 06:45 PM

Jeroen,

I'm inferring from the method you show there that the recommended process, in general, is to start with a complete base update, unwrap it, add/modify as necessary, then re-wrap it.

Thanks.

Dave

0 ·

jeroen ♦ davep commented · Dec 11, 2020 at 08:19 PM

No, it is not the recommended process per se, it is simply one which works with the existing software. I think you are the first one to consider altering a swu file.

For venus OS we build everything from source with OpenEmbedded, see https://github.com/victronenergy/venus, and the output are the swu files and images. But you cannot build a full image with that since not everything is opensource.

If you don't need the closed source part, using OE would be the recommended process. Extracting, altering and packing again is simply a method which works, nothing more, nothing less.

0 ·

davep jeroen ♦ commented · Dec 11, 2020 at 08:21 PM

Thanks for the clarification.

0 ·

davep davep commented · Dec 14, 2020 at 05:44 PM

So, after fumbling around in the dark, I finally found the light switch... turns out what I wanted to accomplish can be done directly and safely with venus-data.tgz on a USB.

https://www.victronenergy.com/live/ccgx:root_access

0 ·

question