--------------
Summary:
This problem is in essence (AFAICT) the same as #337176, #420754
I think the solution is to fix the hook-functions to not just
catch a few well known optimized locations, but to also dereference
library paths to absolute locations? (or create the initrd with
symlinks for found lib directories back to /lib)
(sorry, i don't have enough time to really dig into this, myself)
--------------
If /etc/ld.so.conf contains /lib64, update-initramfs will create a
filesystem containing /lib64/libcrypt.so.1, but /bin/sh is looking only
for /lib/libcrypto.so.1 yielding:
So /lib64 is default symlink to /lib (on running system):
+ stat -c %N /lib64
`/lib64' -> `/lib'
+ grep lib64 /etc/ld.so.conf
/lib64
Note: you could argue this is a "mistake", but the end result is that
kernel security updates render the system unbootable. As far as the
running system is concerned, since /lib64 is a symlink to /lib, it
operates the same. Theoretically, though someone COULD make /lib64
a real directory and have a custom libcrypt.so.1 there and i suspect
that update-initramfs would still break.
+ ldconfig -p
+ grep libcrypt.so
libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.0) => /lib64/libcrypt.so.1
libcrypt.so.1 (libc6, OS ABI: Linux 2.6.0) => /lib32/libcrypt.so.1
libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.0) => /usr/lib/libcrypt.so
note that /lib64 is where libcrypt.so is found in this configuration.
If i remove /lib64 from /etc/ld.so.conf and 'ldconfig', we get instead:
+ ldconfig -p
+ grep libcrypt.so
libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.0) => /lib/libcrypt.so.1
libcrypt.so.1 (libc6, OS ABI: Linux 2.6.0) => /lib32/libcrypt.so.1
libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.0) => /usr/lib/libcrypt.so
(where it's now found in /lib)
+ gunzip -c /boot/initrd.img-2.6.18-6-amd64.bak
+ cpio -tiv
+ grep crypt
28172 blocks
-rw-r--r-- 1 root root 22656 Jan 4 2009 lib64/libcrypt.so.1
Note: i'm using the .bak since we fixed the system previously by
removing /lib64 from /etc/ld.so.conf and i've only put it back
in here for the bugreport (so /boot/initrd.img-2.6.18-6-amd64
is fixed as seen here:.
+ gunzip -c /boot/initrd.img-2.6.18-6-amd64
+ cpio -tiv
+ grep crypt
28172 blocks
-rw-r--r-- 1 root root 22656 Jan 4 2009 lib/libcrypt.so.1
thanks,
--stephen
RE: [ Severity set to 'important' from 'critical' Request was from maximilian attems <maks@debian.org> ] I just wanted to point out that i had difficulty determining HOW to address the severity field in reportbug. Because i *do* have a workaround to the "problem", it's not critical to *me* anymore, and wasn't at the point i submitted the bug. But the question that debian reportbug asks is:-------------------------------- How would you rate the severity of this problem or report? 1 critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.) 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. ... Please select a severity level: [normal]-------------------------------- in a generic sense, this *problem* is critical, because it DOES render end-user systems broken. "...makes...(or the whole system) break..." (not being able to boot due to kernel panic certainly falls under "system breakage") So, given the language from reportbug, i answered honestly that this bug does indeed break the whole system, therefore it is a critical problem. my *specific* problem *report* itself is not critical, because i am operational now that i've determined the nature of the problem. (if i were under a security compliance obligation and was still incapable of booting my system due to this bug, i would consider this problem VERY critical) So, in this reply, i am simply voicing my concern that a better wording in reportbug addressing this type of discrepency be employed. Perhaps a distinction between end-user "urgency" and problem "severity" is needed. It's certainly not my intent to distract developers from more important tasks (i can tell from other bug reports i'm not the only one affected by this, but i don't believe the affected end-user base is very large) I only bring this up, because i've also seen other users wonder about how to classify bug report severity as well. thanks, --stephen
clone 543815 -1 reassign -1 reportbug retitle -1 overinflated linux-2.6 bug reports stop dear reportbug maintainer, never seen this trouble so nicely phrased. *one* box not booting is not a critical bug in the sense that it works on X other boxes, so it doesn' make the package unusable for all the other, could you have an cuttof for linux-2.6 submittions on important severity and let us maintainer upgrade specific ones, instead of beeing bothered every day to have to downgrade X reports. thanks