Can't reach graphical interface unless I startx twice
 

Arch Linux
AMD RadeonHD 7870

The first time I try startx, I get a jumbled mess of colors on my displays.
I press ctrl+alt+f3, login again, and try startx. It works.

Here's the log of the unsuccessful first attempt: http://pastebin.com/8dfAe0tk

Any ideas?

Distro...DM??

Well, it did report "out of memory". I imagine some other processes got aborted as well releasing enough memory that it would run the second time.

Does this occur every time, or only the first time after a reboot? Any entries in the system log?

Proprietary or Open drivers? Probably a bug in the proprietary drivers IMO. It could also not be loading the kernel module until after X starts the first time and the timing of events go south. Which might work differently on other distros and be a non-issue.

$ sudo modprobe fglrx
$ startx

Or whatever the newer drivers call themselves these days. If using the open drivers and it's not corrupted by the proprietary ones it should just work. Depending on the age of the distro versus the age of the card.

I think the others have good ideas. It may be possible too (very rare) that the video is not fully in a cold state. When you start it once, some mis-match happens and basically crashes the video card. Second time the crash cleared it.

Guess you could try full power off. Remove AC plug, press power button a few times and then try this. It still may not fully clear video card. (again kind of rare)

Arch Linux, the newest available as of yesterday. I don't know what "DM" means in this context, I'm new to quite a few acronyms.

Open drivers.
Package xf86-video-ati which provides X with what it calls the "radeon" driver.

Using the proprietary drivers yields the same result.
Using the command you suggested yields the same result.

No such luck. The problem persists.

After I successfully startx once, I can exit my graphical session and startx again with no issues. I don't know much about a system log, but I know about dmesg: http://pastebin.com/d48KM5zz
Looks like some good information at the bottom.

DM = display manager

since it's Arch did you read this

https://wiki.archlinux.org/index.php/ATI

Check the tail end of /var/log/Xorg.0.log after the first failed start. The (EE) entries might hint at what's going south.

To switch back to the open driver from the proprietary one you'll need to re-install the libGL.so file. Since the ati/amd driver overwrites the libGL.so file. In debian it would be the libgl1-mesa-glx package. Something like pkgfile in arch is roughly the same function as apt-file in debian if you need to search (without google) to find what package contains what file(s).

Yes. I've been through it multiple times. The Arch wiki has been my bread and butter during this install, I've looked through the installation guide, the beginner's guide, and the ATI and Xorg pages looking for any help. I've exhausted all options within my (admittedly pretty narrow) scope of knowledge.

Also, I currently don't have any graphical login, but I do use openbox as a desktop environment: Boot > terminal login > "startx" > fail > ctrl+alt+f3 > terminal login > "startx" > openbox session

The problem I'm describing has been a problem since the beginning, when I first tried starting X using the open "radeon" driver. Only after troubleshooting that as much as I could did I attempt using the proprietary.

Nonetheless, I will try a complete removal of all proprietary shoosh to see if that helps even a little.

Thanks for the responses so far, everyone.

Worse comes to worse, you can use vesa. I tend to use it as I use usb drives on many different systems.

Updates.

Learned a little bit about configuring the radeon driver in the /etc/X11/xorg.conf.d directory.

reveals that Since the problem seems to be with glamor:I tried setting "AccelMethod" to "EXA" in /etc/X11/xorg.conf.d/20-radeon.conf, but it doesn't seem to want to make the switch. Xorg still ends up using glamor.
The GPU I have is a RadeonHD 7870 XT, which I think is technically a Tahiti card. Could that be the reason why I can't use EXA? Is EXA acceleration unsupported on Tahiti and newer? The output above from "man radeon" would lead me to believe so, but is that a definitive answer?

You really shouldn't be having issues unless you're running new linux on dinosaur hardware, or new hardware on dinosaur linux. TBH, you'd be better served trying out other newer distros before fiddling with xorg.conf. It's probably been fixed in a newer kernel or newer version of X. Often already available in certain distros. Or update your distro in six months once it's caught up.

Most of the GPU driver stuff is libGL. In the kernel driver (often needs to be re-installed with each kernel update if using proprietary drivers). Or in the *_drv.so that gets loaded by X. A common issue with the amd proprietary drivers is that the kernel module doesn't get built, but everything else installed. Or the libGL.so reverts to the open driver or vice versa, whatever is NOT the driver you're trying to use. But it's been a few years since I've had a working ATI card. And I trend towards fanless and low power machines now. As I booted an old desktop to use a parallel port printer and I thought I was having health issues. Nope, just 15F hotter in my room until I turned it off.

He's on Arch so he's on the latest kernel and latest X.

my guess is he installed the whole xorg package and something is conflicting.

Maybe try changing the run levels if you haven't already. Setting the right runlevel should make it so you don't have to keep running 'startx'

http://www.tldp.org/LDP/sag/html/run-levels-intro.html

My experience with proprietary drivers are that they are; buggy, buggy, buggy.

You can also try running strace with startx to see more verbosity as startx attempts to load the first time. Use tee to send output to a file for later viewing. Ex. startx | tee -a startx_debugging.txt

More on strace:
http://www.thegeekstuff.com/2011/11/strace-examples/