[Clfs-support] boot process hangs on init.

[Andy Kennedy]

Andy Kennedy wrote:
> 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
> _______________________________________________
> Clfs-support mailing list
> Clfs-support at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
>
>
>   
To provide more information about this issue, I just reinstalled the 
CLFS system to a USB stick and attempted to chroot into it. . . survey says:
root at ACAMS_ ~# chroot /jumpdrive
Segmentation fault
which leads me to believe that I have a bad build on the native Glibc?  
Using the cross-tools as the clfs user, I can statically compile a hello 
world, but I have no library to link to to attempt a dynamic version.

Again, any help will be greatly appreciated.

Andy