To boot or to Chroot.

[Robert Baker]

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.

Robert Baker


-----Original Message-----
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-2.6.27.10 is not happy with changes in 
arch/i386/lib/usercopy.c in 2.6.27.20. Using 2.6.27.10 in 2.6.27.20s 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 
complains:

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:
http://www.mail-archive.com/clfs-support@lists.cross-lfs.org/msg00792.html
This user said the compile worked if they did not use -fstack-protector-all or 
-nostdlib. 

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 
temporary system...

Robert Baker

-- 
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page