William Immendorf wrote: > On Mon, Mar 28, 2011 at 2:00 AM, Bryan Kadzban > <br...@kadzban.is-a-geek.net> wrote: >> Which library wasn't found? Where did the various files involved go, >> when they were put into the cpio archive? > /lib64/libreadline.so.6, when Bash was executed. This caused a stack > trace and a kernel panic because the kernel can't find the RootFS.
Inside the initramfs?
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...)
If what I think is the problem is actually the problem, then I think the
pure64 setup is broken. But it depends on what ldd actually said, and
where various files got put.
>>> The way to fix this is to first check if /lib64 is a symlink, or if
>>> it is a directory, and behave appropriately.
>> What's "appropriately" in this context? I don't think it's doing
>> anything wrong, but please explain what it should be doing. :-)
> Something like this:
>
> {{{
> if [ -h /lib64 ]; then
> # Create /lib64 as a symlink to /lib (Pure64)
> elif [ -d /lib64 ]; then
> # Create /lib64 as a directory (Multilib)
> fi
> }}}
Yes, obviously. But what do you want me to do in the place of the
comments? That's the part where because I don't understand what's
wrong, I don't know what to do.
>> If you can reproduce the error at this point (after udev has started, in
>> a manual run), what's in /dev compared to /etc/fstab for the rootfs?
> I'll try this setup again. What I'll do is I'll use LFS 6.8 with
> kernel 2.6.38.2 (or greater minor version number), with the grsecurity
> patch,
Eh? Why complicate things?
> and see how it goes. If I run into that error, I'll be sure to
> use init=/bin/bash at the GRUB menu, and report what I find.
Please do.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/hints FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
