7213 2015-01-21 09:44:12 +0000 Toaster image files are not recorded for generic-x86 (and variants) builds 2015-02-11 13:30:58 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster 1.8 x86 Multiple VERIFIED FIXED High normal 1.8 M3 1 ionutx.chisanovici alexandru.damian alexandru.damian belen.barros.pena bluelightning bogdanx.a.voiculescu cristiana.voicu ionutx.chisanovici --- New (Never tested) No (bug/feature does not impact docs) oldest_to_newest 48122 0 ionutx.chisanovici 2015-01-21 09:44:12 +0000 Hi, For 1.8 M2 RC1, commit: d9d5b8b499af3ae01a1e33d0d3969c54c2d4ab1b, for a second build in a project, table orm_target_image_file is not updated with the second build informations. Steps to reproduce: 1. Create a toaster project; 2. Do a core-image-minimal image for qemux86 and let the build to finish; 3. Change the MACHINE variable to 'genericx86-64' in project configuration; 4. Do another core-image-minimal image for genericx86-64 and let the build to finish; 5. Check orm_target_image_file table to see if it was updated with the second build informations. sqlite> select * from orm_build where id=2; build_name = 201501201817 outcome = 0 completed_on = 2015-01-20 16:59:19.417168 warnings_no = 10 distro_version = 1.7 started_on = 2015-01-20 16:17:43.574611 machine = genericx86-64 project_id = 1 timespent = 2495 bitbake_version = 1.25.0 cooker_log_path = /home/ionut/work/poky_1.8/poky/build/tmp/log/cooker/genericx86-64/20150120161710.log errors_no = 0 id = 2 distro = poky sqlite> select * from orm_target; build_id = 1 target = core-image-minimal license_manifest_path = /home/ionut/work/poky_1.8/poky/build/tmp/deploy/licenses/core-image-minimal-qemux86-20150120152613/license.manifest image_size = 0 is_image = 1 id = 1 build_id = 2 target = core-image-minimal license_manifest_path = /home/ionut/work/poky_1.8/poky/build/tmp/deploy/licenses/core-image-minimal-genericx86-64-20150120161710/license.manifest image_size = 0 is_image = 1 id = 2 sqlite> select * from orm_target_image_file; file_name = /home/ionut/work/poky_1.8/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20150120152613.rootfs.ext3 target_id = 1 id = 1 file_size = 9211904 file_name = /home/ionut/work/poky_1.8/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20150120152613.rootfs.tar.bz2 target_id = 1 id = 2 file_size = 2358475 Cheers, Ionut C 48199 1 alexandru.damian 2015-01-22 18:08:58 +0000 This is a Toaster design issue. In short, toaster uses IMAGE_FSTYPES to detect what type of images the build process outputted. In long, The problems comes from the fact that for genericx86_64 target scrambles the IMAGE_FSTYPES to "live", where is should be expected to be something like "tar.bz2 ext3". This happens because of the poky/meta/conf/machine/include/x86-base.inc line 13 "append" op is done before the "set?" in poky/meta/conf/bitbake.conf file. -- After a discussion with Paul, it has become apparent that it is wrong to use IMAGE_FSTYPES variable in determining the image types written at output. Indeed, there is no definition in the Bitbake variable set that will point to a list of extensions, or exhaustive image type list for that matter, because the image creation may take any form in the bbclass file used; e.g. for "live" image types, ".ext3" files are outputted, even if this is not explicitly set up in the IMAGE_FSTYPES file. Consequently, we have no reliable method to determine, by looking at the images/ directory, what is an image, and what is not an image. The only solution I see is to store in the database links to all the files generated by the build, and modify the user interface to eliminate the differentiation between image files and other files created by the build in the "tmp/deploy/images/" directory. Passing the bug to Belen for needed design changes. 48217 2 belen.barros.pena 2015-01-23 10:47:34 +0000 So we had a chat about this. It is right now impossible to tell with 100% accuracy which artifacts are root file systems. But we do know that often file names that contain the string 'rootfs' are root file systems. So we will use that to separate the build artifacts, in the assumption that it will work the majority of time, and that separating the artifacts in the interface helps people to easily find their images. 48248 3 alexandru.damian 2015-01-23 17:48:10 +0000 Pushed for review on poky-contrib:adamian/20150123-review 48429 4 alexandru.damian 2015-01-30 13:33:31 +0000 merged in master 48594 5 ionutx.chisanovici 2015-02-05 16:17:18 +0000 Verified in 1.8 M2 RC2, commit: 22c38e2d8a058619e3d05534b5e830b750aa4241. Issue is fixed. Cheers, Ionut C