|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST creates unbootable initrd file, due to an ld.so.conf customization | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.1 | Reporter: | Bruno Haible <bruno> |
| Component: | YaST2 | Assignee: | Michal Marek <mmarek> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
What you're doing - shadowing libncurses - is nothing that we recommend and support. openSUSE <= 12.1 is no longer active. If you still can reproduce the problem with openSUSE 12.3 or Factory, please reopen the bug and change the product field accordingly. Sorry that I did not have time to address this bug. |
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20100101 Firefox/9.0 Operating system: openSUSE 12.1. In the course of some use of YaST, it replaced the file /boot/initrd-3.1.0-1.2-desktop (to which /boot/initrd is a symbolic link). At the next boot, I got a kernel panic, because the 'init' process exited. The 'init' process exited because it is a shell script, and /bin/bash (inside the initrd gzipped cpio archive) depends on libncurses.so.5 which was not packaged into the initrd in the location /lib64/. The cause is that 1) I have a file /etc/ld.so.conf.d/packages.conf which contains the line /arch/x86_64-linux/gnu/lib64 In the running system, this line is included through the wildcard statement in /etc/ld.so.conf. 2) In /arch/x86_64-linux/gnu/lib64 I have an older copy of libncurses.so.5 and libncurses.so.5.7 (built by myself before the upgrade to openSUSE 12.1). 3) /bin/bash depends on libncurses. So, in the running system, after doing "ldconfig", I have $ ldd /bin/bash linux-vdso.so.1 => (0x00007fff5e117000) libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fddf3843000) libncurses.so.5 => /arch/x86_64-linux/gnu/lib64/libncurses.so.5 (0x00007fddf35ef000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fddf33eb000) libc.so.6 => /lib64/libc.so.6 (0x00007fddf305c000) /lib64/ld-linux-x86-64.so.2 (0x00007fddf3a8a000) The initrd that YaST has created (most probably via initrd) has the files bin/bash arch/x86_64-linux/gnu/lib64/libncurses.so.5 arch/x86_64-linux/gnu/lib64/libncurses.so.5.7 (among others). It does NOT contain /lib64/libncurses.so.*. AND it does not have the /etc/ld.so.conf customization that allows the /lib64/ld-linux-x86-64.so.2 loader to find the library in the non-standard place. So, when booting, the process with pid 1, which attempts to run /bin/bash, fails. Reproducible: Didn't try Steps to Reproduce: 1. Create a directory /my/lib64, add libncurses.so.5 and libncurses.so.5.8 to it. 2. Create a file /etc/ld.so.conf.d/packages.conf with the line /my/lib64 3. Run "ldconfig" and verify that "ldd /bin/bash" now references the library in /my/lib64. 4. Run YaST and make it create a new initrd (or, possibly, run mkinitrd manually). 5. Reboot. Actual Results: Kernel panic Expected Results: Successful reboot Fixing the unbootable system involved looking at the mkinitrd(8) manual page, and following the "RECOVERY" recipe in said manual page. Unfortunately the "rescue" system on the installation disk was unusable for this purpose - it does not even have a "man" command. Without the openSUSE "live CD" it would have been impossible for me to create a new, working initrd. Things would also have been simpler if mkinitrd would make a backup copy of the previous /boot/initrd-3.1.0-1.2-desktop in the same directory, say, under the name /boot/initrd-3.1.0-1.2-desktop.bak.