To boot or to Chroot.

Robert Baker RBaker at newpark.com
Thu Apr 30 14:49:08 PDT 2009


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




More information about the hlfs-dev mailing list