William Immendorf wrote: > On Mon, Mar 28, 2011 at 11:52 PM, Bryan Kadzban > <br...@kadzban.is-a-geek.net> wrote: >> Why is your linker looking in /lib64 when ldd reported it found the >> library in /lib? (Assuming that's what happened. The actual directory >> tree that got generated would be way more useful...) > Actually, ldd on /bin/bash generated libreadline.so.6 => > /lib64/libreadline.so.6 for me on Pure64.
That's what I'd expect... > What I assume was happening was that Bash was looking in /lib64 for > Readline, and copied the symlink over to /lib64, > but the library to /lib, confusing the linker and causing a kernel panic. mkinitramfs does not preserve the symlink. If ldd reported /lib64/libreadline.so.6, then mkinitramfs should have generated a line like so: file /lib64/libreadline.so.6 /lib64/libreadline.so.6 0755 0 0 which *should* (or at least, does for me) cause gen_init_cpio to copy the contents of the target file. The soname symlinks are not required inside the initramfs because there's no point in upgrading the libraries in one; as long as the filename exists, though, everything should work. Which comes back to the other issue, I guess. Have to see what the script is putting into the cpio archive. (Or actually, maybe hacking on the script to dump what it echos into a temp file instead of into gen_init_cpio's stdin, would work better.) Unless somehow gen_init_cpio started preserving symlinks, but that seems even more strange...
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/hints FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
