[Clfs-support] boot process hangs on init.

[Andy Kennedy]

NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing init memory: 72K
INIT: version 2.86 booting
  Vendor: CBM       Model: Flash Disk        Rev: 5.00
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 2067968 512-byte hdwr sectors (1059 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
SCSI device sda: 2067968 512-byte hdwr sectors (1059 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
 sda: sda1

Book:  CLFS-Sysroot-SVN-0.0.1-20080121
HOST:  x86 Slackware 12.0 install (Glibc 2.6)
Target: Arm XScale

As seen from the above, the Linux kernel continues to control the 
system, however, INIT never does anything other than the one printf().  
I have attempted this several different ways so far. 

One way I attempted this was to build a static BusyBox (linked against 
uClibC) to get mount, ls, cp, and a very few other utilities.  Next, I 
allow my old system to boot into the 2.3.2 Glibc system.  I then use NFS 
to attach the freshly built CLFS to the target (via the mount command 
which is the static BusyBox).  I connect in and can busybox ls /usr /bin 
/sbin /lib and see all the files I expect.  Next, however, I do a ls and 
I hang, just like on the init.

Thinking that the dynamic linker just didn't get re-homed correctly, I 
attempted to build the system to boot off of USB, which I did and booted 
into the system.  init hangs.

Thinking that I was doing something sloppy with the USB, I carefully 
built a 32MB jffs2 image (/usr would be via USB device) and attempted to 
bring up the system that way.  Again, no luck and init only hangs.

Thinking that the init had some issues with it I built BusyBox 1.9.1, 
dynamically linking it to the sysrooted Glibc.  Same thing.  However, 
when I statically linked BusyBox with the Glibc (not following the full 
instructions from the BusyBox build -- I didn't have to removed the gcc 
switches, just the #error from within the one file) I was able to get 
BusyBox to start.  The inittab was extremely off for this version of 
BusyBox, therefore I was unable to see anything other than /dev/**** was 
not found (**** was a continuous loop of l0-l9 S0, etc).  This may have 
meant that I may have been able to get that one to run.  But the bottom 
line question still remains:

Why can I not get a dynamically linked program to run under the 
cross-compile system?

Any light you can shed on this would be greatly appreciated.
Andy