CDROM Boot Initrd Problem

Charles Meier cmeier at peerpro.net
Tue Nov 9 05:34:33 PST 2004


Thomas Hackert wrote:
 > Hello Charles,
 > On Tuesday 09 November 2004 04:56, Charles Meier wrote:
 >
 >>System is an LFS 5.1 w/ Linux 2.6.8.1.  I've created a boot CD
 >>using lilo and BusyBox.  This boots easily on the machine where
 >>the LFS was built.  This box is a dual PIII.  The CD also boots
 >>on a Dell PIII laptop.  But the CD refuses to boot on my older
 >>boxs -- one w/ a K6/300 (mail server) and the other with a
 >
 > you should search the archives/hints for the cross-compiling hint.
 > You have build your boot CD on an x686, therefore it boots on you
 > Dell laptop, but not on your K6/300. Here you need a bootable CD
 > for x586 (I think).
 >
 >>PII/200 (replacement firewall/router).  On those machines, the
 >
 > Here you need a bootable CD for x386.
 >
 >>kernel boots as far as the "Freeing unused kernel memory" message
 >>and then appears to hang w/ no further msgs.  This is the point
 >>where /linuxrc should kick in, but no dice.
 >
 > This happens because you have compiled your LFS system for the wrong
 > architecture (is this the right terminology in english?).
 >

OK, that leads to some further questions.  I have built many
binaries in the past on the PIII using GNU's configure and
then copied the results over to the K6 and PII and they just work.
There was no need to modify uname or install a kernel module
to fool gcc into believing I was running the system on a lower
stepping processor or give a -march/-mcpu option.  Further, the LFS
instructions for glibc explicitly say NOT to add any options for
processor type:

  This package is known to behave badly when you change its default
  optimization flags (including the -march and -mcpu options). Therefore,
  if you have defined any environment variables that override default
  optimizations, such as CFLAGS and CXXFLAGS, we recommend un-setting
  them when building Glibc.

And from the gcc manual:

  -mcpu=cpu-type
     Tune to cpu-type everything applicable about the generated code,
     except for the ABI and the set of available instructions. The choices
     for cpu-type are i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro,
     pentium2, pentium3, pentium4, prescott, nocona, k6, k6-2, k6-3, athlon,
     athlon-tbird, athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3.

     While picking a specific cpu-type will schedule things appropriately for
     that particular chip, the compiler will not generate any code that does not
     run on the i386 without the -march=cpu-type option being used. i586 is
     equivalent to pentium and i686 is equivalent to pentiumpro. k6 and athlon
     are the AMD chips as opposed to the Intel ones.

   -march=cpu-type
     Generate instructions for the machine type cpu-type. The choices for cpu-type
     are the same as for -mcpu. Moreover, specifying -march=cpu-type implies
     -mcpu=cpu-type.

All of the above implies to me that the default for both gcc and LFS is to
generate vanilla i386 code UNLESS -mcpu or -march is explicitly requested.

 > I think, you should search http://search.linuxfromscratch.org for
 > the uname hack. This seemed to be a solution in the past ... ;)
 >

 > Thomas.

My LFS was built as a pure vanilla system w/ no options for -mcpu or -march.
Why is a uname hack necessary?

cmeier




More information about the lfs-support mailing list