Iot2050 Firmware update via swupdate fails #280
Comments
|
@gylstorffq Where does swupdate extract the swu here, on /tmp or on the medium where it is picked up from? |
|
The swu binary is extracted to |
|
@gylstorffq: is there a way to extract to different folder as there is not sufficient space is /tmp and currently it has only 312MB free. I just followed the steps mentioned in README for swupdate |
|
That increase may relate to the addition of Google Coral support. You can disable that if you don't need it. Or increase the root partition sizes. Otherwise, you can set |
|
@jan-kiszka: i tried setting TMPDIR and getting below error. The /mnt/tmp is folder created in usb which has free space of 27GB.
|
|
What's the filesystem of /dev/sda1? Some FAT? |
|
I have build 78a1eaf. The image has around 1.5G free disk space on root. The commit doesn't contain meta-coral. @amitsagargowda If you have installed additional software i would propose to adjust the disk sizes at meta-iot2050/wic/iot2050-swu.wks.in Line 14 in 78a1eaf meta-iot2050/wic/iot2050-swu.wks.in Line 17 in 78a1eaf |
|
@jan-kiszka : Yes the filesytem is of type FAT |
|
Yes, FAT won't work as tmp because swupdate will try to use it to create files that require a real Unix filesystem (e.g. the one used for /data). BTW, the example image with Coral support still has plenty of free space: So, if you already customize your rootfs, you can also adjust its size like Quirin suggested. |
|
@jan-kiszka : Thanks for the update i did try formatting my usb to ext4 and not swupdate works logs can be seen in figure below. But after reboot it is not moving form one rootfs to other rootfs I am getting following error what is going wrong here. Finally we see that it stills in same rootfs and not moved to flashed rootfs. Any support here will help us a lot. We know that at the end we need to run script " complete_update.sh success" after we observe that rootfs has shifted correctly but since rootfs is not shifted we did not run script complete_update.sh.
root@iot2050-debian:/media/usb0# TMPDIR=/media/usb0/tmp/ swupdate -v -i ./iot2050-image-swu-example-iot2050-debian-iot2050.swu Licensed under GPLv2. See source distribution for detailed copyright notices. [INFO ] : SWUPDATE running : [lua_handlers_init] : Lua handler(s) found. |
|
The watchdog error indicates that you are not using latest master for your tests. Correct? We fixed some issues there, and things worked after that, at least for me. |
|
@jan-kiszka : Which commit id should we refer. Currently we are using commit id 78a1eaf924579aca87e26d6f511ecc0b660f0515 |
|
master, bf54a81. |
|
@jan-kiszka : Currently we are using bootloader version mentioned below is this fine.
|
|
It should be fine, yes. There are many variants and versions by now, so we may always miss some corner case, specifically with rather fresh features. Please again with a vanilla image built from today's master. If that one shows the same error as before, I need to reproduce (don't have the exact same setup at hands right now). |
|
@jan-kiszka: I am trying to build image from commit id mentioned but i get following error. The build option used was " ./kas-container build kas-iot2050-example.yml" . Are we doing anything wrong here.
|
|
Please retry after running |
|
@jan-kiszka : I tried "./kas-container --isar clean" as suggested above and tried build options "./kas-container build kas-iot2050-example.yml" . But still i do get same error. |
|
Then please share the log file, rather than screenshots. |
|
@jan-kiszka : what log file would you expect . can you please let me know so i can upload it. |
|
Please find the logs files attached i hope this is what you are expecting. |
|
Double-check that you are not having any local modifications on top. E.g., I don't see why openssl-dev should be installed on the original version of bf54a81 (it's not installed when I build it here). You might also be bitten by the new sstate cache and a Debian update of openssl in the meantime. That can be cleaned via Note that you will want |
|
@jan-kiszka : I tried the cleansstate command but it seem to fail. Are we entering correct command.
|
|
Nope, but the kas-container version in master is not recent enough. Just to |
|
We might indeed have a problem in the openssl recipe, just received another report. Hang on! |
|
Our CI is broken now also due to the openssl issue. |
|
@AsuraZeng already trigger a new CI to fix it, although that will not be the final solution. |
|
This will resolve the issue (for clean rebuilds): |
|
Specifically, a clean of the download cache for openssl seems to be needed ( |
|
@jan-kiszka : Thanks a lot it works now 👍 ... Now i would verify my swupdate ... Just a question ... i see the last patch you pointed to for my issue was related to u-boot. Should i update uboot on my pg1 board? |
|
@jan-kiszka : Can you please confirm if i need to update the base image or u-boot for this swupdate feature to work? |
|
You need firmware 1.2.1, and I would strongly recommend to build from master. Note that the SWUpdate feature should be fine in principle already, but some details will still need work. And the ongoing effort to enable secure boot for it may even bring more fundamental architectural changes (we are exploring if switching to UEFI wouldn't be better). |
|
@jan-kiszka : I build the firmware from master and updated it still i find the issue that rootfs is shifted still boots with old kernel i have attached detailed logs can you please have a look and mention what is going wrong here. ebian-iot2050.swuan:/media/usb0# TMPDIR=/media/usb0/tmp/ swupdate -v -i ./iot2050-image-swu-example-iot2050-debian-iot2050.swu Licensed under GPLv2. See source distribution for detailed copyright notices. [INFO ] : SWUPDATE running : [lua_handlers_init] : Lua handler(s) found. root@iot2050-debian:/media/usb0# reboot
|
|
Looks as if patching of the U-Boot env didn't work out on the first boot of the SWUpdate image. That patching will install the boot path switch. Could you share |
|
Please find o/p of both command below. fw_printenv o/proot@iot2050-debian:# fw_printenv journalctl -u patch-u-boot-envroot@iot2050-debian:/tmp# journalctl -u patch-u-boot-env |
|
Hmm, not sure yet what went wrong. The log says everything was fine, but the environment does contain what https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/patch-u-boot-env/files/patch-u-boot-env.config would bring in. Do you also get that variable state also when running |
|
|
|
@jan-kiszka and @gylstorffq I tried all steps mentioned above. Actually I confirmed that uboot has variable ustate=0. Later i trigerred swupdate at end of successfull swupdate tranfer the ustate was set to 1 . I was expecting that rootfs to trigger rootfs change from rootfs1 to rootfs2 but i still see that it points to rootfs1 only. But now the ustate value is set to 3. I have attached complete log for your reference. What could go wrong here? We are really stuck up here as this is one of the main part of our user story. Could you please assist us here. iot2050-image-swu-example-iot2050-debian-iot2050.swu tmp TMPDIR=/mnt/usb0/tmp/ swupdate -v -i ./iot2050-image-swu-example-iot2050-debian-iot2050.swudebian:/mnt/usb0# TMPDIR=/mnt/usb0/tmp/ swupdate -v -i ./iot2050-image-swu-example-iot2050-debian-iot2050.swu Licensed under GPLv2. See source distribution for detailed copyright notices. [INFO ] : SWUPDATE running : [lua_handlers_init] : Lua handler(s) found.
|
|
Are you using the eMMC or the SD card as mass storage for the device? It looks to me like you have both plugged and U-Boot configured to prefer the SD card. The result is a mess when both are bootable. |
|
@jan-kiszka : We are using 16GB sd card as mass storage device. Yes currently both are plugged in and we prefer SD card out of it. Is there a way to make emmc not bootable? |
|
@jan-kiszka : I removed sd card and tried on emmc the swupdate now works fine thanks a lot. But we need SD card approach also. Is this creating the issue? If i set boot_targets=mmc0 mmc1 usb0 usb1 usb2 Will it help What about setting boot_targets=mmc0 what is your thought on this? |
|
Yes, mmc0 is SD, mmc1 is eMMC. If you move mmc0 to the front, you will only boot from eMMC if SD fails. If you drop everything but SD from boot_targets, only that will be tried for booting. |
We are trying swupdate on our iot2050 using the example mentioned in iot meta-2050 readme.md "$ swupdate -i iot2050-image-swu-example-iot2050-debian-iot2050.swu" .
But this fails with an error "Error: Not Enough free Space to extract img1.gz " .
We are trying on PG1 FS03 using 32GB SD card. Base os is updated to commit id "78a1eaf924579aca87e26d6f511ecc0b660f0515".
We have updated event Bootloader to latest one compitable to PG2 OS.
The text was updated successfully, but these errors were encountered: