Patchwork udev 182: Create a symlink of /lib/udev/udevd in /sbin

login
register
mail settings
Submitter Shakeel, Muhammad
Date Nov. 27, 2012, 12:57 p.m.
Message ID <1354021038-26183-1-git-send-email-muhammad_shakeel@mentor.com>
Download mbox | patch
Permalink /patch/39693/
State New
Headers show

Comments

Shakeel, Muhammad - Nov. 27, 2012, 12:57 p.m.
From: Muhammad Shakeel <muhammad_shakeel@mentor.com>

From udev 174 changelog:
"The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
and non-dracut initramfs image generators need to change the init
scripts. Alternatively the udev build needs to move udevd back to
/sbin or create a symlink in /sbin, which is not done by default."

Also for 64 bit architectures there exists /lib64/udev instead of
/lib/udev and current init script fails to start udev.

Signed-off-by: Muhammad Shakeel <muhammad_shakeel@mentor.com>
---
 meta/recipes-core/udev/udev.inc    |    4 ++++
 meta/recipes-core/udev/udev/init   |    4 ++--
 meta/recipes-core/udev/udev_182.bb |    2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
Otavio Salvador - Nov. 27, 2012, 2:15 p.m.
On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
<muhammad_shakeel@mentor.com> wrote:
> From: Muhammad Shakeel <muhammad_shakeel@mentor.com>
>
> From udev 174 changelog:
> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
> and non-dracut initramfs image generators need to change the init
> scripts. Alternatively the udev build needs to move udevd back to
> /sbin or create a symlink in /sbin, which is not done by default."
>
> Also for 64 bit architectures there exists /lib64/udev instead of
> /lib/udev and current init script fails to start udev.
>
> Signed-off-by: Muhammad Shakeel <muhammad_shakeel@mentor.com>

As far as I know, all code in master now handles it properly (the
missing bits I sent a patch today) so why to include this symlink?
Qi.Chen@windriver.com - Nov. 28, 2012, 2:26 a.m.
On 11/27/2012 10:15 PM, Otavio Salvador wrote:
> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
> <muhammad_shakeel@mentor.com>  wrote:
>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>
>>  From udev 174 changelog:
>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
>> and non-dracut initramfs image generators need to change the init
>> scripts. Alternatively the udev build needs to move udevd back to
>> /sbin or create a symlink in /sbin, which is not done by default."
>>
>> Also for 64 bit architectures there exists /lib64/udev instead of
>> /lib/udev and current init script fails to start udev.
>>
>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
> As far as I know, all code in master now handles it properly (the
> missing bits I sent a patch today) so why to include this symlink?
>
I'm not sure about this.

Two things:

1) Have we ever tested udev on a target where its ${base_libdir} is 
'/lib64'?
Apparently, if udevd is intalled under '/lib64', its init script cannot 
start udev correctly.

2) Bug#2804 is related to to udev and ${base_libdir}.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
(Some packages hardcode their udev rules directory to be 
'/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is 
'/lib64'? )
Otavio Salvador - Nov. 28, 2012, 10:51 a.m.
On Wed, Nov 28, 2012 at 12:26 AM, ChenQi <Qi.Chen@windriver.com> wrote:
> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>
>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
>> <muhammad_shakeel@mentor.com>  wrote:
>>>
>>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>
>>>  From udev 174 changelog:
>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
>>> and non-dracut initramfs image generators need to change the init
>>> scripts. Alternatively the udev build needs to move udevd back to
>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>
>>> Also for 64 bit architectures there exists /lib64/udev instead of
>>> /lib/udev and current init script fails to start udev.
>>>
>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>
>> As far as I know, all code in master now handles it properly (the
>> missing bits I sent a patch today) so why to include this symlink?
>>
> I'm not sure about this.
>
> Two things:
>
> 1) Have we ever tested udev on a target where its ${base_libdir} is
> '/lib64'?
> Apparently, if udevd is intalled under '/lib64', its init script cannot
> start udev correctly.
>
> 2) Bug#2804 is related to to udev and ${base_libdir}.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
> (Some packages hardcode their udev rules directory to be
> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is
> '/lib64'? )

It seems the right fix for it is to ensure udev is always installed in
/lib/udev/udevd (for all targets) as you propose to do for the rules.d
directory.
Shakeel, Muhammad - Nov. 28, 2012, 11:09 a.m.
If we ensure that udev will always be found in /lib/udev/udevd then this patch will not be required.

Actually I needed this patch to start udev on a mips64 target where ${base_libdir} is '/lib64' and original udev init script was failing to start udev.
(I am not using initramfs).

--Shakeel

-----Original Message-----
From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
Sent: Wednesday, November 28, 2012 3:52 PM
To: ChenQi
Cc: Shakeel, Muhammad; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin

On Wed, Nov 28, 2012 at 12:26 AM, ChenQi <Qi.Chen@windriver.com> wrote:
> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>
>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad 
>> <muhammad_shakeel@mentor.com>  wrote:
>>>
>>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>
>>>  From udev 174 changelog:
>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems 
>>> and non-dracut initramfs image generators need to change the init 
>>> scripts. Alternatively the udev build needs to move udevd back to 
>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>
>>> Also for 64 bit architectures there exists /lib64/udev instead of 
>>> /lib/udev and current init script fails to start udev.
>>>
>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>
>> As far as I know, all code in master now handles it properly (the 
>> missing bits I sent a patch today) so why to include this symlink?
>>
> I'm not sure about this.
>
> Two things:
>
> 1) Have we ever tested udev on a target where its ${base_libdir} is 
> '/lib64'?
> Apparently, if udevd is intalled under '/lib64', its init script 
> cannot start udev correctly.
>
> 2) Bug#2804 is related to to udev and ${base_libdir}.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
> (Some packages hardcode their udev rules directory to be 
> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is 
> '/lib64'? )

It seems the right fix for it is to ensure udev is always installed in /lib/udev/udevd (for all targets) as you propose to do for the rules.d directory.
Qi.Chen@windriver.com - Nov. 29, 2012, 9:26 a.m.
So the question would be:
Is it reasonable to always intall udev under /lib?

udev's user manual seems to imply this behavior.

Thanks,
Chen Qi

On 11/28/2012 07:09 PM, Shakeel, Muhammad wrote:
> If we ensure that udev will always be found in /lib/udev/udevd then this patch will not be required.
>
> Actually I needed this patch to start udev on a mips64 target where ${base_libdir} is '/lib64' and original udev init script was failing to start udev.
> (I am not using initramfs).
>
> --Shakeel
>
> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
> Sent: Wednesday, November 28, 2012 3:52 PM
> To: ChenQi
> Cc: Shakeel, Muhammad; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
>
> On Wed, Nov 28, 2012 at 12:26 AM, ChenQi<Qi.Chen@windriver.com>  wrote:
>> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
>>> <muhammad_shakeel@mentor.com>   wrote:
>>>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>>
>>>>    From udev 174 changelog:
>>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
>>>> and non-dracut initramfs image generators need to change the init
>>>> scripts. Alternatively the udev build needs to move udevd back to
>>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>>
>>>> Also for 64 bit architectures there exists /lib64/udev instead of
>>>> /lib/udev and current init script fails to start udev.
>>>>
>>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>> As far as I know, all code in master now handles it properly (the
>>> missing bits I sent a patch today) so why to include this symlink?
>>>
>> I'm not sure about this.
>>
>> Two things:
>>
>> 1) Have we ever tested udev on a target where its ${base_libdir} is
>> '/lib64'?
>> Apparently, if udevd is intalled under '/lib64', its init script
>> cannot start udev correctly.
>>
>> 2) Bug#2804 is related to to udev and ${base_libdir}.
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
>> (Some packages hardcode their udev rules directory to be
>> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is
>> '/lib64'? )
> It seems the right fix for it is to ensure udev is always installed in /lib/udev/udevd (for all targets) as you propose to do for the rules.d directory.
>
Otavio Salvador - Nov. 29, 2012, 10:49 a.m.
On Thu, Nov 29, 2012 at 7:26 AM, ChenQi <Qi.Chen@windriver.com> wrote:
> So the question would be:
> Is it reasonable to always intall udev under /lib?
>
> udev's user manual seems to imply this behavior.

I think so.
Qi.Chen@windriver.com - Nov. 30, 2012, 6 a.m.
On 11/28/2012 07:09 PM, Shakeel, Muhammad wrote:
> If we ensure that udev will always be found in /lib/udev/udevd then this patch will not be required.
>
> Actually I needed this patch to start udev on a mips64 target where ${base_libdir} is '/lib64' and original udev init script was failing to start udev.
> (I am not using initramfs).
>
> --Shakeel
Hi Muhammad,

I'm somewhat confused by this 'baselib' problem. I just built udev on a 
test machine which has mips64 arch. But it turned out that its baselib 
was '/lib' instead of '/lib64'.

How did you get '/lib64' on a mips64 target?

My test machine's conf file is:
"
require conf/machine/include/tune-mips64.inc

KERNEL_IMAGETYPE = "vmlinux"
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"

SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
"

Besides, I tried it on x86-64.  As long as we don't explicitly specify 
multilib (lib64) for udev, it defaults to '/lib'.

I seems that the baselib defaults to '/lib64' only when the target has 
powerpc64 arch.

Could you please give me some more information to help me?

Thanks,
Chen Qi

> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
> Sent: Wednesday, November 28, 2012 3:52 PM
> To: ChenQi
> Cc: Shakeel, Muhammad; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
>
> On Wed, Nov 28, 2012 at 12:26 AM, ChenQi<Qi.Chen@windriver.com>  wrote:
>> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
>>> <muhammad_shakeel@mentor.com>   wrote:
>>>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>>
>>>>    From udev 174 changelog:
>>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
>>>> and non-dracut initramfs image generators need to change the init
>>>> scripts. Alternatively the udev build needs to move udevd back to
>>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>>
>>>> Also for 64 bit architectures there exists /lib64/udev instead of
>>>> /lib/udev and current init script fails to start udev.
>>>>
>>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>> As far as I know, all code in master now handles it properly (the
>>> missing bits I sent a patch today) so why to include this symlink?
>>>
>> I'm not sure about this.
>>
>> Two things:
>>
>> 1) Have we ever tested udev on a target where its ${base_libdir} is
>> '/lib64'?
>> Apparently, if udevd is intalled under '/lib64', its init script
>> cannot start udev correctly.
>>
>> 2) Bug#2804 is related to to udev and ${base_libdir}.
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
>> (Some packages hardcode their udev rules directory to be
>> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is
>> '/lib64'? )
> It seems the right fix for it is to ensure udev is always installed in /lib/udev/udevd (for all targets) as you propose to do for the rules.d directory.
>
Shakeel, Muhammad - Dec. 5, 2012, 1:31 p.m.
Hi Chen Qi,

Seems like baselib is getting value from here:
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"

In your conf file, tune-mips64.inc requires arch-mips.inc which sets:

DEFAULTTUNE ?= "mips"
and then:
BASE_LIB_tune-mips = "lib"

This seems to be the reason that why you get /lib in 'baselib' even for mips64 arch.

I have a modified conf file which sets 'DEFAULTTUNE" to 'mips64'  explicitly.

DEFAULTTUNE="mips64"

And arch-mips.inc has:
BASE_LIB_tune-mips64 = "lib64"

I am sure if you modify DEFAULTTUNE in your conf file then you will get /lib64 in baselib.

(Sorry for replying late as I forgot to flag this conversation.)

Regards,
Shakeel

-----Original Message-----
From: ChenQi [mailto:Qi.Chen@windriver.com] 
Sent: Friday, November 30, 2012 11:01 AM
To: Shakeel, Muhammad
Cc: openembedded-core@lists.openembedded.org; Otavio Salvador
Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin

On 11/28/2012 07:09 PM, Shakeel, Muhammad wrote:
> If we ensure that udev will always be found in /lib/udev/udevd then this patch will not be required.
>
> Actually I needed this patch to start udev on a mips64 target where ${base_libdir} is '/lib64' and original udev init script was failing to start udev.
> (I am not using initramfs).
>
> --Shakeel
Hi Muhammad,

I'm somewhat confused by this 'baselib' problem. I just built udev on a test machine which has mips64 arch. But it turned out that its baselib was '/lib' instead of '/lib64'.

How did you get '/lib64' on a mips64 target?

My test machine's conf file is:
"
require conf/machine/include/tune-mips64.inc

KERNEL_IMAGETYPE = "vmlinux"
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"

SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
"

Besides, I tried it on x86-64.  As long as we don't explicitly specify multilib (lib64) for udev, it defaults to '/lib'.

I seems that the baselib defaults to '/lib64' only when the target has
powerpc64 arch.

Could you please give me some more information to help me?

Thanks,
Chen Qi

> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On 
> Behalf Of Otavio Salvador
> Sent: Wednesday, November 28, 2012 3:52 PM
> To: ChenQi
> Cc: Shakeel, Muhammad; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of 
> /lib/udev/udevd in /sbin
>
> On Wed, Nov 28, 2012 at 12:26 AM, ChenQi<Qi.Chen@windriver.com>  wrote:
>> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
>>> <muhammad_shakeel@mentor.com>   wrote:
>>>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>>
>>>>    From udev 174 changelog:
>>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems 
>>>> and non-dracut initramfs image generators need to change the init 
>>>> scripts. Alternatively the udev build needs to move udevd back to 
>>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>>
>>>> Also for 64 bit architectures there exists /lib64/udev instead of 
>>>> /lib/udev and current init script fails to start udev.
>>>>
>>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>> As far as I know, all code in master now handles it properly (the 
>>> missing bits I sent a patch today) so why to include this symlink?
>>>
>> I'm not sure about this.
>>
>> Two things:
>>
>> 1) Have we ever tested udev on a target where its ${base_libdir} is 
>> '/lib64'?
>> Apparently, if udevd is intalled under '/lib64', its init script 
>> cannot start udev correctly.
>>
>> 2) Bug#2804 is related to to udev and ${base_libdir}.
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
>> (Some packages hardcode their udev rules directory to be 
>> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is 
>> '/lib64'? )
> It seems the right fix for it is to ensure udev is always installed in /lib/udev/udevd (for all targets) as you propose to do for the rules.d directory.
>
Mark Hatle - Dec. 5, 2012, 2 p.m.
On 12/5/12 7:31 AM, Shakeel, Muhammad wrote:
> Hi Chen Qi,
>
> Seems like baselib is getting value from here:
> baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"
>
> In your conf file, tune-mips64.inc requires arch-mips.inc which sets:
>
> DEFAULTTUNE ?= "mips"
> and then:
> BASE_LIB_tune-mips = "lib"
>
> This seems to be the reason that why you get /lib in 'baselib' even for mips64 arch.
>
> I have a modified conf file which sets 'DEFAULTTUNE" to 'mips64'  explicitly.

It really should be the machine configuration that sets the DEFAULTTUNE properly 
for the board.  While the tune-mips64.inc should likely set a DEFAULTTUNE ?= 
"mips64" it doesn't have to be done that way... and in this case there is a 
reason it's not.

On most MIPS architectures, people are not going to actually want the default 
tune to be MIPS64, what they really want is an alterantive library support for 
MIPS64, with a primary library of either o32 (mips32) or n32 (32-bit mips64). 
This is why it's really up to the machine configuration, and ultimately the end 
user's configuration to determine the appropriate DEFAULTTUNE... the tune files 
are just guidelines to make it easier.

