• Intro
• Downloads
• Community
• Development
• News
• TALK

Troubleshooting boot issues

This article is out-of-date, and needs to be updated. Please see the talk page for discussion.

You'll need bootmenu [1] with a telnet or ssh server installed. I'll suppose that a telnet server is used:

• Boot Nxx0 and start the telnet/ssh server
• Connect USB cable to PC
• In your Linux PC run:

modprobe usbnet
ifconfig usb0 up
ip addr add dev usb0 192.168.10.2/24
telnet 192.168.10.1

(where 192.168.10.1 is the IP address of the Nxx0 device and 192.168.10.2 is an IP address in the same subnet to be used by your PC)

• You're now connected. Load required modules for accessing your root partition (not all of them are required):

insmod /lib/modules/2.6.21-omap1/jbd.ko 
insmod /lib/modules/2.6.21-omap1/mbcache.ko 
insmod /lib/modules/2.6.21-omap1/ext2.ko 
insmod /lib/modules/2.6.21-omap1/ext3.ko

• And mount the root partition (suppose it is /dev/mmcblk0p2):

mount /dev/mmcblk0p2 /mnt/new_root -t ext3 -o noatime

• Now run:

cd /mnt/new_root
mount -obind /tmp /mnt/new_root/tmp
pivot_root . mnt/initfs

export OSSO_VERSION=$(cat /etc/osso_software_version)

• And you're ready to manually boot it:

cd /etc/init.d
./rcS
./rc 2

This will do the whole bootup procedure (not exactly, but the interresting part) and you'll be able to watch all bootup messages.

Don't forget that the watchdog will reboot the machine after a some time.

[edit] Reporting reboot issues

When reporting strange booting/rebooting issues here is a list of information that is helpful in debugging:

• Output of /proc/bootreason
• Output of /var/lib/dsme/stats/lifeguard_resets
• Application running when the reboot occurred
• State of device - idle with cover, idle without cover, turned off, in use, etc.
• Mode of device - R&D or production mode
• dmesg after a successful boot. This will show whether the OOM (out of memory) killer is reaping processes.

/proc/bootreason can have the following values:

pwr_key 	Power key was pressed to switch on device
32wd_to 	Watchdog reset - something was consuming too much CPU causing a watchdog reset, or kernel crashed
sw_rst 	Software reset (critical system application crashing or being killed by the kernel OOM-killer)
rtc_alarm 	An alarm woke up the device

You need to install XTerm or SSH to get a console. Then use cat to get the contents of a particular file.

You can create a core-dumps directory on the internal flash card, then crashing applications will leave core files in it. Use file core.* to find out the name of the crashed application. In theory, you can use gdb to get the stack trace, but without debug symbols it wont be any use. If you copy *.core files to your Linux PC you can use gdb see what program crashed, use gdp -core core.xxxx where xxxx is the number of the file.

And finally, file bugs against the problem applications!