[OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin

Shakeel, Muhammad Muhammad_Shakeel at mentor.com
Wed Dec 5 13:31:40 UTC 2012


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 at windriver.com] 
Sent: Friday, November 30, 2012 11:01 AM
To: Shakeel, Muhammad
Cc: openembedded-core at 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 at gmail.com [mailto:otavio.salvador at gmail.com] On 
> Behalf Of Otavio Salvador
> Sent: Wednesday, November 28, 2012 3:52 PM
> To: ChenQi
> Cc: Shakeel, Muhammad; openembedded-core at 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 at 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 at mentor.com>   wrote:
>>>> From: Muhammad Shakeel<muhammad_shakeel at 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 at 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.
>





More information about the Openembedded-core mailing list