> DEFAULTTUNE="mips64"
>
> And arch-mips.inc has:
> BASE_LIB_tune-mips64 = "lib64"
>
> I am sure if you modify DEFAULTTUNE in your conf file then you will get /lib64 in baselib.
>
> (Sorry for replying late as I forgot to flag this conversation.)
>
> Regards,
> Shakeel
>
> -----Original Message-----
> From: ChenQi [mailto:Qi.Chen@windriver.com]
> Sent: Friday, November 30, 2012 11:01 AM
> To: Shakeel, Muhammad
> Cc: openembedded-core@lists.openembedded.org; Otavio Salvador
> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
>
> On 11/28/2012 07:09 PM, Shakeel, Muhammad wrote:
>> If we ensure that udev will always be found in /lib/udev/udevd then this patch will not be required.
>>
>> Actually I needed this patch to start udev on a mips64 target where ${base_libdir} is '/lib64' and original udev init script was failing to start udev.
>> (I am not using initramfs).
>>
>> --Shakeel
> Hi Muhammad,
>
> I'm somewhat confused by this 'baselib' problem. I just built udev on a test machine which has mips64 arch. But it turned out that its baselib was '/lib' instead of '/lib64'.
>
> How did you get '/lib64' on a mips64 target?
>
> My test machine's conf file is:
> "
> require conf/machine/include/tune-mips64.inc
>
> KERNEL_IMAGETYPE = "vmlinux"
> KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
>
> SERIAL_CONSOLE = "115200 ttyS0"
>
> MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> "
>
> Besides, I tried it on x86-64.  As long as we don't explicitly specify multilib (lib64) for udev, it defaults to '/lib'.
>
> I seems that the baselib defaults to '/lib64' only when the target has
> powerpc64 arch.
>
> Could you please give me some more information to help me?
>
> Thanks,
> Chen Qi
>
>> -----Original Message-----
>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>> Behalf Of Otavio Salvador
>> Sent: Wednesday, November 28, 2012 3:52 PM
>> To: ChenQi
>> Cc: Shakeel, Muhammad; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of
>> /lib/udev/udevd in /sbin
>>
>> On Wed, Nov 28, 2012 at 12:26 AM, ChenQi<Qi.Chen@windriver.com>  wrote:
>>> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
>>>> <muhammad_shakeel@mentor.com>   wrote:
>>>>> From: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>>>
>>>>>     From udev 174 changelog:
>>>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
>>>>> and non-dracut initramfs image generators need to change the init
>>>>> scripts. Alternatively the udev build needs to move udevd back to
>>>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>>>
>>>>> Also for 64 bit architectures there exists /lib64/udev instead of
>>>>> /lib/udev and current init script fails to start udev.
>>>>>
>>>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel@mentor.com>
>>>> As far as I know, all code in master now handles it properly (the
>>>> missing bits I sent a patch today) so why to include this symlink?
>>>>
>>> I'm not sure about this.
>>>
>>> Two things:
>>>
>>> 1) Have we ever tested udev on a target where its ${base_libdir} is
>>> '/lib64'?
>>> Apparently, if udevd is intalled under '/lib64', its init script
>>> cannot start udev correctly.
>>>
>>> 2) Bug#2804 is related to to udev and ${base_libdir}.
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
>>> (Some packages hardcode their udev rules directory to be
>>> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is
>>> '/lib64'? )
>> It seems the right fix for it is to ensure udev is always installed in /lib/udev/udevd (for all targets) as you propose to do for the rules.d directory.
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Patch

diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index 4705b9b..a882efe 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -96,5 +96,9 @@  do_install_append () {
 	# hid2hci has moved to bluez4. removed in udev as of version 169
 	rm -f ${D}${base_libdir}/udev/hid2hci
 
+        # Create a symlink of /lib/udev/udevd in /sbin
+        install -d ${D}${base_sbindir}
+        ln -s ..${base_libdir}/udev/udevd ${D}${base_sbindir}/udevd
+
 	echo 'udev_run="/var/run/udev"' >> ${D}${sysconfdir}/udev/udev.conf
 }
diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init
index 74449fe..84631ac 100644
--- a/meta/recipes-core/udev/udev/init
+++ b/meta/recipes-core/udev/udev/init
@@ -13,7 +13,7 @@  export TZ=/etc/localtime
 
 [ -d /sys/class ] || exit 1
 [ -r /proc/mounts ] || exit 1
-[ -x /lib/udev/udevd ] || exit 1
+[ -x /sbin/udevd ] || exit 1
 [ -f /etc/default/udev-cache ] && . /etc/default/udev-cache
 [ -f /etc/udev/udev.conf ] && . /etc/udev/udev.conf
 
@@ -69,7 +69,7 @@  kill_udevd > "/dev/null" 2>&1
 
 # trigger the sorted events
 echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug
-/lib/udev/udevd -d
+/sbin/udevd -d
 
 /usr/bin/udevadm control --env=STARTUP=1
 if [ "$not_first_boot" != "" ];then
diff --git a/meta/recipes-core/udev/udev_182.bb b/meta/recipes-core/udev/udev_182.bb
index c41de9f..0ae9f8c 100644
--- a/meta/recipes-core/udev/udev_182.bb
+++ b/meta/recipes-core/udev/udev_182.bb
@@ -1,6 +1,6 @@ 
 include udev.inc
 
-PR = "r2"
+PR = "r3"
 
 # module-init-tools from kmod_git will provide libkmod runtime
 DEPENDS += "module-init-tools"