Hello I'm a multi-linux multi-booter who always boots to console and then when/if I'm ready for the gui to start I use startx (almost always with my ~/.xinitrc pointing at E17...) Any way; Lately, when running Sabayon on my Gateway laptop (MT6451 Notebook PC) which has AMD Turion 64x2 processors, I've got to call startx twice to get X (E17) ??? This didn't used to happen, and still doesn't with the other three distro's I've got installed on it.

When startx runs the first time I wind up looking at a blue screen that says "Sabayon" and something about "initializing the kernel"... But by typing the appropriate <Alt>+<Fkey> combination I can return to the tty I ran startx from. Except that the font size is now much smaller than my eyes are comfortable with <sigh> Though that doesn't really matter since this {tiny font garbage} don't happen until I want the gui anyway, so it's easy enough to just repeat the startx command and then poof I'm in E17 where I decide how big a font is used in the Konsole terminal windows. In fact I only mention it because: it's hard telling {not knowing} what facts actually are significant to the guys with smarter brains than mine...------------------------------==== my ~/.xinitrc ===========------------------------------

Current version of pixman: 0.24.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version.Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 2 07:05:37 2011(==) Using config file: "/etc/X11/xorg.conf"(==) Using config directory: "/etc/X11/xorg.conf.d"(==) Using system config directory "/usr/share/X11/xorg.conf.d"(II) [KMS] drm report modesetting isn't supported.(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.[dri] This chipset requires a kernel module version of 1.17.0,[dri] but the kernel reports a version of 2.9.0.[dri] Make sure your module is loaded prior to starting X, and[dri] that this driver was built with support for KMS.[dri] Aborting.(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:no screens found

Please consult the The X.Org Foundation support at http://wiki.x.org for help.Please also check the log file at "/var/log/Xorg.0.log" for additional information.

------------------------------==============================------------------------------I'm thinking this line is likely the big clue here:

[dri] This chipset requires a kernel module version of 1.17.0,

But I'm not quite sure what to do about it. I'm hoping it doesn't mean I'm going to have to {first learn how} customize the kernel every time it gets upgraded from now on... Or maybe I'll just try putting this in my ~/.bashrc:

alias startx='/usr/bin/startx;/usr/bin/startx'

But even if that works, it'd be too much of a kludge, even for me...There simply has to be a better solution.

Could somebody point me at a good how-to that might give me a clue?-- joe3

Thanks for the link BHReach , Im not using Sabayon at the moment so I'll have to look at it again when I can use it as a guide to running some of the listed diagnostic commands...

It does make some sense to me that this could be KMS related. Though I do already have "radeon.modeset=1" set in my kernel options... And I'm not so sure that any "missing firmware files" that would stop x from starting the first time wouldn't also stop it from running the second time I gave the command???

But I did notice that by the time I issue the second startx command (the one that works) my console font size has shrunk significantly... Historically I always used to keep my console fonts legible by way of the {now defunct} kernel option "vga=normal" Which I basically replaced with "gfxpayload=text" instead of learning how to explicitly set a LARGE console font in sabayon. I do have a dim memory of having had to install some large console font to my Arch Linux installation when they began using KMS...

Anyway, not knowing how gfxpayload=text actually works, {nor why it always stops working in the consoles after x starts, or evidently, even just "tries" to start} So I don't have a clue if it could be a factor...I'll have to try booting without that option to see if it makes any difference. If it does, then I'll be looking for a how-to on properly setting a "huge" console font in Sabayon. Which might be a better method than using a kernel option that x blows away anyhow. Would you happen to know the URL of a how-to for that??

Thanks again for the link BHReach... This one really hit the spot, and was very easy to follow. And thanks for the equo/vs/emerge tip too {though I'd like to think I'd have tried equo first anyway [emerge makes me nervous]}

Anyway, I've now got a nice console font set up... And no BTW, booting without 'gfxpayload=text' didn't make any difference on the startx issue.

Which brings me back to the first link you posted to this thread.

I notice {now that I've had time to look closer} that your link indexes the part of the wiki article titled "Check if radeon-KMS is enabled before X is started" which section just about exactly describes my error message. It would make me think that radeon-KMS isn't so enabled except that I do already have "radeon.modeset=1" in my "kernel" command line options.

I note that much of the radeon-KMS wiki artical is written above my skill level. It's like the informative auto motive manual that tells you to use 10w30 oil without telling you where to put it, (I've seen idiots pouring motor oil in their radiator before {shudder}) In like manor that wiki advises "don't load radeonfb, uvesafb or vesafb module" But other than looking in my menu.lst file for those exact terms (which are not there BTW) I have no idea how to check that I'm not somehow loading them...

Though I can say that I've never customized my kernel. (wouldn't know how...) So unless an entropy managed Sabayon system would by default load one of those for a generic kernal, then logic tells me they weren't loaded. I only ever install anything to my sabayon via equo (with the sole exception that I followed explicit blow by blow instructions to emerge music on console with use flags that let it actualy recognise my *.wav music files).

