Natty borks on modern and supported hardware badly

Did you MD5 test the ISO you downloaded?
If you used a CD, did you burn the CD as slowly as possible? Did you check the CD for defects?
Did you test your RAM?

The last paragraph is of zero value to the question. Please leave fluff like that out and stick to the facts and details.

Thanks

network manager comes with nm-cli where you can configure networking in CLI, the average user (Think about the target audience of Ubuntu) would be put off by this so network manager (and similar) exists. wicd has a GUI interface but also has a curses UI which can setup networks beautifully

I did not MD5 test the CD, which I did not download. As I said, I'm using the physical desktop CD (produced by Canonical) handed out at UDS. I have two of them, and the results are identical for both.

I have run RAM tests without any difficulty.

I'm sorry for my intemperate paragraph. Paper cuts hurt a lot, that's all.

Phoronix reported that Clarkdale works a year ago.
http://www.phoronix.com/scan.php?page=article&item=intel_clarkdale_gpu&num=1

Then you should still check the CD for defects, CD burners are far from perfect.

Once again, this CD was not "burnt". It is the pressed CD, manufactured by Canonical, and both CDs have the same problem. If you can propose the correct method to check this CD for defects, I'd be glad to do so.

When you see the stick man screen, press SPACE and you can test your RAM as well as the CD.

As expected, Canonical's CDs are just fine. (Really, please, CD fabrication is not that error prone. CD *burning* is moderately error prone, but these seem to be ordinary real pressed CDs.)

So can we return to the software problems please? Shibboleth!

By the way, the existence of nmcli is not helpful. It is not a replacement for nm-applet; my statement remains correct. nmcli is not able to do such things as bring up wireless with a password. It remains that the graphical installer is a disaster in cases where X fails--like mine--because too much of the system relies on graphics working to get anywhere.

Did you test the CD for defects and did you test your RAM?

Turning off quiet and splash shows that the exciting color flashy thing (when not using nomodeset) happens when drm is being set up by the kernel. (It is not surprising that this is the case.)

"Did you test the CD for defects and did you test your RAM?"

I have the suspicion that you simply repeat this for all ubiquity problems without actually reading the question. I have that suspicion because, if you had read the question, you would find that I said, "I have run RAM tests without any difficulty."

And, despite my saying that I had CDs from Canonical which I picked up at the recent Budapest UDS, you thought I burned them.

And, before asking this again, I had said, "I have run RAM tests without any difficulty."

So, yes, once again, I have run ram tests. I have run the cd test. They are fine.

If you get karma for this, it's an insane system. You're cluttering the log at this point.

Good, testing the media and RAM is great for diagnosing issues as they will directly affect the installation. I can only suggest you try boot options available in the F6 menu of the screen you ran the RAM test from (disable things like ACPI and APIC can help, or force vesa video driver for the duration of the install and such). These can also help.

I simply iterated the question as I asked the question and you started discussing nmcli, which doesn't flow. I may not have seen it in the initial question but it was an honest mistake so I sought further clarification.

The problem is that X is crashing opening mtdev. If you aren't able to help with that, can you escalate the question to someone who can?

I think the Answers system is likely to continue to be useless for this
kind of thing; you need a kernel or X developer (I'm not sure which),
and none of those are reading. All too often, Answers is too much of a
first-line support system, without enough willingness to escalate.

I'd suggest raising a bug on the xorg package in Ubuntu as the first
instance; if you can manage to get the system working with wireless for
long enough to run 'ubuntu-bug xorg' on that system, that would be best,
but if not, then
https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20when%20off-line
has advice on gathering information which can then be attached using
ubuntu-bug from a working system.

Thanks Colin; that's very helpful. I have done some more debugging, and I sent a few initial messages to some of the people involved with the mtdev/evdev code and also to the ubiquity team list. They're awaiting moderation. My concern is this:

Suppose we find that the fix is
1) Using a custom xorg.conf,
2) Patching evdev or mtdev, or
3) Getting something from natty-updates.

What does that mean for installation? Using the install CD, I'm pretty helpless, because there doesn't seem to be any way to say "make this change, and then let the install proceed", and nmcli is useless at bringing up the network unless you have already configured it with the GUI.

My suspicion is that even if we find a fix, if it's anything more than adding a kernel flag, the graphical CD installer is essentially useless. Is that right?

This question was expired because it remained in the 'Open' state without activity for the last 15 days.