Date
1 - 5 of 5
How to overwrite IMAGE_FSTYPES variable in loacal.conf using placement of kas file wic-targz-img.yml
|
Venkata Pyla
Hi,
I am trying to overwrite the IMAGE_FSTYPES variable with the values in wic-targz-img.yml by keeping at the end in kas file definition as shown in below command, but it is not overwriting. $ kas-container build kas-cip.yml:kas/opt/ebg-swu.yml:kas/opt/wic-targz-img.yml kas/opt/ebg-swu.yml include local_conf_header as below ----------------------------------------- local_conf_header: ... wic-swu: | ... IMAGE_FSTYPES = "wic" ... ----------------------------------------- kas/opt/wic-targz-img.yml include local_conf_header as below ----------------------------------------- local_conf_header: ... image-type: | ... IMAGE_FSTYPES = "wic tar.gz" ... ----------------------------------------- Final conf/local.conf generate as below ----------------------------------------- # image-type IMAGE_FSTYPES = "wic tar.gz" ... # wic-swu IMAGE_FSTYPES = "wic" ----------------------------------------- Expecting conf/local.conf ----------------------------------------- # wic-swu IMAGE_FSTYPES = "wic" ... # image-type IMAGE_FSTYPES = "wic tar.gz" ----------------------------------------- The above is possible when I use name with higher in alphabetical order like 'zimage-type:' in the wic-targz-img.yml kas/opt/wic-targz-img.yml with ----------------------------------------- local_conf_header: ... zimage-type: | ... IMAGE_FSTYPES = "wic tar.gz" ... ----------------------------------------- Is this the only solution to set the order of the variable assignment in local_conf_header? Thanks, Venkata. |
|
|
|
Jan Kiszka
On 31.01.23 17:55, Venkata.Pyla@... wrote:
Hi,local.conf nodes are alphabetically sorted as you already found out - we should probably document that in kas. Generally spoken, you can make use of that to achieve append behaviour, or you overwrite the original node you are competing with. In case of isar-cip-core, we can rearrange or kas option files so that your use case becomes possible (though I'm unsure if it makes any sense: the content of the tar.gz will be only a subset of the wic swupdate image). Jan -- Siemens AG, Technology Competence Center Embedded Linux |
|
|
|
Venkata Pyla
toggle quoted message
Show quoted text
-----Original Message-----Thanks for confirming, I want to create swupdate image that should generate both tar.gz and wic image and use tar.gz for reproducibility checks. I probably have to modify this file kas/opt/swupdate.yml to include both in IMAGE_FSTYPES = "wic tar.gz".
|
|
|
|
Jan Kiszka
On 01.02.23 12:39, Venkata.Pyla@... wrote:
To clarify again: What I meant is either aligning the node names in the-----Original Message-----Thanks for confirming, kas files or converting wic-targz-img.yml to targz-img.yml with IMAGE_FSTYPES_append. But I don't get yet why reproducibility checking is limited to tar.gz outputs. Can't it be run against the common input, given that it works only for the rootfs so far? Jan -- Siemens AG, Technology Competence Center Embedded Linux |
|
|
|
Venkata Pyla
toggle quoted message
Show quoted text
-----Original Message-----Changing the node names should work, but I need to give irrelevant name just to increase the sorting order. The other approach is use " IMAGE_FSTYPES_append" in all yaml files like "swupdate.yaml" and "targz-img.yml" because if one of the yaml file has "IMAGE_FSTYPES = " will replace the other if it comes later in the sorting order. Currently wic is not comparable with diffoscope, so I am checking only tar balls in reproducible build.
|
|
|