* udev breakage
@ 2013-04-22 23:09 Gary Thomas
2013-04-23 10:34 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2013-04-22 23:09 UTC (permalink / raw)
To: Yocto Project
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.
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: udev breakage
2013-04-22 23:09 udev breakage Gary Thomas
@ 2013-04-23 10:34 ` Gary Thomas
2013-04-23 17:31 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2013-04-23 10:34 UTC (permalink / raw)
To: Yocto Project
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)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: udev breakage
2013-04-23 10:34 ` Gary Thomas
@ 2013-04-23 17:31 ` Gary Thomas
2013-04-24 11:00 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2013-04-23 17:31 UTC (permalink / raw)
To: Yocto Project
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
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: udev breakage
2013-04-23 17:31 ` Gary Thomas
@ 2013-04-24 11:00 ` Gary Thomas
0 siblings, 0 replies; 4+ messages in thread
From: Gary Thomas @ 2013-04-24 11:00 UTC (permalink / raw)
To: Yocto Project
[-- 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:
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-24 11:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-22 23:09 udev breakage Gary Thomas
2013-04-23 10:34 ` Gary Thomas
2013-04-23 17:31 ` Gary Thomas
2013-04-24 11:00 ` Gary Thomas
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.