On Wed, Nov 28, 2012 at 12:26 AM, ChenQi <[email protected]> wrote: > On 11/27/2012 10:15 PM, Otavio Salvador wrote: >> >> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad >> <[email protected]> wrote: >>> >>> From: Muhammad Shakeel<[email protected]> >>> >>> 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<[email protected]> >> >> 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: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
