| Summary: | Udev broken in initrdscripts | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Andre Schramm <andre.schramm> | ||||||||||
| Component: | core | Assignee: | Radu Moisan <radu.moisan> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | critical | ||||||||||||
| Priority: | Medium+ | CC: | dvhart, meta.mr.watcher, meta.watcher, otavio, peterlei, Qi.Chen, ross.burton | ||||||||||
| Version: | 1.3 | ||||||||||||
| Target Milestone: | 1.4 M6 | ||||||||||||
| Hardware: | x86 | ||||||||||||
| OS: | x86_64 | ||||||||||||
| Whiteboard: | |||||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||||
| Verified: | Documentation change: | --- | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
Andre Schramm
2013-03-18 15:20:05 UTC
recipes-core/udev/udev/init needs to be changed as well: $ grep -n lib64 init 18:[ -x /lib64/udev/udevd ] || exit 1 74: /lib64/udev/udevd -d How did this work before, as the previous line was:
/lib/udev/udevd --daemon
It must have always been broken.
It works with the 1.3 release tarball, where udevd is under /sbin and thus in PATH. I then just did a test with the latest git version and a quick look at the log suggested, that this commit might be the problem. But I did not test any versions between, so yes - it might already have been broken before. Right, udev moved a lot in between 1.3 and now. guys, can you help me with instructions to reproduce this failure. I've build both 32 & 64bit quemu images and played a little with udev but could not really tell if there is a problem. I used core-image-minimal on x86_64. Starting it via: $ qemu-system-x86_64 -m 1024 -hda core-image-minimal.hddimg and booting the live image results in: /init: line 98: --daemon: not found Waiting for removable media... And then it just hangs. Doing the fixes above, everything is back to normal. Andree, it would also be useful for me to know what image did you build and if you had any special configuration for it. I'll give it a shoot for now with atom-pc. Created attachment 1150 [details]
image configuration
Created attachment 1151 [details]
kernel configuration
Created attachment 1152 [details]
machine configuration
Created attachment 1153 [details]
local configuration
Sorry, the image cfg is slightly wrong. Correct line is: IMAGE_FEATURES += "opengl glx ssh-server-openssh splash x11" eventually I used qemu: MACHINE ?= "qemux86-64" IMAGE_FSTYPES += "live" qemu-system-x86_64 -m 1024 -hda core-image-minimal-qemux86-64.hddimg I had not problems running the machine this way. I tried a few startups, and reboots, still not problem. "udevadm --v" gives me 182 every time with no error. Just seen Andree's comments. I'll look into attachments. I think the key point here is that multilib is enabled in Andre's case, which is why the binaries are in lib64. We need to run the init-live.sh script through sed to stop hard-coding the paths. Right. The system is basically 64b, I only install some 32b stuff to make custom software work. just notice myself multilib is enabled sent patches on mailing list, waiting for review. From my POV systemd and udevd needs to have /lib hardcoded by now so we take the safest route for 1.4 release and early in 1.5 release cycle we can make it configurable and work in all need recipes for it to work. it seems the problem goes quite deeper, the fix I've send does not resolve the root cause but rather the effect, I'll continue investigate. found an older patch on the mailing list that addresses this problem, but was nack'd at the time. Looking into resurrecting that one. http://patches.openembedded.org/patch/41167/ to sum up, we have three approaches here. One is patching the scripts looking in /lib, and adjust the path arch dependent, /lib vs /lib64. This recived a NACK from Koen who reasons that upstream community have agreed for udevd (and other binaries) to end in /lib no matter the architecture they are build for One another approach was to align with udev upstream, but then I got a NACK from Richard. It is not clear yet if following udev upstream is good for us (in terms of breaking multilib) The third approach, a quick fix for this bug, would be to move udevd back to /sbin (it was moved to /lib with the v182 upgrade) As I see it, third wariant would be less intrusive and cand get the job done, as far as this bug goes. For the bigger picture we might wait for 1.4 to pass and target then the problem. sent another patch on the mailing list targeting the third solution. waiting for review. |