Re: udev breakage

[Gary Thomas <gary@mlbassoc.com>]

[-- Attachment #1: Type: text/plain, Size: 4785 bytes --]

On 2013-04-23 11:31, Gary Thomas wrote:
> 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@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@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@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
>

One last follow-up - I found that currently the "unpack" step leaves
the majority of the work directory untouched and simply unpacks and
patches the sources on top of what's there.  In this case (and probably
others), this is not sufficient to be able to rebuild the package properly.

A simple change in behaviour is to have the unpack step make sure it is starting
fresh.  This fixes the problem reported above and is easily done with the
attached patch.

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

[-- Attachment #2: clean-unpack.patch --]
[-- Type: text/x-patch, Size: 465 bytes --]

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 641316d..d81fb21 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -114,7 +114,7 @@ python base_do_fetch() {
 
 addtask unpack after do_fetch
 do_unpack[dirs] = "${WORKDIR}"
-do_unpack[cleandirs] = "${S}/patches"
+do_unpack[cleandirs] = "${S}"
 python base_do_unpack() {
     src_uri = (d.getVar('SRC_URI', True) or "").split()
     if len(src_uri) == 0: