Bug 1324746

Indeed that's strange. But does it cause any issues?

No, no issues seen so far.

Still present on Fedora 26 Alpha.

I have these too, with different directories.

I believe it MAY have something to do with entries in /etc/ld.so.conf.d/ -- more exactly, although this is pure conjecture though it APPEARS to fit the pattern (at least on my machine), it appears that an empty directory is created that corresponds to each /etc/ld.so.conf.d/ entry which points to a directory in /usr/lib64 (and possibly /usr/lib as well), and does so WITHOUT a trailing slash at the end of that directory path.

So, for example, here's what my /etc/ld.so.conf.d/ looks like:

$ grep . /etc/ld.so.conf.d/*                   
/etc/ld.so.conf.d/atlas-x86_64.conf:/usr/lib64/atlas
/etc/ld.so.conf.d/bind99-x86_64.conf:/usr/lib64/bind99
/etc/ld.so.conf.d/cuda-9-1.conf:/usr/local/cuda-9.1/targets/x86_64-linux/lib
/etc/ld.so.conf.d/dyninst-x86_64.conf:/usr/lib64/dyninst
/etc/ld.so.conf.d/kernel-4.15.17-300.fc27.x86_64.conf:    # Placeholder file, no vDSO hwcap entries used in this kernel.
/etc/ld.so.conf.d/kernel-4.16.4-200.fc27.x86_64.conf:    # Placeholder file, no vDSO hwcap entries used in this kernel.
/etc/ld.so.conf.d/kernel-4.16.5-200.fc27.x86_64.conf:    # Placeholder file, no vDSO hwcap entries used in this kernel.
/etc/ld.so.conf.d/libiscsi-x86_64.conf:/usr/lib64/iscsi
/etc/ld.so.conf.d/libnsl2-x86_64.conf:/usr/lib64/nsl
/etc/ld.so.conf.d/qt-x86_64.conf:/usr/lib64/qt-3.3/lib
/etc/ld.so.conf.d/recoll-x86_64.conf:/usr/lib64/recoll
/etc/ld.so.conf.d/wine-32.conf:/usr/lib/wine/
/etc/ld.so.conf.d/wine-64.conf:/usr/lib64/wine/
/etc/ld.so.conf.d/xulrunner-64.conf:/usr/lib64/xulrunner

Sure enough, my current initrd contains all of these (empty) directories under /usr/lib64/: atlas, bind99, dyninst, iscsi, nsl, recoll, xulrunner

It doesn't contain /usr/lib/wine or /usr/lib64/wine directories, which I'm theorizing is explained by the trailing slash. It also doesn't contain /usr/lib64/qt-3.3/lib or /usr/local/cuda-9.1/targets/x86_64-linux/lib because there's no way to confuse them for files in /usr/lib or /usr/lib64.

Keep in mind, all of the files in /etc/ld.so.conf.d/ are themselves copied into the initrd, so having them refer to paths that actually exist isn't even a particularly crazy thing. Ultimately these directories seem harmless, and their presence seems adequately explained by the existence of corresponding /etc/ld.so.conf.d/ files.

(In reply to "FeRD" (Frank Dana) from comment #4)
>
> Sure enough, my current initrd contains all of these (empty) directories
> under /usr/lib64/: atlas, bind99, dyninst, iscsi, nsl, recoll, xulrunner
> 
> It doesn't contain /usr/lib/wine or /usr/lib64/wine directories, which I'm
> theorizing is explained by the trailing slash. It also doesn't contain
> /usr/lib64/qt-3.3/lib or /usr/local/cuda-9.1/targets/x86_64-linux/lib
> because there's no way to confuse them for files in /usr/lib or /usr/lib64.

I experimentally hand-edited /etc/ld.so.conf.d/atlas-x86_64.conf and /etc/ld.so.conf.d/libiscsi-x86_64.conf to contain paths with trailing slashes, and this did not eliminate the empty directories in initrd, even after running `ldconfig` and then building a new initrd using `new-kernel-pkg`. So, this part of my conjecture was wrong.

I still think it has something to do with the ld.so cache, as I notice that there aren't actually any entries in the cache for /usr/lib{,64}/wine. The directories that DO appear, appear because those paths are found in the cache (or so my theory goes). Observe:

% sudo ldconfig -N -p|grep -i wine
	libwine.so.1 (libc6,x86-64) => /lib64/libwine.so.1
	libwine.so.1 (libc6) => /lib/libwine.so.1

% sudo ldconfig -N -p|grep -i atlas
	libtatlas.so.3 (libc6,x86-64) => /usr/lib64/atlas/libtatlas.so.3
	libsatlas.so.3 (libc6,x86-64) => /usr/lib64/atlas/libsatlas.so.3

% sudo lsinitrd /boot/initramfs-4.16.8-300.fc28.x86_64.img|egrep '(atlas|wine)'
-rw-r--r--   1 root     root           18 Mar  5 08:16 etc/ld.so.conf.d/atlas-x86_64.conf
-rw-r--r--   1 root     root           15 Mar  5 08:16 etc/ld.so.conf.d/wine-32.conf
-rw-r--r--   1 root     root           17 Mar  5 08:16 etc/ld.so.conf.d/wine-64.conf
drwxr-xr-x   2 root     root            0 Mar  5 08:16 usr/lib64/atlas

Yeah, dracut additionally creates all directories found with:

ldconfig -pN 2>/dev/null \
  | grep -E -v '/(lib|lib64|usr/lib|usr/lib64)/[^/]*$' \
  | sed -n 's,.* => \(.*\)/.*,\1,p' | sort | uniq


If this bothers you sooo much, I can add a function to clean up empty directories at the end.

https://github.com/dracutdevs/dracut/commit/f6e777ec4b1031b18b835cd34ed644ebf4a2ace6

(In reply to Harald Hoyer from comment #6)
>
> If this bothers you sooo much, I can add a function to clean up empty
> directories at the end.

For the record, though I certainly can't speak for Christian, the empty dirs never bothered ME at all. It simply became an irresistible puzzle to figure out why they were there in the first place, after they were pointed out. 

Still, thanks for the fix! 👍

(In reply to Harald Hoyer from comment #6)
> If this bothers you sooo much, I can add a function to clean up empty
> directories at the end.

It's not about bothering me, it's about "if this is wrong, what else will be wrong?).

Thank you very much for the fix!

I cannot reproduce this issue in Fedora 29 Beta any more. Dracut version: dracut-048-14.git20180726.fc29.x86_64

Yeah, it's even cleared up in F28.

In /boot/initramfs-4.18.11-200.fc28.x86_64.img, /usr/lib64/ only contains the directories plymouth/, bind9-export/, and device-mapper/, all of which have contents.