All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
To: openembedded-devel@lists.openembedded.org
Subject: Problem building with meta-oe udev_182 recipe
Date: Fri, 03 Aug 2012 19:07:27 +0100	[thread overview]
Message-ID: <501C135F.8000303@dynamicdevices.co.uk> (raw)

Hi all,

I'm taking a look at building a Poky DISTRO out of oe-core (met-yocto) 
for an atom-pc
MACHINE target.

I've tried a number of image recipes, from core-image-minimal, -base, 
-sato and so
forth. I have the the meta-oe layer pulled in via bblayers.config.

All images seem to hang on start-up, with a suspicious message about a 
missing udevd.

I've tried a range of bblayer configurations, both with and without the 
new meta-systemd
I've been hearing about, to no avail.

Current bblayers config is simply:

   /data_drive/stream/oe-core/meta \
   /data_drive/stream/oe-core/meta-openembedded/meta-oe \
   /data_drive/stream/oe-core/meta-yocto/meta-yocto \

Having investigated a little, I see that when I build udev, meta-oe 
provides a udev_182 which is the
default and there are QA warnings reported when building:

NOTE: package udev-182-r1: task do_package: Started
WARNING: QA Issue: udev: Files/directories were installed but not 
shipped  /usr/sbin
WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.1.1, installed in the 
base_prefix, requires a shared library under exec_prefix (/usr): 
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xdead1000)
WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.1.1, installed in the 
base_prefix, requires a shared library under exec_prefix (/usr): 
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xdead2000)
WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.1.1, installed in the 
base_prefix, requires a shared library under exec_prefix (/usr): 
libffi.so.5 => /usr/lib/libffi.so.5 (0xdead3000)
WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.1.1, installed in the 
base_prefix, requires a shared library under exec_prefix (/usr): 
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xdead4000)
WARNING: QA Issue: udev: /lib/udev/udevd, installed in the base_prefix, 
requires a shared library under exec_prefix (/usr): libkmod.so.2 => 
/usr/lib/libkmod.so.2 (0xdead3000)
NOTE: package udev-182-r1: task do_package: Succeeded

So that would seem to explain the missing udevd.

I did spot some conversation about a kmod_git.bb patch, which was 
reverted as it broke udev_182.bb, but this seems to have been reverted

http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg25435.html

I have found that setting PREFERRED_VERSION_udev = "164" in local.conf 
and rebuilding seems
to resolve the issue, but I'd like to understand what's going wrong 
rather than use the old udev.

Can anybody advise?

Is is as simple as "don't use the meta-oe layer"?

On a somewhat related note, when I add in the meta-systemd layer I get 
warnings about multiple providers for udev.
Should I be able simply to add in meta-systemd and define a 
PREFERRED_PROVIDER_udev = "systemd" ?

Thanks,

Alex



















                 reply	other threads:[~2012-08-03 18:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=501C135F.8000303@dynamicdevices.co.uk \
    --to=ajlennon@dynamicdevices.co.uk \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.