Re: lfs-initramfs problems
William Immendorf wrote:
I'll just add this before the gen_init_cpio call:
{{{
tee /tmp/lfs-initramfs-filelist
}}}
Does that work?
Should be fine, yeah.
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/hints
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: lfs-initramfs problems
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.
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.
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.
This:
{{{
if [ -h /lib64 ]; then
echo slink /lib64 /lib 0777 0 0
elif [ -d /lib64 ]; then
echo dir /lib64 0755 0 0
fi
}}}
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?
I've been running it with Grsecurity with 2.6.37.4 and it has been
working for me (untill I unintentionally trashed
my LFS system by trying to move the shared library files of iptables
by rm /lib/*.so and then ln -sfv ../../lib/{lib}.so.x
/usr/lib/{lib}.so,
only to wipe out the files for Glibc as well, making nothing work, and
requiring a reformat and a rethink)
I'll do it again, unless you say I should not.
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.
Will do. Thanks.
--
William Immendorf
The ultimate in free computing.
Messages in plain text, please, no HTML.
GPG key ID: 1697BE98
If it's not signed, it's not from me.
--
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
--
http://linuxfromscratch.org/mailman/listinfo/hints
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: lfs-initramfs problems
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
Re: lfs-initramfs problems
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.
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
}}}
When the bootscripts attempt to mount the root filesystem, it can't
find it, even through the initramfs could.
If I had to guess, I'd say something is wrong with udev. What udev
version, and what kernel? What happens if you boot with init=/bin/bash
and run each bootscript manually in the proper order, from the resulting
shell? (Specifically, what happens during the checkfs and mountfs
script runs? Exact error?)
This was a while ago, but the problem started happening when I tried
to build 6.7 with both this hint and the pkgusr hint. I diddn't use
init=/bin/bash, but maybe I should. I discovered this hint when I was
building LFS 6.6, and I decided to try the hint. I don't remember what
LVM version I used, but it was the latest at the time of build. The
bootscripts failed because it can't find the swap file, which was on
the LVM, and failed again when it couldn’t find the root disk on the
LVM as well. I used several different, apparently valid paths, and
even created a script that runs vgchange -ay lfs at boot time, and it
still didn’t work.
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, 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.
--
William Immendorf
The ultimate in free computing.
Messages in plain text, please, no HTML.
GPG key ID: 1697BE98
If it's not signed, it's not from me.
--
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
--
http://linuxfromscratch.org/mailman/listinfo/hints
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
