Bug 7213

Summary: Toaster image files are not recorded for generic-x86 (and variants) builds
Product: [Build System, Metadata & Runtime] Toaster Reporter: Ionut Chisanovici <ionutx.chisanovici>
Component: toasterAssignee: Alexandru Damian <alexandru.damian>
Status: VERIFIED FIXED QA Contact: Ionut Chisanovici <ionutx.chisanovici>
Severity: normal    
Priority: High CC: alexandru.damian, belen.barros.pena, bluelightning, bogdanx.a.voiculescu, cristiana.voicu
Version: 1.8   
Target Milestone: 1.8 M3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: New (Never tested)
Verified: Documentation change: No (bug/feature does not impact docs)

Description Ionut Chisanovici 2015-01-21 09:44:12 UTC
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
Comment 1 Alexandru Damian 2015-01-22 18:08:58 UTC
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.
Comment 2 Belen Barros Pena 2015-01-23 10:47:34 UTC
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.
Comment 3 Alexandru Damian 2015-01-23 17:48:10 UTC
Pushed for review on 

poky-contrib:adamian/20150123-review
Comment 4 Alexandru Damian 2015-01-30 13:33:31 UTC
merged in master
Comment 5 Ionut Chisanovici 2015-02-05 16:17:18 UTC
Verified in 1.8 M2 RC2, commit: 22c38e2d8a058619e3d05534b5e830b750aa4241.
Issue is fixed.

Cheers,
Ionut C