Yocto Thud compilation: got "ERROR: No boot files defined, IMAGE_BOOT_FILES unset for entry #1" about meta-updater-qemux86-64

[pattivacek]

If you set IMAGE_BOOT_FILES_sota = "" in your local.conf (or add it to meta-updater/classes/sota_qemux86-64.bbclass), does that solve the problem?

By the way, it looks like you are bitbaking core-image-sato. We don't have much experience with that target, so it is possible that you may find some issues that we've never encountered. We typically build core-image-minimal.

[viktor-mitin]

Patrick, thank you for the information. I tried to set IMAGE_BOOT_FILES_sota = "" in meta-updater/classes/sota_qemux86-64.bbclass, however it did not help. So I built it using the next manual: https://docs.ota.here.com/quickstarts/qemuvirtualbox.html So it works well (repo in this link uses older Yocto 2.4 by default, it is ok for me for now).
Thanks

[pattivacek]

@viktor-mitin glad to hear you had some success. Our quick start guide does default to rocko, and that's still what we test the most, but we do also support thud. You should be able to do the same thing the quick start suggests, but add -m thud.xml to the repo init command, and everything should work in (almost) the same way.

[viktor-mitin]

@patrickvacek repo init with -m thud.xml worked well. Mean that compilation and all the OSTree update steps passed without error. The only thing that doesn't work is that running quemu with '--overlay' option returns next error some-why (it was ok in case of default.xml file with Yocto Rocko):

c@cd:~/w/myproject_qemu_thud/build$ ../meta-updater/scripts/run-qemu-ota --overlay mydevice.cow Launching core-image-minimal with mac address ca:fe:aa:c9:8b:d3 To connect via SSH: ssh -o StrictHostKeyChecking=no root@localhost -p 2222 To connect to the serial console: nc localhost 8990 qemu-system-x86_64: -cpu Haswell: Could not open backing file: Could not open '/home/c/w/myproject_qemu_thud/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20190220140607.rootfs.ota-ext4': No such file or directory
Running the same script without --overlay option works well with Thud build.
Please note that all the host OS is Ubuntu 18.04.2.

Thanks

[pattivacek]

The only thing that doesn't work is that running quemu with '--overlay' option returns next error some-why

That is strange. I just tried it and it worked fine:

$ ../meta-updater/scripts/run-qemu-ota --no-gui --machine qemux86-64 --overlay mydevice.cow
Launching core-image-minimal with mac address ca:fe:00:a1:35:90
To connect via SSH:
 ssh -o StrictHostKeyChecking=no root@localhost -p 2222
To connect to the serial console:
 nc localhost 8990
Image file mydevice.cow does not yet exist, creating.
Formatting 'mydevice.cow', fmt=qcow2 size=265100288 backing_file=/home/patrick/Code/updater_repo_thud/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20190218103106.rootfs.ota-ext4 cluster_size=65536 lazy_refcounts=off refcount_bits=16
QEMU 2.11.1 monitor - type 'help' for more information

It looks like it was looking for a ota-ext4 image built for qemu. Is that correct? Does the file it complains about exist? If you bitbake core-image-minimal, do you see images getting generated in tmp/deploy/images/qemux86-64/?

[viktor-mitin]

The ota-ext4 image built for qemu exists. However, the script is looking for another one (with another date) some-why. This issue appeared after adding 'vim' package as the first update commit for testing purposes (according to 'quickstart' manual):
c@cd:~/w/myproject_qemu_thud/build$ ll /home/c/w/myproject_qemu_thud/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-*rootfs.ota* -rw-r--r-- 2 c c 265083904 лют 20 16:26 /home/c/w/myproject_qemu_thud/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20190220142241.rootfs.ota-ext4
Thanks

[pattivacek]

What it looks like is that using the --overlay parameter depends on the original image file still existing, and for some reason, the subsequent bitbake caused it to get removed. I don't entirely understand what Yocto's logic is there. If you want to be careful next time, you could copy the image file to another location and provide that as a positional argument to the run-qemu-ota script. That's a workaround, but without understanding what Yocto is doing, that's the best I can do for the moment.

[viktor-mitin]

I've found that the file mydevice.cow has hardcoded Yocto image name inside it. So I removed the cow file and restarted the script with --overlay parameter. The script recreated new mydevice.cow file with proper image name inside it and it works well. Still not clear what is the reason why Yocto removed the 'old' image file. Thanks

[viktor-mitin]

I've added one more package update with 'htop' and it broke the cow file again. Manual editing of the cow binary didn't help as well - it results to infinite loop with one CPU core load 100% (during qemu start). So it looks we have an 'meta-updater + qemu + Yocto Thud' issue which is easy to reconstruct.
Please note: exactly the same steps with Yocto Rocko are ok, mean works well without error (so the issue is relevant for the Thud version of Yocto only).
Thanks

[pattivacek]

It would require a bit of investigation to understand what changed in Yocto that causes that problem. If you have any ideas, I'm open to suggestions. In the mean time, does the workaround I proposed with backing up the desired image file help?

By the way, I'm not surprised that the cow file depends on a specific image file. That makes sense to me. You can't reboot the same image without the image being available. I suspect the change in Yocto relates to keeping vs. removing image files in the work directories when bitbaking repeatedly.

[viktor-mitin]

It would require a bit of investigation to understand what changed in Yocto that causes that problem. If you have any ideas, I'm open to suggestions.

Well, Yocto throws the warning that compilation Yocto with Ubuntu 18.04 is not supported yet.
So I tried to build it (the same Yocto Thud version) with Ubuntu 16.04 and I faced another issue (see another new issue opened). This issue currently prevents to move forward with 'cow' issue testing.

In the mean time, does the workaround I proposed with backing up the desired image file help?

I haven't check it yet...

By the way, I'm not surprised that the cow file depends on a specific image file. That makes sense to me. You can't reboot the same image without the image being available. I suspect the change in Yocto relates to keeping vs. removing image files in the work directories when bitbaking repeatedly.

[viktor-mitin]

Please be aware that backing up the original ota-ext4 image resolves the 'cow' issue with Yocto Thud.