Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "André Draszik" <git@andred.net>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS
Date: Thu, 14 Jul 2016 11:04:55 +0100	[thread overview]
Message-ID: <1468490695.17743.8.camel@andred.net> (raw)
In-Reply-To: <CAKUP++sNL9QmS9zqL2_dZBb6wRDiZJFnzkgid9+x+Anv_44QFg@mail.gmail.com>

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'



      reply	other threads:[~2016-07-14 10:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-06 11:26 [PATCH] bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS Ross Burton
2016-05-06 11:40 ` Martin Jansa
2016-05-06 13:51 ` Mark Hatle
2016-05-06 14:13   ` Khem Raj
2016-05-27 10:54 ` André Draszik
2016-05-27 14:21   ` Mark Hatle
2016-05-27 14:42     ` André Draszik
2016-05-27 15:21       ` Mark Hatle
2016-05-27 20:42         ` André Draszik
2016-07-14 10:04           ` André Draszik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1468490695.17743.8.camel@andred.net \
    --to=git@andred.net \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox