On 12/11/2012 01:11 PM, Paul Eggleton wrote:
On Tuesday 11 December 2012 12:54:57 Zach Tibbitts wrote:
I'm working on an embedded Linux platform for work to run an app that's
written with Gtk+3. The hardware in question is a Sandy Bridge Core i3
platform. With a vanilla Yocto build, I can boot an image just fine (I've
tested with core-image-basic, core-image-minimal, and core-image-x11) and
everything seems to work; I can even install it to the internal drive
without issue.
I found recipes for Gtk+3, as well as some of our other dependencies in the
meta-oe layer from the meta-openembedded repository. However, just adding
these layers and rebuilding any of the images that I've built (without
actually adding any new recipes) cause the image to hang when run on
hardware (but oddly enough not in QEMU).
The last line printed before the bootup apparently stops is along the lines
of: "sd 4:0:0:0: [sdb] Attached SCSI removable disk", and the line that
seems most at fault is a little farther up, "/init: line 69: udevd: not
found". If needed, I can try to capture more of the output, maybe with a
camera, I'm not sure of an easy way to pastebin the output from hardware...
What I'm wondering is if this is a known issue, or if meta-openembedded
isn't meant to be used in conjunction with Yocto. My assumption is that
something from meta-oe is superceeding a recipe in Yocto and causing this
failure.
This is a known issue in meta-oe unfortunately; the udev version there
apparently does not work outside of use with systemd. I believe the plan is to
drop udev from meta-oe fairly soon.
Is this recent? I've been running oe-core + meta-oe without meta-systemd
and don't think I've seen this. I haven't updated in a couple of weeks
though.
Philip
The workaround is to force the system to use the version of udev in meta/ -
I'm guessing you are using the 1.3 release version, in which case you can add
the following to your local.conf:
PREFERRED_VERSION_udev = "164"
Cheers,
Paul
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
