Openembedded Core Discussions
 help / color / mirror / Atom feed
* [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
@ 2012-11-27 12:57 Shakeel, Muhammad
  2012-11-27 14:15 ` Otavio Salvador
  0 siblings, 1 reply; 10+ messages in thread
From: Shakeel, Muhammad @ 2012-11-27 12:57 UTC (permalink / raw)
  To: openembedded-core

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(-)

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"
-- 
1.7.9.5




^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-27 12:57 [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin Shakeel, Muhammad
@ 2012-11-27 14:15 ` Otavio Salvador
  2012-11-28  2:26   ` ChenQi
  0 siblings, 1 reply; 10+ messages in thread
From: Otavio Salvador @ 2012-11-27 14:15 UTC (permalink / raw)
  To: Shakeel, Muhammad; +Cc: openembedded-core

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?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-27 14:15 ` Otavio Salvador
@ 2012-11-28  2:26   ` ChenQi
  2012-11-28 10:51     ` Otavio Salvador
  0 siblings, 1 reply; 10+ messages in thread
From: ChenQi @ 2012-11-28  2:26 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: openembedded-core

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'? )






^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-28  2:26   ` ChenQi
@ 2012-11-28 10:51     ` Otavio Salvador
  2012-11-28 11:09       ` Shakeel, Muhammad
  0 siblings, 1 reply; 10+ messages in thread
From: Otavio Salvador @ 2012-11-28 10:51 UTC (permalink / raw)
  To: ChenQi; +Cc: openembedded-core

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                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-28 10:51     ` Otavio Salvador
@ 2012-11-28 11:09       ` Shakeel, Muhammad
  2012-11-29  9:26         ` ChenQi
  2012-11-30  6:00         ` ChenQi
  0 siblings, 2 replies; 10+ messages in thread
From: Shakeel, Muhammad @ 2012-11-28 11:09 UTC (permalink / raw)
  To: openembedded-core@lists.openembedded.org; +Cc: Otavio Salvador

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                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-28 11:09       ` Shakeel, Muhammad
@ 2012-11-29  9:26         ` ChenQi
  2012-11-29 10:49           ` Otavio Salvador
  2012-11-30  6:00         ` ChenQi
  1 sibling, 1 reply; 10+ messages in thread
From: ChenQi @ 2012-11-29  9:26 UTC (permalink / raw)
  To: Shakeel, Muhammad
  Cc: Otavio Salvador, openembedded-core@lists.openembedded.org

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.
>




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-29  9:26         ` ChenQi
@ 2012-11-29 10:49           ` Otavio Salvador
  0 siblings, 0 replies; 10+ messages in thread
From: Otavio Salvador @ 2012-11-29 10:49 UTC (permalink / raw)
  To: ChenQi; +Cc: Shakeel, Muhammad, openembedded-core@lists.openembedded.org

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.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-28 11:09       ` Shakeel, Muhammad
  2012-11-29  9:26         ` ChenQi
@ 2012-11-30  6:00         ` ChenQi
  2012-12-05 13:31           ` Shakeel, Muhammad
  1 sibling, 1 reply; 10+ messages in thread
From: ChenQi @ 2012-11-30  6:00 UTC (permalink / raw)
  To: Shakeel, Muhammad
  Cc: Otavio Salvador, openembedded-core@lists.openembedded.org

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.
>




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-11-30  6:00         ` ChenQi
@ 2012-12-05 13:31           ` Shakeel, Muhammad
  2012-12-05 14:00             ` Mark Hatle
  0 siblings, 1 reply; 10+ messages in thread
From: Shakeel, Muhammad @ 2012-12-05 13:31 UTC (permalink / raw)
  To: ChenQi; +Cc: Otavio Salvador, openembedded-core@lists.openembedded.org

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.
>




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
  2012-12-05 13:31           ` Shakeel, Muhammad
@ 2012-12-05 14:00             ` Mark Hatle
  0 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2012-12-05 14:00 UTC (permalink / raw)
  To: openembedded-core

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
>




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-12-05 14:15 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-27 12:57 [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin Shakeel, Muhammad
2012-11-27 14:15 ` Otavio Salvador
2012-11-28  2:26   ` ChenQi
2012-11-28 10:51     ` Otavio Salvador
2012-11-28 11:09       ` Shakeel, Muhammad
2012-11-29  9:26         ` ChenQi
2012-11-29 10:49           ` Otavio Salvador
2012-11-30  6:00         ` ChenQi
2012-12-05 13:31           ` Shakeel, Muhammad
2012-12-05 14:00             ` Mark Hatle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox