Results 1 to 5 of 5

Thread: Missing libz in initrd

  1. #1

    Angry Missing libz in initrd

    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 ?

    justdave601

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,673
    Blog Entries
    3

    Default Re: Missing libz in initrd

    Quote Originally Posted by justdave601 View Post
    How to I instruct mkinitrd to always include /lib64/libz libraries ?
    It looks as if this is supposed to be handled by the script "/lib/mkinitrd/scripts/setup-sharedlibs.sh".

    You could try a bug report.

    I am not having any problems with an encrypted LVM in 13.1, and I had no problems with 12.3.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

  3. #3

    Red face Re: Missing libz in initrd

    Quote Originally Posted by nrickert View Post
    It looks as if this is supposed to be handled by the script "/lib/mkinitrd/scripts/setup-sharedlibs.sh".

    You could try a bug report.

    I am not having any problems with an encrypted LVM in 13.1, and I had no problems with 12.3.
    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-sharedlibs.sh script is pretty opaque to me.

    justdave601

  4. #4
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,673
    Blog Entries
    3

    Default Re: Missing libz in initrd

    Quote Originally Posted by justdave601 View Post
    It seems to me the script really shouldn't allow this to happen, i.e. it *is* a bug,
    I'm glad you managed to fix the particular problem system.

    I'm inclined to agree that it is a bug. I suggest you report it. And yes, that script isn't easy to read.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

  5. #5
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Missing libz in initrd

    On 2013-12-17 23:56, justdave601 wrote:

    > 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-sharedlibs.sh script is pretty opaque to me.


    openSUSE:Submitting bug
    reports


    ;-)

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.3 x86_64 "Dartmouth" at Telcontar)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •