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.