 Gui Bails Almost Immediately - C860 / R121 |
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > pdaXrom  |
 Oct 20 2006, 07:14 AM
Post
#1
|
|
|
Group: Members Posts: 59 Joined: 25-October 04 Member No.: 5,208  |
I've just done a fresh install of 1.1.0r121 - both uboot and the system itself - on my C860. Everything seemed to go well - very smooth. Eventually, the system starts and I login as root. I run startx and get the touchscreen calibration screen as expected.
Then x starts. The screen is initially rotated as if my clamshell was in portrait mode, which it isn't. As the display gets almost fully drawn - the toolbar is complete but the wallpaper and icons aren't loaded yet - the screen flashes and switches to landscape mode. The screen is drawn to the same point - toolbar but no icons or wallpaper - then I'm dumped back out to the command prompt. I see: CODE # startx Jan 1 00:02:42 sudo: root : TTY=vc/1; PWD=/home/root; =/sbin/modprobe mousedev Jan 1 00:02:43 input.agent[1082]: ... no modules for INPUT Removing empty element from the valid list of fontpaths Shutting down switchevd: Jan 1 00:02:46 switchev: switchevd Starting switchevd: Jan 1 00:02:47 switchev: Starting swit pdaXrom [Husky] Removing empty element from the valid list of fontpaths This output is truncated - I guess by the switch from one screen mode to another - and I don't know how to see the full output. The above is just as it appears on my screen. If I startx again at this point, everything goes exactly the same, except the "... no modules for INPUT" line is omitted. I see that line only once per boot. The behavior is the same whether my clamshel is in portrait or landscape mode. Can anyone give me any suggestions? |
 |
 
|
|
Oct 20 2006, 07:30 AM
Post
#2
|
|
 Group: Admin Posts: 1,208 Joined: 20-January 06 From: York, Pennsylvania Member No.: 8,961 |
Did you check your MD5 checksum before burning that image to NAND?
Seems like there was a hickup... pre/during/post flash... Late |
|
|
|
|
Oct 20 2006, 09:39 AM
Post
#3
|
|
|
Group: Members Posts: 59 Joined: 25-October 04 Member No.: 5,208 |
QUOTE(InSearchOf @ Oct 20 2006, 03:30 PM) Did you check your MD5 checksum before burning that image to NAND? No, I didn't - but I have now done so and they check out. I've just tried reflashing the kernel and root filesystem image, and - with horror - I think I see the problem. Once the emergency system started "writing data to block[s]," I got an I/O error. It rebooted before I could read the whole thing, but it said something about how the file didn't fit due to bad blocks! So - I restarted the whole process, and it went without incident the second time around. And it booted into the GUI just fine! Is my NAND dying? Is this simply a bug or a glitch? |
|
|
|
|
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:
|
Lo-Fi Version | Time is now: 20th May 2013 - 06:29 PM |