Help - Search - Members - Calendar
Full Version: Gui Bails Almost Immediately - C860 / R121
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > pdaXrom
g33k
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?
InSearchOf
Did you check your MD5 checksum before burning that image to NAND?

Seems like there was a hickup... pre/during/post flash...

Late
g33k
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?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.