Minimum Host Prerequisites

Bryan Kadzban bryan at
Mon Oct 20 21:41:30 PDT 2008

Hash: RIPEMD160

Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> Ken Moffat wrote:
>>> but also I think we should encourage 
>>> people to build a new kernel first (if they aren't using a Live CD) 
>>> so that they can be sure it works with their .config, and then they 
>>> can use --enable-kernel=current.
>> Hmm.  I wouldn't want to set it any higher than the minimum required on
>> the host, which I believe is determined currently by the process to
>> generate udev NIC names?  Though the actual page only says "2.6.x", hmm.
>> I *think* the udev process required 2.6.8 or newer to work at all, and
>> 2.6.18 for some kind of enhancement (comments perhaps?).  I wonder if we
>> need to set it at least that high.
> Perhaps I'm not understanding your point. Certainly 
> --enable-kernel=current would cover that very circumstance?

My point was not very well made.  It's two-fold.

First, I'd rather not use =current, just because we (could) end up
building a different glibc on every different kernel that way.  If we
pick a given version string and use it, then building on any given
kernel should yield the same glibc binary.  Forcing the user to build a
newer kernel (of a fixed version) before starting the book would help
with this, but I'll hold off on that until the end.

Second, if we choose something for --enable-kernel that's newer than
2.6.0, then I don't want to set it any higher than what the host system
pre-reqs page says.  (Otherwise someone will start a build, get to
chapter 6, and not be able to run some tool because chapter 5's glibc
was built for a kernel that's too new.)  And I see that the  page in
question simply says 2.6.x; this should be made more specific.

I then remembered some kernel version requirements of the udev
network-device hack (2.6.8); I suspect the minimum host kernel version
is that one.  Though it may be newer, I don't know for sure.

So we could use 2.6.8 for --enable-kernel=, and update the prereqs page
to match.  Or we could leave it at 2.6.0 and update the prereqs page
anyway (at least for 6.4).

(That's assuming my understanding of the flag is correct.  I believe
that setting it to something too old will add some extra compatibility
code, but setting it to something too new will cause program breakage.
Using the current kernel would work, if we could assume that after a
reboot, the same (or newer) kernel will be in use.  I'm not willing to
make that assumption, given the backward-version breakage that RH and
friends have caused in the past with stuff like binutils.)

Forcing the user to build the kernel before they start may work, but I'm
not entirely sure I want to change things that much right now.  Maybe
for 7.0?  (Actually it may cause grief with the installed distro's udev
system, especially if the wrong CONFIG_ compatibility sysfs flags get
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the lfs-dev mailing list