Troubleshooting boot issues
(recategorize) |
|||
(One intermediate revision not shown) | |||
Line 1: | Line 1: | ||
+ | {{out of date}} | ||
+ | |||
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 58: | Line 60: | ||
And finally, file [http://bugs.maemo.org bugs] against the problem applications! | And finally, file [http://bugs.maemo.org bugs] against the problem applications! | ||
- | + | [[Category:N8x0]] | |
- | [[Category: | + | [[Category:Power users]] |
Latest revision as of 10:29, 7 December 2010
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!
- This page was last modified on 7 December 2010, at 10:29.
- This page has been accessed 20,723 times.