Thanks for this hint.

I ran the init=/bin/sh scenario on my rev 1161, rev 1482, and rev 1489 builds.

The 1161 build did what was expected, ending up in sh...

Freeing init memory: 60K
/bin/sh: can't access tty; job control turned off

The 1482 build, which had the default LCD display selected (option 2) in the configuration, ended up hanging with an error displayed (ignore my printk traces on init_post)...

Freeing init memory: 120K                                                      
init_post returns from free_initmem                                            
init_post returns from unlock_kernel                                           
init_post returns from mark_rodata_ro                                          
init_post returns from numa_default_policy                                     
Warning: unable to open an initial console.                                    
init_post returns from sys_dups                                                
init_post returns from run_init_process                                        
init_post enters execute_command                                               

The 1489 build, which had the Gumstix standard LCD display selected (option 3) in the configuration, ended up hanging with no error...

Freeing init memory: 120K

So, there's a chance that all this init hanging has to do with the LCD panel configuration (which doesn't have an option for "none of above").  Note that my hardware set-up doesn't have any of the LCD configuration choices, since it uses the Sony mini-panel (which shouldn't be the console anyway).

Where do I go from here?  It looks like /sbin/init (part of busybox) is simply not attached to any terminal.

Thanks again.

On 8/1/07, Craig Hughes <craig@gumstix.com> wrote:
On Aug 1, 2007, at 1:29 PM, Peter Lu wrote:

> Hi,
> Thanks for the info.  I had done "mv root root.old; mkdir root" and
> should have just skipped the mkdir.  My system is still not doing /
> sbin/init properly and  all the "experiments" I'm doing to  attempt
> to correct  things are just digging me into deeper and irrelevant
> holes inadvertently (although I'm learning to avoid pilot errors).
> I really need to trace what /sbin/init is doing (wrong).  I just
> built rev 1489 with a bare-bone .config and it still won't run.

Have you tried going into u-boot and (temporarily) setting bootargs
like this:

GUM> setenv bootargs $bootargs init=/bin/sh
GUM> bootd

... wait for linux to start and dump you to shell prompt.  Then when
you get the shell prompt, manually run the stuff in /etc/inittab one
command at a time and see where things go bad.


This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
gumstix-users mailing list