gdm fails to start after hardy upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xorg-server (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Binary package hint: gdm
I've just upgraded my gutsy machine to hardy.
The installation went well, not errors or issues.
After the first reboot the machine does not start gdm anymore (rather the X server starts and crashes) Eventually I get this error in the console:
The display server has been shut down about 6 times in the last 90 seconds. It is likely that something bad is going on. Waiting for 2 minutes before trying again on display :0
The machine is a duron 800 kt133 with an nvidia fx5200 apg card. Running an up-to-date hardy.
I'm running the following kernel:
Linux aporia 2.6.24-19-rt #1 SMP PREEMPT RT Sat Jul 12 02:53:01 UTC 2008 i686 GNU/Linux
with noapm and acpi=off kernel options
This is likely not a HW problem, as the breezy liveCD starts X fine, and using nv or nvidia I can start x with startx (as root) no problem.
I've experimented with vesa, nv and nvidia drivers to figure out the problem. Here are the results: Files are attached after this message and references by filename here.
Here are the results for the xorg.conf file (where only the driver field is changed)
nv:
gdm switches the VT, shows busy mouse pointer, then quits and restarts, eventually showing above message.
startx works as expected (as root)
vesa:
gdm goes into suspend rather than showing the busy mouse, shows console between quits and restarts. Eventually shows the above message.
startx behaves the same as gdm, does not quit and restart, just puts monitor in suspend.
nvidia:
gdm behaves the same as when using nv
startx works as expected (as root)
The following is included for comparison using the xorg.conf.failsafe:
Vesa failsafe:
gdm behaves the same as vesa with the xorg.conf
startx behaves same as gdm, stays in suspend. Not error message, does not flash back to console.
The Xorg.0.log files are also included (cleared for each test). The only difference between the startx and gdm method appears to be the VT being used. Could all this come down to a VT problem? How to confirm?
The xorg files and xorg logs for each test case attached:
[lspci]
00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] [1106:0305] (rev 03)
Subsystem: ABIT Computer Corp. KT7/KT7-
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV34 [GeForce FX 5200] [10de:0322] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Unknown device [1043:80e3]
Changed in gdm: | |
status: | Incomplete → New |
Changed in xorg-server: | |
status: | New → Confirmed |
Changed in xorg-server: | |
status: | Incomplete → New |
status: | New → Incomplete |
Changed in xorg-server: | |
status: | Incomplete → Confirmed |
description: | updated |
Changed in xorg-server (Ubuntu): | |
status: | Confirmed → Triaged |
tags: | added: hardy |
tags: | added: crash |
Changed in xorg-server (Ubuntu): | |
status: | Incomplete → Fix Released |
Thank you for taking the time to report this bug and help make Ubuntu better. However, after having a quick look through your X server log files, I can't see anything drastically wrong with your X server. Could you please try to start GDM with your default configuration (when it fails), and then add the contents of /var/log/gdm in to a tar.gz archive and then attach it to this bug report.
Thanks