[yocto] udev breakage

[Gary Thomas]

On 2013-04-23 04:34, Gary Thomas wrote:
> On 2013-04-22 17:09, Gary Thomas wrote:
>> I've found that Poky/Yocto images built after this commit have
>> a broken udev:
>>
>> commit c71d1f446c734954dceba0666c4f074047864b87
>> Author: Richard Purdie <richard.purdie at linuxfoundation.org>
>> Date:   Wed Apr 17 14:53:21 2013 +0000
>>
>>      udev: Effectively revert the move to /sbin
>>
>>      This effectively reverts the changes made in b49ddeb11c0319b7ece278fd7cef6b0223114ca9
>>      to move udev's libexecdir to sbin. The changes caused too many issues in
>>      other places and were not well enough tested this close to a release.
>>
>>      Rather than use base_libdir, the nonarch version is used to try and give some
>>      chance of multilib not being totally broken in the release.
>>
>>      (From OE-Core rev: c50e50fdafad378d75b7b74259a3d55ca0fe3d18)
>>
>>      Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
>>
>> Prior to this commit, the X server finds my input devices and works
>> perfectly.  After this commit, something breaks and X can't find any
>> keyboard/mouse/touch.
>>
>> It seems like the path '/sbin/udev' has crept in some way that the
>> recipe configuration does not affect.  After the failing commit, all
>> of the udev files should be in ${nonarch_base_libdir}, not /sbin.
>> However, that doesn't seem to be the case in libudev
>>
>> root at sabrelite:~# strings /lib/libudev.so.0 | grep /udev
>> /etc/udev/udev.conf
>> /run/udev
>> /sbin/udev/rules.d
>> /etc/udev/rules.d
>>
>> I believe that this is why X is failing since it uses libudev to
>> search for devices.
>>
>> I've not found where/how this mixup is happening, perhaps someone more
>> familiar with the udev code can spot it quickly.
>
>
> Somehow this misconfiguration ended up in a number of the executable
> programs in the udev package:
>
> ******* /usr/bin/udevadm
> /sbin/udev/ /sbin/udev/rules.d
> ******* /lib/libudev.so.0.13.1
> /sbin/udev/rules.d
> ******* /lib/udev/ata_id
> /sbin/udev/rules.d
> ******* /lib/udev/collect
> /sbin/udev/rules.d
> ******* /lib/udev/accelerometer
> /sbin/udev/rules.d
> ******* /lib/udev/cdrom_id
> /sbin/udev/rules.d
> ******* /lib/udev/udevd
> /sbin/udev/ /sbin/udev/devices /sbin/udev/rules.d
> ******* /lib/udev/scsi_id
> /sbin/udev/rules.d
> ******* /lib/udev/keymap
> /sbin/udev/keymaps/
>
>
> Just to see if this is the problem, I added a symlink
>    # ln -s ${nonarch_base_libdir}/udev /sbin
> and X now works (after a reboot)
>

Continuing research on this shows that all of the above was a
[long] journey down a twisty rabbit hole :-(

There does seem to be a problem with rebuilds and repository updates,
at least for this recipe.  Here's what I found:

* Build clean udev using a repo that precedes the revision mentioned above.
   % git checkout c71d1f~1
   % bitbake udev -c cleansstate;bitbake udev
   % strings tmp/work/arm*/udev/*/image/usr/bin/udevadm | grep sbin
   /sbin/udev/
   /sbin/udev/rules.d

* Now update the repo to the bad revision (or later) and rebuild without
   cleaning udev tree, just like you would if you update the repo and just
   do an incremental build
   % git checkout c71d1f
   % bitbake udev
   % strings tmp/work/arm*/udev/*/image/usr/bin/udevadm | grep sbin
   /sbin/udev/
   /sbin/udev/rules.d

* No change to repo, just rebuild clean
   % bitbake udev -c cleansstate;bitbake udev
   % strings tmp/work/arm*/udev/*/image/usr/bin/udevadm | grep sbin
   ... none

Oops!  I wonder how many other packages/recipes suffer from this?  I try
to not rebuild from scratch when possible (since it takes many hours) and
rely on bitbake to make sure the right things happen.  Sadly in this case
something isn't working properly.

The actual log of my experiment is at http://www.mlbassoc.com/poky/build_udev.log

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------