[SOLVED] systemd/udev-196 problem (devices not discovered)

re_nelson · 11-25-2012, 08:25 PM

For the very first time in my long experience with LFS, I finally ran into something that stumped me. Note that I follow the current SVN (now at version 20121122). Realizing that this is not a stable version, I always keep an older version of the source packages around in the event of a mishap. And, I'm back up and running just fine and dandy after rolling back from systemd/udev-196 to the prior systemd/udev-195.

I realize that the new 196 uses a binary database in /etc/udev/hwdb.bin. That database is indeed present, some 5 MB in size. I followed the instructions to the letter, including sed -i -e 's/create/update/' src/udev/udevadm-hwdb.c to patch the udevadm help message. The build process and subsequent install were error free.

So what am I finding wrong with 196 compared to its predecessor?

Well, when /etc/rc.d/init.d/udev executes during the system initialization, it shows [ OK ] but devices that ought to be newly-discovered aren't populated into /dev nor are the modules loaded. With the 195 version, there's some disk I/O and a period of time that elapses when udevadm settle as the devices are discovered.

The rollback to 195 was trivial but I am intrigued by what's so substantially different in the newer systemd/udev-196 package. That's what makes LFS so worthwhile and fun -- the troubleshooting and the satisfaction when a problem is resolved.

Time permitting, I may be able to run strace to get more information. In the meantime, has anyone tried the new 196 package and had success?

re_nelson · 11-26-2012, 11:21 AM

Quote:

Originally Posted by re_nelson

Time permitting, I may be able to run strace to get more information. In the meantime, has anyone tried the new 196 package and had success?

Having done so, I've found a difference (via strace) between 195 and 196. Taking the handling of sound as an example, here's what I've observed:

systemd/udev-195

Code:

openat(AT_FDCWD, "/sys/class/sound", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
getdents(4, /* 20 entries */, 32768)    = 624
readlink("/sys/class/sound/card0", "../../devices/pci0000:00/0000:00"..., 1024) = 49
stat("/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent", {st_mode=S_IFREG|0644, st_size=
readlink("/sys/class/sound/card1", "../../devices/pci0000:00/0000:00"..., 1024) = 62
[...]

systemd/udev-196

Code:

openat(AT_FDCWD, "/sys/class/sound", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
getdents(4, /* 2 entries */, 32768)     = 48
getdents(4, /* 0 entries */, 32768)     = 0
close(4)       
[...]

The newer version only finds 2 directory entries in the /sys/class/sound directory whereas the older 195 version finds 20 entries. Consequently, the latest systemd/udev doesn't load the sound modules and, as a result, ALSA's /proc/asound directory is not created.

Note that the ALSA sound system is all modular on my system, nothing is built into the kernel. With version 195, the Intel HDA sound card is "discovered" during the enumeration of /sys/class/sound and the module is automatically loaded by udev. That doesn't happen with version 196.

re_nelson · 11-29-2012, 03:13 PM

Quote:

Originally Posted by re_nelson

So what am I finding wrong with 196 compared to its predecessor (195)?

Well, when /etc/rc.d/init.d/udev executes during the system initialization, it shows [ OK ] but devices that ought to be newly-discovered aren't populated into /dev nor are the modules loaded. With the 195 version, there's some disk I/O and a period of time that elapses when udevadm settle as the devices are discovered.

The LFS folks (bdubbs in particular) fixed it upstream as explained here:

http://permalink.gmane.org/gmane.linux.lfs.book/24014

I almost wish I hadn't seen that post about the fix because I was about to allocate some time to track it down myself. Anyway, thanks to the LFS crew for noting the problem and providing a fix. The essence of the solution just boiled down to adding these lines to cfg.h:

Code:

#define HAVE_KMOD 1 
#define HAVE_BLKID 1