On Sun, Jul 01, 2012 at 01:16:00PM +0530, Emerson Yesupatham wrote: > Hi Andy and All, > > As discussed in below mail, I have now installed latest linux distribution > in my Host computer to have newer kernel. The installed linux version > details are as follows: > > #cat /proc/version > Linux version 2.6.35.6-45.fc14.i686 (mockbu...@x86-16.phx2.fedoraproject.org) > (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Mon Oct 18 > 23:56:17 UTC 2010 > # uname -a > Linux cag73 2.6.35.6-45.fc14.i686 #1 SMP Mon Oct 18 23:56:17 UTC 2010 i686 > i686 i386 GNU/Linux > # uname -r > 2.6.35.6-45.fc14.i686 > > in the glibc configuration (--enable-kernel) option do I need to give > --enable-kernel=2.6.35 or --enable-kernel=$(uname -r) ? kindly advice. > First, a moan : doan't top post (since not everyone understands what that means, see e.g. http://catb.org/jargon/html/T/top-post.html )
and ALWAYS trim what you are replying to if it is the digest : server bandwidth, as well as the bandwidth of some people who read the list, isn't always free - you pulled in several hundred lines of postings. An now, to answer your question. If this is your first build of LFS, I'm tempted to say FBBG (Follow Book, Book Good). So, that would be --enable-kernel=2.6.25 (I'm looking at LFS-svn but I don't think we've changed that part since 7.1. Oh, wait, for some reason you are using 7.0 [ checks ... nope, still 2.6.25 ] ). But to be honest, that is a very old and unsupported version of the kernel [ http://www.kernel.org ]. The more you add in features for old versions of the kernel, the more cruft is built into glibc for compatability. If you are never going to boot a kernel older than 2.6.35, specifying 2.6.35 should be fine. For my own desktop builds (several each year, using LFS-svn) I reduce the cruft by using the current kernel and (typically) I enable that version - the actual details of what has changed are in glibc's sysdeps/unix/sysv/linux/kernel-features.h. OTOH, for recent kernels there is not a lot of change in the features and modern disks and physical memory are usually big. I *have* been caught out in the last year - moved my existing desktops to new machines, so I had to build new kernels : I used SystemRescueCD to chroot and do that, but the version I was using was compiled for linux-3.0, so my binaries for 3.2 weren't usable. I had to install an older LFS system to get it to chroot. After that, of course, I could boot to the older system, chroot to the current system. build a kernel for that, and then boot the current system and use that to build a fresh one. It's always good to know what the upgrade / rescue path is :) ĸen (hmm, lost my .sig - no matter, this is long enough) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page