Booting into x86_64

Ken Moffat ken at
Thu Nov 17 12:11:17 PST 2005

(adding the list back as a Cc)

On Thu, 17 Nov 2005, jstipins at wrote:

> Quoting Ken Moffat <ken at>:
>>  Just like vanilla LFS, I'm guessing there is something unfortunate in your 
>> .config.  This is probably your first attempt to run x86_64, and therefore 
>> you are now ready to build chapter 9 (tcl and so forth) ? (If you'd already 
>> finished the system, you could revert to the 64-bit .config you used when 
>> you were building it)
>>   Are you following the 'boot' or 'chroot' option ?  If you boot, you 
>> should point the init= to wherever you installed the /tools files.  If you 
>> chroot, you should point init= to the (32-bit) system containing /sbin/init 
>> (and also make sure the kernel can emulate 32-bit in the .config).
>> Ken
> Hi, thanks for the responses.
> It is in fact my first attempt to run x86_64.  My current kernel cannot
> run 64-bit executables, so my understanding is that my only option is to
> 'boot'.

  x86_64, powerpc64, and maybe other arches, will let a 64-bit kernel run 
a 32-bit userspace, and successfully chroot to a 64-bit system.  But, 
trying to install modules in that situation is not recommended.

  However, if you've built everything necessary to boot, you should be 
good to go.

>  I agree with you that GRUB has done its job by the time I run
> into trouble.  It looks like there's some problem with the device driver
> for my Maxtor 6L200M0, which is a SATA drive.
> What I'm especially confused about is that the failure mode changes,
> depending on whether or not the kernel is compiled with support for 32-bit
> executables.  I haven't done enough experimenting to be 100% certain of
> this, but it seems like what is happening is as follows:
> 1. With 32-bit support, I get the register dump that contains some "scsi_..."
>  symbols (don't have them handy right now, sorry).
  Odd, but x86_64 is still new enough to have a few strangenesses.  If 
this is indeed an oops, all bets are off for what happens afterwards.

> 2. Without 32-bit support, there is no register dump; rather, I just get
>  an error from VFS that it is unable to mount the root device.

  In other words, either you haven't included the necessary driver, or 
it hasn't been loaded by modprobe.

> Does any of this make sense?  That is, is there any reason why support for
> 32-bit executables should have any effect on the loading of a device driver?

  No obvious reason.  My advice is to change your config.  Go through 
menuconfig, build in all the filesystems you use, your network card, and 
all the DMA and SATA options that might be relevant to your hardware. 
Take out anything that looks unnecessary.  Also, take out support for 
32-bit apps temporarily.  Build in the correct SATA drivers for your 
chipset under the SCSI drivers.

  Build, see if it boots, repeat.  When it boots, add in the 32-bit 
option.  If it then oopses, you've identified a bug.  The important 
thing is to reduce the variables in the problem to a manageable level.

> Right now, I'm not sure if the problem is 64-bit based, or kernel
> based.  (My current working LFS distribution is running  I can't
> seem to build kernel with my current toolchain, so I can't easily
> test whether the new kernel would cause a problem in pure 32-bit mode.  It
> occurred to me that I could try updating to the "development" LFS that uses
>, and see if I can boot that (again, all 32-bit).  Unfortunately, I
> get errors in "make check" on glibc-2.3.6 and gcc-4.0.2, so I abandoned that
> idea.
  I worry about your 32-bit toolchain, or the .config, but that is 
getting O/T for cross-lfs.  Remember, the kernel config options for 
x86_64 and i686 are very different, so problems in one dont necessarily 
appear in the other.

  For me, has been reliable on my limited range of x86_64 
hardware.  OTOH, building non-modular 64-bit kernels for newer versions 
has been problematic (a .config problem, they take for ever to boot - 
the modular versions are absolutely fine).

  If you have excessively new hardware, you might require a newer kernel 
(e.g. for PCI-E), but that is probably also true for 32-bit.  Otherwise 
a newer kernel just throws more variables into the equation (once you 
identify a kernel problem, obviously you need to try newer kernels to 
see if it has been fixed).

> I have a huge hard drive, and lots of time... any suggestions for plans of
> attack?
> Thanks,
> -Janis
  If you are sure what your hardware contains (lspci?), slimming down the 
kernel config is probably the quickest method: typically, 3 or 4 
recompiles per hour, more on fast hardware.

  You could, at a pinch, install a 64-bit distro onto a spare partition 
and see which modules it loads (plus, fixing up grub from a rescue disk 
if the current options disappear), but that will take significant time 
to download.

  das eine Mal als Tragödie, das andere Mal als Farce

More information about the cross-lfs mailing list