On Wed, Nov 28, 2012 at 12:26 AM, ChenQi <qi.c...@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_shak...@mentor.com> wrote:
>>>
>>> From: Muhammad Shakeel<muhammad_shak...@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_shak...@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: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
