To boot or to Chroot.
RBaker at newpark.com
Fri May 1 14:22:34 PDT 2009
First off sorry for the lack of word wrapping on the last mail. I hate Outlook...
Anyhow I just wanted to post back up with a few more of my experiences.
First when it comes to keeping / as pristine as possible I did realize that a
good deal of the directory structure needs to be in place for the boot process.
I am guessing that this isn't an issue because we will be setting up those
Directories right after the reboot anyway. Of course there are several symlinks
that we will need to throw into /bin, and /sbin. Some because of hard coding in
sources, and others because of init scripts. I would rather do symlinks than edit
the scripts if that's acceptable.
Second it appears that Udev-137 has some problems. It was failing to create
device nodes for me. I went back to Udev-124 because I knew it was in working
order(CLFS uses this version). I built this, and as I discussed yesterday I
also rebuilt Util-linux using the --enable-login-utils. After dealing with those
two packages I got to a logon prompt, but was still unable to login. I am still
trudging through that problem, but I thought it was worth mentioning the Udev
issues. I am going to try newer versions of Udev to see when/where the problem
was introduced. More on that later.
From: hlfs-dev-bounces at linuxfromscratch.org [mailto:hlfs-dev-bounces at linuxfromscratch.org] On Behalf Of Robert Baker
Sent: Thursday, April 30, 2009 4:49 PM
To: hlfs-dev at linuxfromscratch.org
Subject: To boot or to Chroot.
I went ahead and pulled down a copy of Onward as it stood on Friday last week,
and compiled through the temporary system with only one notable issue. Evidently
something in the Grsec patch for linux-184.108.40.206 is not happy with changes in
arch/i386/lib/usercopy.c in 220.127.116.11. Using 18.104.22.168 in 22.214.171.124s place worked
fine. Considering the temporary system only deals with setting up /tools, and
not actually making the system bootable I took CLFS' lead.
Using the instructions in CLFS to build a bootable temporary system I was able
to reboot into our limited install. Of course following those directions I did
end up recompiling udev, sysvinit, etc in accordance with their directions.
Obviously this method forces creating the directory structure as well as installs
a few packages to /usr. I agree this is not an ideal solution, and at the most I
would prefer installing to tools, and symlinking important bits. This would make
checking for lingering pieces of the temporary system much easier because anything
outside of /tools would have been setup manually, and can then be looked at easily.
I did try to create a self contained /tools temporary system, but I hit some snags.
It wasn't until I ran through the CLFS method that I found what I think created my
problem. On the configure pass of Util-linux CLFS uses an additional switch
--enable-login-utils. I was able to get the self contained system to boot, but could
never login, and I think that switch is what I was missing. It is my intention to
run back through making my /tools bootable, and see if that solves my issue. I will
post up when I have an answer to that.
As for the question of whether or not to reboot I suppose that is largely dependent
upon the host distro. I personally have learned the hard way that I need to build
from a known good starting point. Because of that I do my builds using the LFS live
cd, and that doesn't have the capabilities module installed. Still taking a chroot,
or boot approach the way CLFS has their doc structured sounds like a decent idea
that way there are options.
As an aside the CLFS boot scripts using minimal install work great, and we likely
only need to perform a small sed to get the rc path the way we need it.
One last thing. Once I got my system up and running I installed linux-headers,
man-pages, and started trying to build glibc. Unfortunately glibc's configure script
configure: error: Need linker with .init_array/.fini_array support.
Digging through the config.log leads me to believe that the test it fails is failing
because of -fstack-protector-all
It appears CLFS user Carsten Clever ran into something similar a couple years back:
This user said the compile worked if they did not use -fstack-protector-all or
I'm not sure where the breakdown is, and it very well might have come up when I
followed CLFS chapter 7's path. More on this once I get to a self contained bootable
Unsubscribe: See the above information page
More information about the hlfs-dev