[Clfs-dev] Need another set of eyes or more on udev changes

William Harrington berzerkula at cox.net
Tue Aug 21 16:48:16 PDT 2012


I have confirmed three builds with issues:  GIT x86_64 Pure64 and  
x86_64 Multilib and PowerPC all have the same issues:

Here is the output of udev using current configuration options in GIT  
final system udev configure command:

./configure --prefix=/usr   --exec-prefix="" --sysconfdir=/etc   -- 
with-usb-ids-path=no --with-pci-ids-path=no   --disable-introspection  
--disable-keymap

         udev 182
         ========

         prefix:                  /usr
         rootprefix:              /usr
         sysconfdir:              /etc
         bindir:                  ${exec_prefix}/bin
         libdir:                  ${exec_prefix}/lib
         rootlibdir:              ${exec_prefix}/lib
         libexecdir:              ${exec_prefix}/libexec
         datarootdir:             ${prefix}/share
         mandir:                  ${datarootdir}/man
         includedir:              ${prefix}/include
         include_prefix:
         systemdsystemunitdir:
         firmware path:           \"/usr/lib/firmware/updates/\", \"/ 
usr/lib/firmware/\"
         usb.ids:                 no
         pci.ids:                 no

         compiler:                gcc
         cflags:                  -g -O2
         ldflags:
         xsltproc:
         gperf:

         logging:                 yes
         debug:                   no
         selinux:                 no

         man pages                yes
         gudev:                   yes
         gintrospection:          no
         keymap:                  no
         mtd_probe:               yes
         rule_generator:          no
         floppy:                  no



This results in /libexecdir/udev  (where udevd is and the bootscripts  
don't like)
This also results in /lib/udev (where devices are)
This also results in /bin/udevadm (which the bootscripts like but it  
needs to be in sbin)
This also results in firmware not being loaded because /lib/firmware  
is not in the firmware path?

Do we agree with this? Can anyone replicate the issue? I have this on  
three builds.

This is what my proposes change ( while in chroot of my x86_64 pure64  
build):

  ./configure --prefix=/usr   --exec-prefix="" --with-rootprefix="" -- 
sysconfdir=/etc   --libexecdir=/lib --libdir=/lib --enable- 
rule_generator   --with-usb-ids-path=no --with-pci-ids-path=no   -- 
disable-introspection --disable-keymap --disable-gudev

         udev 182
         ========em

         prefix:                  /usr
         rootprefix:
         sysconfdir:              /etc
         bindir:                  ${exec_prefix}/bin
         libdir:                  /lib
         rootlibdir:              /lib
         libexecdir:              /lib
         datarootdir:             ${prefix}/share
         mandir:                  ${datarootdir}/man
         includedir:              ${prefix}/include
         include_prefix:
         systemdsystemunitdir:
         firmware path:           \"/lib/firmware/updates/\", \"/lib/ 
firmware/\"
         usb.ids:                 no
         pci.ids:                 no

         compiler:                gcc
         cflags:                  -g -O2
         ldflags:
         xsltproc:
         gperf:

         logging:                 yes
         debug:                   no
         selinux:                 no

         man pages                yes
         gudev:                   no
         gintrospection:          no
         keymap:                  no
         mtd_probe:               yes
         rule_generator:          yes
         floppy:                  no

Which puts udev into /lib indefinitely, no /libexec
Which also puts udevadmn in /bin to make bootscripts happy
And firmware is loaded from /lib/firmware.
Also disables gudev.
Also adds rule generator

See the differences?

I'm going to do another build soon with x86, as I haven't done that  
yet and I'm going to see what goes on. If I get the same results as I  
did with my 3 other builds to see if I get the same issues. I  
probably will. It is becoming consistent..

Sincerely,

William Harrington



More information about the Clfs-dev mailing list