[PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[Ross Burton]

If debug filesystem generation is enabled but this isn't assigned then the
generation code throws exceptions.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/conf/bitbake.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 1c4175f..8e02e91 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -713,6 +713,7 @@ require conf/sanity.conf
 DL_DIR ?= "${TOPDIR}/downloads"
 SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
 IMAGE_FSTYPES ?= "tar.gz"
+IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
 
 INITRAMFS_FSTYPES ?= "cpio.gz"
 # The maximum size in Kbytes for the generated initramfs image size.
-- 
2.8.0.rc3

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Fri, May 06, 2016 at 12:26:40PM +0100, Ross Burton wrote:
> If debug filesystem generation is enabled but this isn't assigned then the
> generation code throws exceptions.

Acked-by: Martin Jansa <Martin.Jansa@gmail.com>

Thanks

> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/conf/bitbake.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 1c4175f..8e02e91 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -713,6 +713,7 @@ require conf/sanity.conf
>  DL_DIR ?= "${TOPDIR}/downloads"
>  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>  IMAGE_FSTYPES ?= "tar.gz"
> +IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
>  
>  INITRAMFS_FSTYPES ?= "cpio.gz"
>  # The maximum size in Kbytes for the generated initramfs image size.
> -- 
> 2.8.0.rc3
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[Mark Hatle]

On 5/6/16 6:26 AM, Ross Burton wrote:
> If debug filesystem generation is enabled but this isn't assigned then the
> generation code throws exceptions.
> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
Acked-by: Mark Hatle <mark.hatle@windriver.com>

(This is the patch that I thought had been sent before.. obviously didn't happen..)

Thanks!
--Mark

> ---
>  meta/conf/bitbake.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 1c4175f..8e02e91 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -713,6 +713,7 @@ require conf/sanity.conf
>  DL_DIR ?= "${TOPDIR}/downloads"
>  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>  IMAGE_FSTYPES ?= "tar.gz"
> +IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
>  
>  INITRAMFS_FSTYPES ?= "cpio.gz"
>  # The maximum size in Kbytes for the generated initramfs image size.
> 

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]


> On May 6, 2016, at 6:51 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 
> On 5/6/16 6:26 AM, Ross Burton wrote:
>> If debug filesystem generation is enabled but this isn't assigned then the
>> generation code throws exceptions.
>> 
>> Signed-off-by: Ross Burton <ross.burton@intel.com>
> Acked-by: Mark Hatle <mark.hatle@windriver.com>
> 
> (This is the patch that I thought had been sent before.. obviously didn't happen..)
> 

Please bring this to krogoth as well.

> Thanks!
> --Mark
> 
>> ---
>> meta/conf/bitbake.conf | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 1c4175f..8e02e91 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -713,6 +713,7 @@ require conf/sanity.conf
>> DL_DIR ?= "${TOPDIR}/downloads"
>> SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>> IMAGE_FSTYPES ?= "tar.gz"
>> +IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
>> 
>> INITRAMFS_FSTYPES ?= "cpio.gz"
>> # The maximum size in Kbytes for the generated initramfs image size.
>> 
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[André Draszik]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

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?


On Fr, 2016-05-06 at 12:26 +0100, Ross Burton wrote:
> If debug filesystem generation is enabled but this isn't assigned then the
> generation code throws exceptions.
> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/conf/bitbake.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 1c4175f..8e02e91 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -713,6 +713,7 @@ require conf/sanity.conf
>  DL_DIR ?= "${TOPDIR}/downloads"
>  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>  IMAGE_FSTYPES ?= "tar.gz"
> +IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
>  
>  INITRAMFS_FSTYPES ?= "cpio.gz"
>  # The maximum size in Kbytes for the generated initramfs image size.
> -- 
> 2.8.0.rc3
> 

[-- Attachment #2: 0001-image.bbclass-allow-IMAGE_FSTYPES_DEBUGFS-to-be-unse.patch --]
[-- Type: text/x-patch, Size: 2157 bytes --]

From 001ab66c36b18b8a3f25b1116a8c6580c676a673 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <git@andred.net>
Date: Tue, 12 Apr 2016 09:14:40 +0100
Subject: [PATCH] image.bbclass: allow IMAGE_FSTYPES_DEBUGFS to be unset (as
 per the documentation)

conf/local.conf.sample.extended describes IMAGE_FSTYPES_DEBUGFS as defaulting
to IMAGE_FSTYPES if unset.

If you actually do that, i.e. enable IMAGE_GEN_DEBUGFS but don't set
IMAGE_FSTYPES_DEBUGFS, you get the following parse error:

ERROR: Error executing a python function in <code>:

The stack trace of python calls that resulted in this exception/failure was:
File: '<code>', lineno: 14, function: <module>
     0010:__anon_38__meta_classes_rootfs_ipk_bbclass(d)
     0011:__anon_113__meta_classes_image_bbclass(d)
     0012:__anon_176__meta_classes_image_bbclass(d)
     0013:__anon_146__meta_classes_siteinfo_bbclass(d)
 *** 0014:__anon_437__meta_classes_image_bbclass(d)
File: '<poky>meta/classes/image.bbclass', lineno: 322, function: __anon_437__meta_classes_image_bbclass
     0318:    typedeps = {}
     0319:
     0320:    if d.getVar('IMAGE_GEN_DEBUGFS', True) == "1":
     0321:        debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True).split()
 *** 0322:        for t in debugfs_fstypes:
     0323:            alltypes.append("debugfs_" + t)
     0324:
     0325:    def _add_type(t):
     0326:        baset = _image_base_type(t)
Exception: AttributeError: 'NoneType' object has no attribute 'split'
---
 meta/classes/image.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index acaa9ec..59ba38e 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -318,8 +318,8 @@ python () {
     typedeps = {}
 
     if d.getVar('IMAGE_GEN_DEBUGFS', True) == "1":
-        debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True).split()
-        for t in debugfs_fstypes:
+        debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True) or ''
+        for t in debugfs_fstypes.split():
             alltypes.append("debugfs_" + t)
 
     def _add_type(t):
-- 
2.8.1

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[Mark Hatle]

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'.

You should check if the patch has been applied to the "krogoth" branch.

--Mark

> 
> On Fr, 2016-05-06 at 12:26 +0100, Ross Burton wrote:
>> If debug filesystem generation is enabled but this isn't assigned then the
>> generation code throws exceptions.
>>
>> Signed-off-by: Ross Burton <ross.burton@intel.com>
>> ---
>>  meta/conf/bitbake.conf | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 1c4175f..8e02e91 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -713,6 +713,7 @@ require conf/sanity.conf
>>  DL_DIR ?= "${TOPDIR}/downloads"
>>  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>>  IMAGE_FSTYPES ?= "tar.gz"
>> +IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"
>>  
>>  INITRAMFS_FSTYPES ?= "cpio.gz"
>>  # The maximum size in Kbytes for the generated initramfs image size.
>> -- 
>> 2.8.0.rc3
>>
>>

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[André Draszik]

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.


Cheers,
André

Re: [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é
> 

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[André Draszik]

Thanks Mark.

Nothing is pulling vmdk into my builds. vmdk does not end up in my
IMAGE_FSTYPES or IMAGE_FSTYPES_DEBUGFS. Again, the output from bitbake
-e is fine when reverting Ross' patch and applying the patch I posted
earlier instead. With Ross' patch (only), bitbake doesn't even finish
parsing due to the exception being thrown (so bitbake -e output is
empty apart from the exception).

I know I can set IMAGE_FSTYPES_DEBUGFS explicitly to work around the
issue, but that's not it is intended to work.

Cheers,
Andre

On Fri, May 27, 2016 at 4:21 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 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é
>>
>

Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS

[André Draszik]

Hi,

On Fr, 2016-05-27 at 21:42 +0100, André Draszik wrote:
> 
> On Fri, May 27, 2016 at 4:21 PM, Mark Hatle <mark.hatle@windriver.com>
> wrote:
> > 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.


> Nothing is pulling vmdk into my builds. vmdk does not end up in
> my IMAGE_FSTYPES or IMAGE_FSTYPES_DEBUGFS. Again, the output from bitbake
> -e is fine when reverting Ross' patch and applying the patch I posted
> earlier instead. With Ross' patch (only), bitbake doesn't even finish
> parsing due to the exception being thrown (so bitbake -e output is empty
> apart from the exception).
> 
> I know I can set IMAGE_FSTYPES_DEBUGFS explicitly to work around the
> issue, but that's not it is intended to work.


Do you have any more suggestions how to debug this?

I am still in the exact same position. I need to revert Ross' patch and
apply the patch I sent before.

Is anybody successfully using this feature?


Cheers,
Andre'