Local software updates using SWUpdate failed | Hash mismatch - embedded-linux

Question

I am using SWUpdate to install updates to my Avnger96 board using A+B(dual copy) scheme. I am integrating SWUpdate with Yocto. But while installing updates locally using command line parameters, installation fails with error:
Trying to update with CLI swupdate -H dh-stm32mp1-dhcor-avenger96:1.0 -e stable,copy2 -v -i /tmp/avenger96-swu-v1-dh-stm32mp1-dhcor-avenger96-20220222133501.swu -k /etc/swupdate/swupdate-public.pem
[INFO ] : SWUPDATE started : Software Update started !
[TRACE] : SWUPDATE running : [network_initializer] : Software update started
[TRACE] : SWUPDATE running : [extract_file_to_tmp] : Found file
[TRACE] : SWUPDATE running : [extract_file_to_tmp] : filename sw-description
[TRACE] : SWUPDATE running : [extract_file_to_tmp] : size 1716
[TRACE] : SWUPDATE running : [extract_file_to_tmp] : Found file
[TRACE] : SWUPDATE running : [extract_file_to_tmp] : filename sw-description.sig
[TRACE] : SWUPDATE running : [extract_file_to_tmp] : size 256
[TRACE] : SWUPDATE running : [swupdate_verify_file] : Verify signed image: Read 1716 bytes
[TRACE] : SWUPDATE running : [swupdate_verify_file] : Verified OK
[TRACE] : SWUPDATE running : [get_common_fields] : Version 0.1.0
[TRACE] : SWUPDATE running : [parse_hw_compatibility] : Accepted Hw Revision : 1.0
[TRACE] : SWUPDATE running : [_parse_images] : Found compressed Image: core-image-minimal-dh-stm32mp1-dhcor-avenger96.ext4.gz in device : /dev/mmcblk0p5 for handler raw
[TRACE] : SWUPDATE running : [_parse_bootloader] : Bootloader var: rootfspart = 5
[TRACE] : SWUPDATE running : [check_hw_compatibility] : Hardware dh-stm32mp1-dhcor-avenger96 Revision: 1.0
[TRACE] : SWUPDATE running : [check_hw_compatibility] : Hardware compatibility verified
[TRACE] : SWUPDATE running : [extract_files] : Found file
[TRACE] : SWUPDATE running : [extract_files] : filename core-image-minimal-dh-stm32mp1-dhcor-avenger96.ext4.gz
[TRACE] : SWUPDATE running : [extract_files] : size 232476044 required
[ERROR] : SWUPDATE failed [0] ERROR : HASH mismatch : 24e9e0e03c5f6efbeb20c6b5da53841c04b9580e8409fa11d5f6307886127576 <--> 4ac608927345a1cdb725f018e20ce54c2840b1012917dffafdc85fe95dc26b14
[ERROR] : SWUPDATE failed [1] Image invalid or corrupted. Not installing ...
[TRACE] : SWUPDATE running : [network_initializer] : Main thread sleep again !
[INFO ] : No SWUPDATE running : Waiting for requests...
[INFO ] : SWUPDATE running : [endupdate] : Swupdate *failed* !
The sw-description is as follows:
software =
{
version = "0.1.0";
dh-stm32mp1-dhcor-avenger96 = {
hardware-compatibility: ["1.0"];
stable : {
copy1 : {
images: ({
filename = "core-image-minimal-dh-stm32mp1-dhcor-avenger96.ext4.gz";
sha256 = "#core-image-minimal-dh-stm32mp1-dhcor-avenger96.ext4.gz";
type = "raw";
compressed = "zlib";
device = "/dev/mmcblk0p4";
});
bootenv: (
{
name = "rootfspart";
value = "4";
},
);
};
copy2 : {
images: ({
filename = "core-image-minimal-dh-stm32mp1-dhcor-avenger96.ext4.gz";
sha256 = "#core-image-minimal-dh-stm32mp1-dhcor-avenger96.ext4.gz";
type = "raw";
compressed = "zlib";
device = "/dev/mmcblk0p5";
});
bootenv: (
{
name = "rootfspart";
value = "5";
},
);
};
};
}
}
I have set "Enable Verification of Signed Images" in menuconfig.
And also i have a question regarding installed rootfs on my device. Currently device is booted with /dev/mmcblk0p4, but I could see in linux user space rootfsB is also mounted(/dev/mmcblk0p5). I am using .wks file from Yocto to build dual partition scheme.
.
.
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root_A --part-name "rootfs_A" --align 4096 --use-uuid --active
part /rootfsB --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root_B --part-name "rootfs_B" --align 4096 --use-uuid
bootloader --ptable gpt
I am not sure why this is happening and is this expected behavior?
Can anyone please let me know what is the issue regarding SWUpdate and how to resolve it?
Your help will be much appreciated.
Thanks in advance.
P.S: Please let me know if any info is missing here.

Answer 1

I seems that the way your hashes are generated in the sw-description file differs from the way they are generated on your target device.
Could be: this bug, maybe you can update your swupdate version?
It seems like you are autogenerating the hashes using the meta-swupdate layer, have you tried generating them manually and tested if that works?