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-supp...@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
