[OE-core] [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[Mark Hatle]

On 5/27/16 9:42 AM, André Draszik wrote:
> On Fr, 2016-05-27 at 09:21 -0500, Mark Hatle wrote:
>> On 5/27/16 5:54 AM, André Draszik wrote:
>>> This doesn't work for me (at least on krogoth):
>>>
>>>     ERROR: poky/meta/recipes-core/images/build-appliance-
>>> image_14.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry
>>> 'debugfs_vmdk' - possibly invalid type name or missing support class
>>>     ERROR: Failed to parse recipe: poky/meta/recipes-core/images/build-
>>> appliance-image_14.0.0.bb
>>>
>>> I *instead* am using the attached patch successfully.
>>>
>>> Is anybody else facing the same issue?
>>
>> Ross's patch should have fixed this.  It ensures that
>> IMAGE_FSTYPES_DEBUGFS is
>> always set to 'something'.
> 
> Yes, and now bitbake is looking for an IMAGE_CMD for debugfs_vmdk according
> to the error message. Note that I didn't specify vmdk anywhere, my
> IMAGE_FSTYPES is set to .tar.gz only.
> 
>> You should check if the patch has been applied to the "krogoth" branch.
> 
> I did apply it locally. For me, it only works if i revert Ross' patch and
> apply my patch instead.
> 

Use bitbake -e <image>.  View the IMAGE_FSTYPES and IMAGE_FSTYPES_DEBUGFS.  Do
you see vmdk in the former?  If so, look at the comments above it and it shoudl
show you where it came from.

My guess is you have an image or BSP that is hard coding a specific 'vmdk'.

I agree there is a problem here, some filesystem types do not make sense for
debugfs type.  I'm not sure how to necessarily reconcile this behavior, but vmdk
doesn't seem reasonable to me here..

But first figure out where it's coming from.

Setting IMAGE_FSTYPES_DEBUGFS = "tar.gz" in your local.conf should be enough to
set the value and avoid the behavior.  If it's not, again look at the bitbake -e
output and see what it's saying it's doing.

--Mark

> Cheers,
> André
>