That wiki article section titled "Check if your ddx and mesa-dri driver have KMS support" is also problematical for me. Again I don't know HOW to check. Though since this is Sabayon, not gentoo I'd expect that the default drivers from entropy would have KMS support??

That section of the wiki also says to: "check if you have fitting components of the Linux graphics driver stack"

And lists a few commands along with examles of the expected output. All of which do so Except lsof | grep ^Xorg | egrep '_drv.so|_dri.so' | egrep 'radeon' Which doesn't give any output what so ever...

In general though I'm not understanding how any of these issues would only stop the first instance of startx from succeeding in starting X while always the second instance of startx works, every time.

I don't know if it would be useful or not, but the last time I booted I ran startx, and when it failed I copied the "Xorg.0.log" file. ran startx again, and as soon as E17 was done loading I logged out of X and copied Xorg.0.log again. These logs can be found at:

I should have rebooted to test that "consolefont would actually work. especially in light of the fact that:

https://sites.google.com/site/drunkvegetarian/computer/linux/consolefont wrote:First thing is that you need to make sure and have a framebuffer already setup and running. Consolefont will fail to start unless you do this first. If you already have a framebuffer setup, then don't worry about it.

But to tell you the truth, I wasn't sure how to tell if framebuffer was working, and I was {and still am} much more interested in solving the startx failure. Especially since, not knowing why the second startx attempt works, I have to assume that I'm depending on some fluke. And thus that some future "equo upgrade" might result in total startx failure... Last night I booted Sabayon on the laptop and proceeded to follow the rest of the consolefont how-to's instructions. Only this was AFTER starting X so I could use opera to view the how-to... I used <ctrl>+<alt>+<F2> to log in as root on tty2 where I installed the "terminus-font" package and tested the fonts with setfont, {found that any terminus font name ending in 24b would approximate what vga=normal used to do before KMS} So I put 'consolefont="ter-124b"' in /etc/conf.d/consolefont, and then ran "eselect rc add consolefont default" and assumed the font was installed... <sigh> But just before going to bed, I got around to rebooting the laptop just to test that I'd actually get ter-124b in the console's both before and after startx. But on the way in, as the verbose text of the boot process scrolled by on tty1, I happened to spot that consolefont failed to start... {whimper}

So now I wonder if a lack of framebuffer could cause the startx failure???

I did some googleing and it looks like I'd need to get into building my own kernel {shudder} (or at least custom modules) to get KMS compatible framebuffer working??? If I had the time and desire to do much of that, I might as well have installed gentoo instead of Sabayon. {sigh}

At this point I'm just hoping running startx TWICE will continue to work. I mean that as far as the console font issue goes, since it don't matter till after I call startx, I'm thinking of just using something like:alias startx='/usr/bin/startx;setfont ter-124b.psf.gz'

Will show which daemons start and on which runlevel. See if consolefont is listed.

Also, make sure /etc/conf.d/consolefont has your selected font listed. Comment out the one that was originally there and add the one you want. If both are listed it may just use the 1st or last one listed.

Also, make sure the font you choose is in /usr/share/consolefonts, I have Sabayon 7 LXDE x86 booted up and the one you want is not listed there.

OK so as soon as I hit enter on that, I got that blue Sabayon {splash?}screen that I've been getting when startx fails... When I used<alt>+<Fkey> to switch back to a tty, I'm seeing that annoyingsmall font again... I'm betting though, that startx will work on thefirst attempt. (it's looking to me like the kernel command lineoption: "radeon.modeset=1" simply isn't initializing radeon-KMS)

But before I test startx, I'm going to look at the consolefontissue...

If the consolefont did not stick on reboot maybe the eselect command did not work.

Also, make sure /etc/conf.d/consolefont has your selected font listed. Comment out the one that was originally there and add the one you want. If both are listed it may just use the 1st or last one listed.

~UnderTree=-> cat /etc/conf.d/consolefont# consolefont specifies the default font that you'd like Linux to use on the# console. You can find a good selection of fonts in /usr/share/consolefonts;# you shouldn't specify the trailing ".psf.gz", just the font name below.# To use the default console font, comment out the CONSOLEFONT setting below.# This setting is used by the /etc/init.d/consolefont script (NOTE: if you do# not want to use it, run "rc-update del consolefont boot" as root).# consolefont="default8x16"consolefont="ter-124b"

# consoletranslation is the charset map file to use. Leave commented to use# the default one. Have a look in /usr/share/consoletrans for a selection of# map files you can use.#consoletranslation="8859-1_to_uni"

# unicodemap is the unicode map file to use. Leave commented to use the# default one. Have a look in /usr/share/unimaps for a selection of map files# you can use.#unicodemap="iso01" ~UnderTree=->

Also, make sure the font you choose is in /usr/share/consolefonts, I have Sabayon 7 LXDE x86 booted up and the one you want is not listed there.

I can't think of any reason why consolefont is failing, unless it'sframebuffer?

But at least the setfont method works...

And BTW I was right about startx working on the 1st try this time... I'llhave to figure out how to load the module without calling it on the kernelcommand line... I'll have to look at that KMS how-to a little more.