PDA

View Full Version : X doesnt start :(



kalaka
10th May 2007, 07:05 PM
Hi,
I'm running Fedora Core 6. I was trying to install gimpShop from source (I know there's an rpm, I realized this too late). To do this, I had to install gtk+ from source too. When running ./configure it told me it was missing some X development libraries. Next thing I know, X crashes and I can't start Fedora (the login screen just flickers a lot but I dont even get an error message). What should I do?

tashirosgt
10th May 2007, 08:50 PM
Use the first install cd, look for "other options" and boot using the rescue mode. Read the instructions about how to do chroot or, if you want to skip them, remember that the files on your hard drive will appear under a directory something like /mnt/sysimage. Check the logs in /var/log to see what caused the first problem. (/var/log/messages , /var/log/Xorg,0,log)

kalaka
12th May 2007, 02:44 AM
When I enter recovery mode and check the logs the only unusual thing that comes up (or so it seems to me) is this:

Warning: font renderer for ".pcf" already registered at priority 0
Warning: font renderer for ".pcf.Z" already registered at priority 0
Warning: font renderer for ".pcf.gz" already registered at priority 0
Warning: font renderer for ".snf" already registered at priority 0
Warning: font renderer for ".snf.Z" already registered at priority 0
Warning: font renderer for ".snf.gz" already registered at priority 0
Warning: font renderer for ".bdf" already registered at priority 0
Warning: font renderer for ".bdf.Z" already registered at priority 0
Warning: font renderer for ".bdf.gz" already registered at priority 0
Warning: font renderer for ".pmf" already registered at priority 0
and this

(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
(WW) AIGLX: 3D driver claims to not support visual 0x25
(WW) AIGLX: 3D driver claims to not support visual 0x26
(WW) AIGLX: 3D driver claims to not support visual 0x27
(WW) AIGLX: 3D driver claims to not support visual 0x28
(WW) AIGLX: 3D driver claims to not support visual 0x29
(WW) AIGLX: 3D driver claims to not support visual 0x2a
(WW) AIGLX: 3D driver claims to not support visual 0x2b
(WW) AIGLX: 3D driver claims to not support visual 0x2c
(WW) AIGLX: 3D driver claims to not support visual 0x2d
(WW) AIGLX: 3D driver claims to not support visual 0x2e
(WW) AIGLX: 3D driver claims to not support visual 0x2f
(WW) AIGLX: 3D driver claims to not support visual 0x30
(WW) AIGLX: 3D driver claims to not support visual 0x31
(WW) AIGLX: 3D driver claims to not support visual 0x32

Should I post my message and xorg.0.log files or is that a bad idea? :P I really dont know where to copy them (I cant seem to mount my USB in recovery mode)

I dont want to have to reinstall fedora.. is there a way to reintsall X without screwing things up more than I already have?

Seve
12th May 2007, 03:50 AM
Hello:
You have a couple of options.
(for now you can ignore the log messages :) )

Boot from your FC install disc and select the upgrade option and go through the process and see if that corrects the missing or corrupt files ?

If it does correct everything, then you are good to go :)

If not:

Try booting from your FC install disc and type
linux resuce
follow along with the on-screen instructions [make sure you have your network enabled]
at the last prompt #
type
chroot /mnt/sysimage

then type
yum groupinstall "X Window System" " GNOME Desktop Environment"
with the exact syntax including the quotes

when it's finished, type exit and reboot and see how it goes

Seve

kalaka
12th May 2007, 11:40 PM
When I try to use yum I get:

rpmdb: Program version 4.3 doesn't match enviroment version
error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database enviroment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
yummain.main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 82, in main
base.getOptionsConfig(args)
File "/usr/share/yum-cli/cli.py", line 206, in getOptionsConfig
errorlevel=opts.errorlevel)
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 132, in doConfigSetup
self.config = config.readMainConfig(startupconf)
File "/usr/lib/python2.4/site-packages/yum/config.py", line 598, in readMainConfig
yumvars['releasever'] = _getsysver(startupconf.installroot, startupconf.distroverpkg)
File "/usr/lib/python2.4/site-packages/yum/config.py", line 661, in _getsysver
idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed

kalaka
14th May 2007, 09:54 PM
Turns out my last post was just a temporary problem. Yum works fine from rescue mode. I had all my packages up to date so I had to groupremove and then groupinstall both "X Window System" and "GNOME Desktop Environment". The updates went just fine but when I reboot the screen still flickers (my problem hasnt gone away). Please help :(

PD: I also tried doing 'yum update' and it didnt work. Anyone have any ideas?

Time2IPL
14th May 2007, 11:10 PM
Turns out my last post was just a temporary problem. Yum works fine from rescue mode. I had all my packages up to date so I had to groupremove and then groupinstall both "X Window System" and "GNOME Desktop Environment". The updates went just fine but when I reboot the screen still flickers (my problem hasnt gone away). Please help :(

Have you tried booting up to runlevel 3 && starting X via startx? Personally, I would give that a shot (in /etc/inittab, on the line that reads "id:5:initdefault:", s/5/3/ && reboot). Log in as root at one of the virtual consoles (<ctrl><alt><F1> - <ctrl><alt><F6>) then type:

startx > run.log 2>&1 &

You should be able to see what X is doing by cat'ing or tail'ing "run.log" or /var/log/Xorg.0.log; dmesg might help too. Same w "tail /var/log/messages".

What kind of graphics card are you using, and with what driver? As you probably guessed, the combination can cause problems like the one you're seeing. In my /etc/X11/xorg.conf, I've had to disable AIGLX:



Section "ServerFlags"
Option "AIGLX" "off"
EndSection


Once X is running, try

grep WW /etc/X11/Xorg.0.conf

&&

grep EE /etc/X11/Xorg.0.conf

Oh yeah - the messages you received earlier:



Warning: font renderer for ".pcf" already registered at priority 0
Warning: font renderer for ".pcf.Z" already registered at priority 0
Warning: font renderer for ".pcf.gz" already registered at priority 0


have to do with the way the X server is split up now (the new "modular design") and some benign redundant font resource table entries; shouldn't be anything there to worry about.

What you're seeing on the screen - is it a poorly visible image, double/triple/quad image, just blank, does it lock the machine up or ??? What does top show that X is doing? Also, you might want to try starting with a REALLY basic xorg.conf, booting to runlevel 3 and running system-config-display; that might prove to be helpful too...

- Larry

kalaka
14th May 2007, 11:48 PM
Hi Larry, thanks for your help.

My xorg.conf file has no ServerFlags section. My xorg.conf file is as basic as it gets (I think). My video card is a ATI Radeon 9200, it worked great up until a few days ago. I now see a black screen with some white flashes (I still see my mouse).

Here's my xorg.conf file:

Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kdb"
Option "XkbModel" "pc105"
Option "XkbLayout" "es"
EndSection

Section "Device"
Identifier "Videocard0"
Driver "radeon"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes (... lots of modes, too lazy to type :-P)
EndSubSection
EndSection

I managed to start Fedora in runlevel 3. I started X using startx and made a log like you told me. When I startx, I can only see the root's desktop background (the default wallpaper), I can still see my mouse but I cant do anything else. I found the following erros and warning in run.log:

(WW)RADEON:No matching Device section for instance (BusID PCI:1:0:1) found

(EE)AIGLX: Screen 0 is not DRI capable


Traceback (most recent call last):
File "/usr/bin/puplet", line 27 in ?
import gtk
File "/usr/lib/python2.4/site-packages/gtk-2.0/gtk/__init__.py", line 48, in ?
from gtk import _gtk
ImportError:/usr/lib/libgdk-x11-2.0.so.0: undefined symbol: cairo_xlib_surface_create_for_bitmap


gnome-panel: symbol lookup error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: cairo_xlib_surface_create

When I was installing gtk+ from source, I also had to install some dependencies (also from source), including cairo. This probably has something to do with it, how can I fix it?

kalaka
15th May 2007, 12:58 AM
I fixed my problem :D
I entered rescue mode and first removed the cairo version I had installed form source with

make uninstall
Then I removed all cairo packages

rpm -e cairo --nodeps
then reinstalled using yum

yum install cairo
Works great! Thanks to everyone who helped

Time2IPL
15th May 2007, 11:02 PM
I fixed my problem :D
I entered rescue mode ...


Cool; I'm glad everything's working for you again.

Just thought I would mention that after looking over your xorg.conf, etc., it doesn't look like you've got DRI enabled. I'm not sure how much of a difference in terms of speed it makes with the "radeon" driver, as the Radeon X1600 I have isn't supported by it (yet), so for the time being I'm stuck using the proprietary drivers - if I want to get any sort of speed out of the thing at all - but on that combination of card and driver but on it (the X1600 + proprietary driver), without DRI, it's painfully slow...

Also, now that everything's back up and running, you might want to go grab the SRPM for cairo, install it (don't worry; it only installs the source && only to /usr/src/redhat/SOURCES && /usr/src/redhat/SPECS) and have a look at the .spec file && see what it did differently. If you install the SRPM, and then:


rpmbuild -bp /usr/src/redhat/SPECS/something.spec

(you'll probably also want to do a -bc && -bi), what'll happen is this:

rpm / rpmbuild sets up a build root somewhere other than your normal /usr, /usr/lib, etc. and chroot()'s so that it's running inside of a fake root somewhere - like /tmp, or /var/tmp

In step "-bi", rpm / rpmbuild actually installs the software inside of that "chroot jail" it created earlier and checks to see if there are any files that are unaccounted for, missing, etc.; in other words, it installs the software you built, but inside of the chroot'd environment only. So you get to see exactly what's happening / is going to happen, but, you don't have to worry about trashing anything.

The .spec files are somewhat daunting at first; all they are is a series of step by step instructions and macros. To decipher one, it can help to pass some some of the macros to RPM on the command line; try:


rpm --eval %configure


When I build something from source, that's very often how I figure out what I need to pass to "./configure".

This problem went away too, right? If you start X by using "startx" you should see your regular desktop, etc.; should look just like it does if you log in from gdm... The only time you should notice a difference is when you log out (you'll be back at a command prompt instead of back to gdm):


When I startx, I can only see the root's desktop background (the default wallpaper), I can still see my mouse but I cant do anything else.


Hope that helps - glad everything worked out well!

- Larry

kalaka
16th May 2007, 04:25 AM
Yeah the problem went away. I had to do the same procedure (make uninstall, rpm -e, yum install, etc) for pango, which was another dependency that I installed for gimpShop. Aparently the only way to install gimpShop in fedora is to use
./configure –prefix=/usr CC=gcc32 CXX=g32 . I'm not sure though, I might try it when I have more time :-P

Time2IPL
16th May 2007, 07:44 PM
Yeah the problem went away. I had to do the same procedure (make uninstall, rpm -e, yum install, etc) for pango, which was another dependency that I installed for gimpShop. Aparently the only way to install gimpShop in fedora is to use ..

That (what you pass to configure) is a large part of whether or not what you build from a tarball, etc. will work or not; what you have is close. Setting "--prefix" correctly is usually the most important thing to set as a lot of other things are based off of it (for ex., if prefix == /usr then --includedir=/usr/include - unless you tell configure otherwise). What has to be set (if anything) can vary a lot from one app to another.

I had some fits and starts initially with pango myself; from what I remember, it was particularly finicky about how it was set up. AFAIK pango <-> cairo is pretty much the default for most things now; there may be other renderers, I haven't had to specifically turn any one on or off though.

My guess is you would probably be OK if you had had everything you needed set for configure - and possibly make. Like I said, you can always go the RPM route && create your own .spec file, but that's overkill for a lot of things in my opinion, anyway. When I don't feel like messing with a .spec file, I usually just redirect the output of "rpm --eval", etc. to a shell script and strip out what I don't need; I usually call it something like "mybuild.sh":



rpm --eval %configure > mybuild.sh
rpm --eval %build >> mybuild.sh
rpm --eval %makeinstall >> mybuild.sh


Then, I fire up vi, strip out what I don't need, add "#!/bin/sh", copy over the settings that I passed to configure and "adjust" them a little so they're appropriate for make (whether or not you need to do this depends upon the app you're building; in general, though, it may not do anything, but it shouldn't hurt anything); then, I chmod the thing and let 'er rip...

This is the script I used to build "fltk" (a windowing toolkit, along the same lines as wxWidgets) that I "wrote" using the process I described; I use this approach a lot, and the worst I've had to do is change some of the settings:



#!/bin/sh
#
# LJM Configure, build package based on the settings used by rpm:
#
# rpm --eval %configure
# rpm --eval %build
# rpm --eval %makeinstall
#
# The commands these directives expand to aren't used verbatim but are heavily
# relied upon. One large difference is that this script is for in-place
# builds, as opposed to RPM, which is for chroot-type builds.
#
# Also, in most cases, we're going to do Just a "make" here, not a "make install".

do_configure() {

./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu \
--target=i386-redhat-linux-gnu \
--program-prefix= \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/usr/com \
--mandir=/usr/share/man \
--infodir=/usr/share/info
}

#

do_make() {

/usr/bin/make \
prefix=/usr \
exec_prefix=/usr \
bindir=/usr/bin \
sbindir=/usr/sbin \
sysconfdir=/etc \
datadir=/usr/share \
includedir=/usr/include \
libdir=/usr/lib \
libexecdir=/usr/libexec \
localstatedir=/var \
sharedstatedir=/usr/com \
mandir=/usr/share/man \
infodir=/usr/share/info
}

#

do_make_install() {

/usr/bin/make \
prefix=/usr \
exec_prefix=/usr \
bindir=/usr/bin \
sbindir=/usr/sbin \
sysconfdir=/etc \
datadir=/usr/share \
includedir=/usr/include \
libdir=/usr/lib \
libexecdir=/usr/libexec \
localstatedir=/var \
sharedstatedir=/usr/com \
mandir=/usr/share/man \
infodir=/usr/share/info \
install
}

# -------------------------------------------------------------------------- #

# Save current value of LANG (if any)
declare -a PREVLANG
PREVLANG=$LANG

LANG=C
export LANG

CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables}" ; export CFLAGS ;
CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables}" ; export CXXFLAGS ;
FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables}" ; export FFLAGS ;

# LJM don't need this code...
# for i in $(find . -name config.guess -o -name config.sub) ; do
# [ -f /usr/lib/rpm/redhat/$(basename $i) ] && /bin/rm -f $i && /bin/cp -fv /usr/lib/rpm/redhat/$(basename $i) $i ;
# done ;

do_configure
# Now do "make" (or "make install")
do_make
# Do "make install" if "make" (eg., "make all") was done separately
#do_make_install

LANG=$PREVLANG
export LANG


The main drawback I've found to building software this way is that RPM doesn't know about what I've installed, so it won't factor in anything I've built this way when it (or yum, pup, etc.) is resolving dependencies.

And, every so often, I'll really screw myself and install an RPM that trashes an install I did this way (usually when I forget && do a "yum -y ugrade").

- Larry