Running 12.3 x86_64 with LVM encrypted boot with luks. Everytime I upgrade, mkinitrd creates a non-bootable initrd image that fails to include /lib64/libz.so.1 linked to libz.so.1.2.7 (does not copy in libz.so.1.2.7). Boot fails with “VolGroup not found” in endless cycle. Potential executables included in the initrd that require libz according to ldd and might be important to booting include:
/sbin/modprobe
/sbin/resume
/usr/lib64/directfb-1.6-0/libdirectfb_fbdev.so and others
/lib64/libcrypto.so.1.0.0
Manually unpacking the generated initrd, adding the libz libraries, and repacking results in a workable boot, but it’s highly annoying given that every time there’s a kernel upgrade, mkinitrd generates an unbootable system.
How to I instruct mkinitrd to always include /lib64/libz libraries ?
OK, I found the problem by running mkinitrd with the -v option and looking at the shared libraries list. On the problem system a “rogue” version of libz installed, I believe, by a 32-bit EMBOSS application suite in /usr/local/lib/libz.so.1.2.7 linked to /usr/local/lib/libz.so.1 was being installed by mkinitrd into the initrd rather than the system x86_64 /lib64/libz.so.1.2.7 linked to /lib64/libz.so.1. After removing the local libz libraries, which are 32-bit and not the library linked to by other libraries and executables as specified by ldd, mkinitrd generated a bootable initrd file.
It seems to me the script really shouldn’t allow this to happen, i.e. it is a bug, as it should install the exact system library specified by ldd for the needed executables, but I have to confess the setup-sharedli:)bs.sh script is pretty opaque to me.
> It seems to me the script really shouldn’t allow this to happen, i.e. it
> is a bug, as it should install the exact system library specified by
> ldd for the needed executables, but I have to confess the
> setup-sharedli:)bs.sh script is pretty opaque to me.
