X server not starting after update to 2.6.25.9-0.2 kernel

I was happily running with 11.0 with the 2.6.25.5 kernel. Then I applied the autoupdates and was “upgraded” to 2.6.25.9.

Now I can’t get the Xserver to start. The graphic splash screen displays during boot, but then it drops back to the login prompt. I can login as root, but nothing starts X. I tried:

init 5
startx
sax2
xorgconfig

but I’m not getting anywhere. The graphics chipset is Intel i845.

If this helps, the error lines from ‘startx’ are

(EE) Failed to load module “dri2” (module does not exist, 0)
(EE) module ABI major version (2) doesn’t match the servers’s versions (4)
(EE) Failed to load module “vga” (module requirements mismatch, 0)
(EE) No drivers available.

Try “sax2 -r”
or
Type “3” at the bootsplash
login as root/password
type “sax2 -m 0=vesa” which is a crappy driver but will get you up
do the config, save
type “reboot”

Should get you up; now go about reinstalling your driver as before when you got it to work.

yep, I already tried those tricks with sax2, and it just fails to start a server. I didn’t go into all the details.

I also tried the failsafe mode from the grub loader, and it does the same things.

I tried this too, but this not work.
Maybe we should wait for fix?

See my reply with 3 possible fixes in the other thread that you started.

Good afternoon!

I have the very same problem, but I’m using ATI card. X server crashed after update. It can’t run even with vesa driver. I hope this bug will be fixed soon.

Same problem here. After logging in I get a blank screen with the mouse cursor but no GUI.

I found the backup xorg.conf file named xorg.conf.sax2save but I can’t see any differences between the two.

As with everyone else, this happened with KDE4.1 with factory repos enabled and a large update with 137 packages. Obviously there is a bug there.

If I can get to a runlevel 3 how do I:

1 - enable and disble repos

2 - run yast from a command line

***I noticed that my path command is blank so I need to know what directory the yast command is located.

is it /usr/sbin ??

Thanks

Hmmmm… I was able to get around the problem by starting KDE failsafe from the login window. Still can’t figure out the problem though. I will try to examine both the old and new xorg.conf files to see if there is any difference. In the meantime, what does “failsafe” do that a normal login doesn’t do? I mean, what does it disable?

I do have the latest 4.1 RC updates because I can tell by the look of the Plasma screen and those ugly shadow boxes around the plasmoids are gone again. (thank God they fixed that) However, failsafe mode must disable something because the system now runs. Knowing what it disables may help to diagnose the problem.

Okay, 32 more package updates including KDEBase and Konqueror today. (July 17th) Let’s see if that fixed the problem. Going down for reboot now. :eek:

Still no go. I get a flash of the desktop when kdm loads (scrambled) and again when I login using KDE4.1 RC2 (actually says RC1, but core is labeled KDE 4.095-2 which I assume really means RC2.

Anyway, the gui won’t load unless I start in KDE Failsafe – which works fine. I wish I knew what failsafe doesn’t load because that is obviously the offending module.

@Psquared -

If you need to back out an update but can’t get to the YaST gui, you can do it this way:

Boot to init 3 (type a 3 in the Boot Option box on the boot menu), login as root, and type “yast” at the command line. It will start the ncurses version of YaST, which looks like the old DOS gui. Tab to Software Management. First tab to View, in the drop-down list choose Package Versions. Then tab to the Filter field; in the drop-down list choose Repositories. Tab to the list, move down to the “11.0 Updates” line, Enter. On the right will be all packages updated through the Update service; if you are looking to reverse an update made from Factory or a Community repo, navigate to that line in the list. The packages with an “i” have been installed from this repo. In the pane below, all the versions will be listed with the version actually installed highlighted. Navigate to the version list, then to the version you want to go back to (e.g., “oss”), and hit return; the package is marked for downgrade. F10 to Accept. Reboot.

Thanks. I’ll try that as a last resort. What I am trying to do now is get all the packages for KDE4.1 RC2. Can find a source (repo) yet. I have a feeling that once I am up to RC2 that the xorg problem will be fixed.

Hopefully you are right that on your system, the issue is with the Factory KDE 4 updates. Just take note that this thread initially referred to an X problem caused by the kernel update. There is another thread where the culprit cited was the update to X. So perhaps your problem lies elsewhere than the 4.1 updates?

Hmmm… now that you mention it I had the buildservice Xorg repos enabled at one time and got a big xorg update … mainly fonts and stuff.

I wonder if I can undo that update? Like I said, starting with KDE “failsafe” starts KDE4.1 RC1 with no problems.

Do you have any idea what the failsafe (from the login window not Grub) disables?

Where are the entries for login (different DEs and failsafe mode) located. If I knew what commands failsafe mode was running when it starts KDE I could figure this out.

I found an xsessions folder with kde4.1.desktop in it, but not the “failsafe.” Any ideas where that might be?

Thanks

The KDM menu will launch any X window manager. On my 3.5 and 4.1 systems, Failsafe just takes you to an X terminal window, which I’m guessing is what happens when a window manager is not chosen. If you are getting into KDE from Failsafe, I don’t think that is intentional. :wink:

Re the X update: To be updated to the version in the X repo, you would need to force that. But there are updates to six X components incl the server, in the standard 11.0 Updates repo. You should be able to downgrade if needed.

Mingus@

On the KDM login screen, under “sessions” - bottom left I have an entry called “KDE Failsafe”. That loads KDE4.1 RC1. I also have an entry called “KDE 4.1 RC1” which tries but does not load KDE4.1. I end up with a cursor on a black screen. I see a flash of a garbled desktop, but it never loads. Ctrl-Alt-F2 takes me to runlevel 3 where X is loaded, but not KDE. I cannot manually start KDE from this runlevel.

Somewhere there is file associated with this selection (KDE Failsafe) which gives the correct parameters to start KDE4.1 RC1 however I cannot find it. It is NOT in usr/share/xsessions.

I don’t know where else to look, but feel like if I could find it and open it with nano I could see the exec:command and any parameters that enable KDE4.1 RC1 to start.

Thanks for your interest and help.

I have looked at the xorg.conf and the backup and see no difference.

@Psquared,

I read through the KDM and X startup scripts. I can’t be absolutely certain - there are quite a few scripts involved - but it appears to me that in the event that the KDM display manager selected fails, the failsafe is to call xterm. And that is what gets called from the “Failsafe” entry on my KDM session types list. My systems don’t have a “KDE Failsafe”. Also, Ctrl-Alt-F2 should open tty2, a terminal session; not X; that is strange, too.

I don’t know what to suggest at this point. But, you are actually getting into KDE with the Failsafe choice? It would seem then that it is a KDE 4 config problem, as you had suspected all along. I doubt that the problem is with X. You might try searching on “kdm” and “kdmrc” to see if you can dig out what is happening; I’m pretty sure that one of the kdm files stores the X login menu and therefore the “Failsafe” menu entry, but I couldn’t find it. I’m sorry I don’t have a better thought right now.

Yeah - it’s weird. If I ctrl-alt-f2 and type startx it says x is already running. If I type startkde it says it can’t connect to the x server.

But again, the KDE Failsafe is working for now so I may just wait for more updates. I’m at 4.0.99 on most everything now so hopefully, if it is a KDE config problem it will get straightened out shortly. Meanwhile, I have a working box.

checking kdmrc is a good idea. I’ll check that. Thanks ever so much for your help. :slight_smile: