Troubleshooting boot issues
m (Categorization) |
(Cleanup and markup, still needs help) |
||
| Line 1: | Line 1: | ||
| - | |||
| - | |||
You'll need bootmenu [http://fanoush.wz.cz/maemo/#initfs] with a telnet or ssh server installed. I'll suppose that a telnet server is used: | You'll need bootmenu [http://fanoush.wz.cz/maemo/#initfs] with a telnet or ssh server installed. I'll suppose that a telnet server is used: | ||
| Line 36: | Line 34: | ||
Don't forget that the watchdog will reboot the machine after a some time. | Don't forget that the watchdog will reboot the machine after a some time. | ||
| + | |||
| + | == Reporting reboot issues == | ||
| + | |||
| + | When reporting strange booting/rebooting issues here is a list of information that is helpful in debugging: | ||
| + | |||
| + | * Output of <code>/proc/bootreason</code> | ||
| + | * Output of <code>/var/lib/dsme/stats/lifeguard_resets</code> | ||
| + | * 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 | ||
| + | * <code>dmesg</code> after a successful boot. This will show whether the OOM (out of memory) killer is reaping processes. | ||
| + | |||
| + | <code>/proc/bootreason</code> 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 <code>cat</code> to get the contents of a particular file. | ||
| + | |||
| + | You can create a <code>core-dumps</code> directory on the internal flash card, then crashing applications will leave core files in it. Use <code>file core.*</code> to find out the name of the crashed application. In theory, you can use <code>gdb</code> to get the stack trace, but without debug symbols it wont be any use. If you copy <code>*.core</code> files to your Linux PC you can use <code>gdb</code> see what program crashed, use <code>gdp -core core.xxxx</code> where <code>xxxx</code> is the number of the file. | ||
| + | |||
| + | And finally, file [http://bugs.maemo.org bugs] against the problem applications! | ||
[[Category:Users]] | [[Category:Users]] | ||
| + | [[Category:Development]] | ||
Revision as of 07:38, 19 April 2009
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.
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
-
dmesgafter 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!