Booting into x86_64
ken at linuxfromscratch.org
Thu Nov 17 12:11:17 PST 2005
(adding the list back as a Cc)
On Thu, 17 Nov 2005, jstipins at umich.edu wrote:
> Quoting Ken Moffat <ken at linuxfromscratch.org>:
>> 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).
> 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
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 184.108.40.206
> based. (My current working LFS distribution is running 220.127.116.11.) I can't
> seem to build kernel 18.104.22.168 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
> 22.214.171.124, 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
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, 126.96.36.199 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
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
das eine Mal als Tragödie, das andere Mal als Farce
More information about the cross-lfs