| Summary: | Enable the capability to check the details of an image when is already booted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Runtime] General Runtime | Reporter: | Jose Perez C <jose.perez.carranza> | ||||
| Component: | General Runtime | Assignee: | Joshua Lock <joshuagloe> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | Medium | CC: | alejandro.hernandez, anibal.limon, benjamin.esquivel, bluelightning, joshuagloe, juan.m.cruz.alcaraz, leonardo.sandoval.gonzalez, mariano.lopez, richard.purdie, ross.burton, sgw | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 2.5 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
Would be easy to add a recipe to do this, similar to the os-release recipe[1]. Under what scenario would we include it in images so that it's useful for QA without adding a useless file for other users? i.e. we can't just unconditionally add this to all core-image-* 1. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/os-release/os-release.bb since QA tests the images that come out of the autobuilder, you can't really differentiate them that way. The main focus of this bug is to know which image is this installation coming from. You can tell the distro and the BSP from the booting messages but you cannot say whether this is core image sato, minimal or full-cmdline whithout doing some guessing of the filesystem you landed on. Without this feature, for certainly knowing which image you are running, you are forced to re-install every time. It would be easier to drop a couple of more variables if we delivered an /etc/*release* file but we don't do releases so we thought we could use some other info file to append the data we want. This sounds like a job for the image-buildinfo class - you'd just need to ensure that IMAGE_BASENAME (or IMAGE_NAME, depending on what you want) is listed in IMAGE_BUILDINFO_VARS. This is the output of the /etc/build once the vars Paul suggested are added and the inheriting of image-buildinfo is set in the config: root@genericx86-64:~# cat /etc/build ----------------------- Build Configuration: | ----------------------- DISTRO = poky DISTRO_VERSION = 2.2 IMAGE_BASENAME = core-image-base IMAGE_NAME = core-image-base-genericx86-64-20161027154309 ----------------------- Layer Revisions: | ----------------------- meta = master:e5815d0b607ff262663864d51fe51fbb37172329 -- modified meta-poky = master:e5815d0b607ff262663864d51fe51fbb37172329 -- modified meta-yocto-bsp = master:e5815d0b607ff262663864d51fe51fbb37172329 -- modified meta-intel = master:8dbd551c1ce6d7124f4bf70030415bda5f154030 I think that info and mechanism are fine but can we put this on the release candidates and the release images? (In reply to comment #5) > I think that info and mechanism are fine but can we put this on the release > candidates and the release images? I don't remember the specific reason why we couldnt add this on releases, if it is meant for QA only perhaps we can add it manually on the AB buildsets though. This is yocto-autobuilder related enhancement. one of the key parameters for adding this to the released images is build performance. If this bug gets implemented, it should be verified that performance is not degraded. Also for the WIC images we will need that that wks parameter used to build the image is included on the details. José, would you figure which variable gives you that info you're requesting? (In reply to comment #10) > José, would you figure which variable gives you that info you're requesting? Not sure Saul or Ed may know that.. add the to the CC list to have their input. I believe it would be WKS_FILE and EFI_PROVIDER would also be valuable but those would be conditional on whether meta-intel is included or not. I CC'ed a number of people who might have an opinion on adding an extra configuration file to the images generated by the autobuilder. I guess that if no comment is made here, we can proceed to sending the patch. Hi all, I am the new assignee of this bug. After reading through the comments, I would like to propose the implementation below. Based on Paul's recommendation on inheriting image-buildinfo bbclass, we are able to produce an image with the said requirement. I am going to implement into AB buildset-config.yocto-qa if no other further comments. Created attachment 4168 [details]
RFC
RFC on the implementation
It looks like GDC QA were requesting for this info to be available on images generated by the public AB, therefore we should be making the change to buildset-config.controller (and deploying to the public AB infrastructure).
I'm wondering if it would be cleaner to teach CreateAutoConf how to write the value with a variable, rather than having to add the line to each atextappend.
That way the buildset-config change would look something like:
{'CreateAutoConf': {'imageinfo': True}}
and a few LOC in CreateAutoConf.py would handle writing the correct config fragment.
Rebecca, feel free to assign this to me if you'd like as I'll have to perform the deployment anyway.
Joshua, you have it! :) Code is merged to the yocto-autobuilder repository, will deploy next week. Code is deployed on both clusters |
Currently when an image is already booted there is no way to know what kind of image is and some other details. Would be great to have a config file inside of the image showing all the details of the image as: - Image type: core-image-sato - poky-commit : XXXXXXX - Build date: XXXX-XX-XX - Layers used : - XXXX - XXXX - XXXX