X server starts randomly in failsafe when starting from cold boot

Bug #459639 reported by Alexia Death
88
This bug affects 15 people
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Confirmed
Undecided
Canonical Desktop Team
Nominated for Karmic by Klaus Steinberger
Lucid
Confirmed
Undecided
Unassigned
Maverick
Confirmed
Undecided
Canonical Desktop Team
kdebase-workspace (Ubuntu)
Triaged
Medium
Bryce Harrington
Nominated for Karmic by Klaus Steinberger
Lucid
Confirmed
Undecided
Unassigned
Maverick
Triaged
Medium
Bryce Harrington

Bug Description

I have a laptop that was upgraded to Karmic from Jaunty. When it comes up from cold boot is ends up with failsafe X more often than not. Failsafes/normal boots are about 60%/40%. If I restart KDM it always starts properly. I havent found any indikation from the logs about the reasons of initial failsafe. It feels like the normal session is not even tried or if it is it fails before even logging something.

Revision history for this message
Alexia Death (alexiade) wrote :

My kdm log tells me this about the failure:

X.Org X Server 1.6.4
Release Date: 2009-9-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-24-server i686 Ubuntu
Current Operating System: Linux angelica 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686
Kernel command line: root=UUID=a0fd659a-f6bf-4fb5-bcbb-920bd376c92e ro nosplash
Build Date: 14 October 2009 11:18:16PM
xorg-server 2:1.6.4-2ubuntu3 (buildd@)
        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: Sat Oct 24 11:08:59 2009
(==) Using config file: "/etc/X11/xorg.conf"
 ddxSigGiveUp: Closing log
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
xinit /etc/gdm/failsafeXinit /etc/X11/xorg.conf.failsafe -- /usr/bin/X -br -once -config /etc/X11/xorg.conf.failsafe -logfile /var/log/Xorg.failsafe.log

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi alexiade,

Please attach the output of `lspci -vvnn` and `dmesg`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you're using a custom /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xorg-server (Ubuntu):
status: New → Incomplete
Revision history for this message
jajaX (jajaplanet) wrote :

Hi ! (sorry for my bad english)

laptop : ACER 5612 WLMI

lspci =>

[jajax@assistinfo ~]$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
06:01.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
06:04.0 CardBus bridge: ENE Technology Inc CB-712/4 Cardbus Controller (rev 10)
06:04.1 FLASH memory: ENE Technology Inc ENE PCI Memory Stick Card Reader Controller (rev 01)
06:04.2 SD Host controller: ENE Technology Inc ENE PCI Secure Digital Card Reader Controller (rev 01)
06:04.3 FLASH memory: ENE Technology Inc FLASH memory: ENE Technology Inc: (rev 01)
06:04.4 FLASH memory: ENE Technology Inc SD/MMC Card Reader Controller (rev 01)

Revision history for this message
jajaX (jajaplanet) wrote :
Revision history for this message
jajaX (jajaplanet) wrote :

X.Org X Server 1.6.4
Release Date: 2009-9-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux assistinfo 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686
Kernel command line: root=UUID=d6f4c462-25bd-4416-9995-f2734f7aa492 ro quiet splash
Build Date: 26 October 2009 05:15:02PM
xorg-server 2:1.6.4-2ubuntu4 (buildd@)
 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: Thu Nov 5 21:31:51 2009
(==) Using config file: "/etc/X11/xorg.conf"
(EE) Failed to load module "freetype" (module does not exist, 0)
WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/libpisock9, it will be ignored in a future release.
Setting master
Dropping master
 ddxSigGiveUp: Closing log
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
/etc/gdm/failsafeXServer: line 124: /var/log/gdm/failsafe.log: No such file or directory
Warning: Cannot write to /var/log/gdm/failsafe.log
xinit /etc/gdm/failsafeXinit /etc/X11/xorg.conf.failsafe -- /usr/bin/X -br -once -config /etc/X11/xorg.conf.failsafe -logfile /var/log/Xorg.failsafe.log

Revision history for this message
jajaX (jajaplanet) wrote :
Revision history for this message
jajaX (jajaplanet) wrote :
Revision history for this message
jajaX (jajaplanet) wrote :
Revision history for this message
jajaX (jajaplanet) wrote :
Revision history for this message
jajaX (jajaplanet) wrote :

normal boot

Revision history for this message
jajaX (jajaplanet) wrote :

bad boot

Revision history for this message
jajaX (jajaplanet) wrote :

others informations :

upgrade kubuntu jaunty 9.04 (32 bit) to kubuntu karmic 9.10 (finale release) (32 bit).

KDE 4.3.3 from ppa (but I have got this problem before kde upgrade).

Revision history for this message
jajaX (jajaplanet) wrote :

Because I have got this problem too

note GDM not installed. only kdm.

Changed in xorg-server (Ubuntu):
status: Incomplete → New
Revision history for this message
jajaX (jajaplanet) wrote :

Hi (sorry for my bad engish)

maybe a solution :

a UUID of swap partition isn't correct after karmic upgrade

before (in my fstab) :

#UUID=7d0c2d5a-831d-4005-b9e9-f72d76d2594a none swap sw 0 0

after upgrade (always in my fstab) :

UUID=8d1e0fa3-1cc8-4d5e-b7d9-914221bca4e4 none swap sw 0 0

for see UUID of swap partition, use this command :

ls -l /dev/disk/by-uuid/

regards ;)

Revision history for this message
jajaX (jajaplanet) wrote :

sorry, I speak too fast, always the same boot problem :-/

Revision history for this message
Marco Cimmino (cimmo) wrote :

Seems I have this problem too since I upgraded from 8.04 to 9.10
I have KDE 4.3.3 and nvidia driver 190, but same issue I experienced with KDE 4.3.2 and nvidia 185 (from Karmic repo).

my video adaptor:
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1)
        Subsystem: Lenovo Device 20d8
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at d4000000 (64-bit, non-prefetchable) [size=32M]
        Region 5: I/O ports at 2000 [size=128]
        Capabilities: <access denied>
        Kernel driver in use: nvidia
        Kernel modules: nvidia, nvidiafb

Revision history for this message
Felix (apoapo) wrote :

I'm affected, too. Perhaps my bug is a duplicate?

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/486702

Revision history for this message
jajaX (jajaplanet) wrote :

Hi (sorry for my bad english).

For your bug, I don't know but when X doesn't want start, I can't make nothing. The screen is black, that's all. I can't go to the TTY for make "startx" or other comand. If I restart X server with "alt" + "impr syst" + "K", the screen is black too and I can't make nothing again.

I must make "magic keys" for reboot my laptop.

regards

Revision history for this message
Alexia Death (alexiade) wrote :

apo, yours does indeed seem to be duplicate of mine. And the whole issue seems to be related to timing. My problems went(sofar) away after I installed some server software not usually found in a desktop like php/apahe/postgresql and mysql that made the boot before X longer for me. It may be possible that the nvidia kernel module is not properly loaded by the time X tries to start an fails.

Revision history for this message
Felix (apoapo) wrote :

This also happens on lucid lynx amd64 on a Dell m1330 notebook. Does anyone now which things trigger kdm to start through upstart? Maybe we have to add something there. The startup file should be /etc/init/kdm.conf

Has anyone tried to delete it yet? Would be interesting to see if it still occurs or if X is not started at all.

Revision history for this message
Marco Cimmino (cimmo) wrote :

Since last X update now I have failsafe mode really kicking and asking me what I want to do, but still 3/10 startup fails :(

Revision history for this message
Alexia Death (alexiade) wrote : Re: [Bug 459639] Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

On Wed, Dec 2, 2009 at 8:59 PM, Marco Cimmino <email address hidden> wrote:
> Since last X update now I have failsafe mode really kicking and asking
> me what I want to do, but still 3/10 startup fails :(
After last update, my startup fails are pretty much 100%....

--
--Alexia

Revision history for this message
Klaus Steinberger (klaus-steinberger) wrote : Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

I found the reason for this behavior. It is a bug in teh upstart script /etc/init/gdm.conf

Inside the script there is a test which dm should be started. If not gdm it exits, but it exits with EXIT_STATUS=1, which then triggers the start of the failsafe session.

I append a patch for gdm.conf which solves the problem. Also kdm.conf has the very same bug and should be patched too.

Sincerly,
Klaus

affects: xorg-server (Ubuntu) → gdm (Ubuntu)
Revision history for this message
Klaus Steinberger (klaus-steinberger) wrote :

Here is the companion patch for /etc/init/kdm.conf

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Is this not the same as bug 491483, for which a fix already exists in karmic-proposed?

Changed in gdm (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Klaus Steinberger (klaus-steinberger) wrote :

Yes, that's true, and the solution is the same

Revision history for this message
Alexia Death (alexiade) wrote : Re: [Bug 459639] Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

On Tue, Dec 8, 2009 at 11:34 AM, Klaus Steinberger
<email address hidden> wrote:
> *** This bug is a duplicate of bug 491483 ***
>    https://bugs.launchpad.net/bugs/491483
>
> Yes, that's true, and the solution is the same
>
> ** This bug has been marked a duplicate of bug 491483
>   Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is used. (low graphics mode error)

The inital bug was afaik present before failsafe-x enabling. With the
last update the fails went up to 100% and the symptoms changed
somewhat, so thats when the GDM problem showed.
--
--Alexia

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

This bug report has nothing to do with gdm+kdm causing failsafe-X to start, that was a regression introduced *after* this bug was filed. Please do not hijack this bug report for unrelated issues.

affects: gdm (Ubuntu) → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
status: Incomplete → New
Bryce Harrington (bryce)
tags: added: karmic
Revision history for this message
Alexia Death (alexiade) wrote :

Just to note, that as soon I uninstalled the sever components(postgresql database sever in my case) I had needed temporarily the issue came back. More often than not for cold boots fail and from what I see from the logs KDM writes, X fails without any clear error messages after trying to load the nvidia driver. I suspect it's because the kernel driver is not done with initalizing hardware yet. I am not however aware how alter upstart so, that X would start little bit later. It seems to be a a matter of few seconds only.

Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Hi Alexia,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 459639

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 459639 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/459639

Changed in xorg-server (Ubuntu):
status: New → Incomplete
tags: added: needs-retested-on-lucid-by-june
Revision history for this message
Alexia Death (alexiade) wrote : Re: [Bug 459639] Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

My update to Lucid is currently stuck behind a full harddrive. I do
hope to solve it in the next few weeks and then I can comment on this
issue further.

Revision history for this message
Marco Cimmino (cimmo) wrote : Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

This is still present on Kubuntu Lucid 10.04 and very random, depends on how fast/slow other processes start.

Attaching my logs where you can see KDM sometimes fails and defaults to failsafe.
Pls do not bother to report these:
(EE) May 04 22:25:21 NVIDIA(1): Unable to find available Display Devices for screen 1.
(EE) May 04 22:25:21 NVIDIA(1): No display devices found for this X screen.

they are for my secondary screen not attached at that time and totally unrelated to the issue.

Revision history for this message
Marco Cimmino (cimmo) wrote :

Adding Xorg log

Revision history for this message
Marco Cimmino (cimmo) wrote :

Adding Xorg.failsafe.log

Revision history for this message
Marco Cimmino (cimmo) wrote :

There is also a patch on comment #24 would someone maybe check before 6 months and next release will be out with the same issue?

Changed in xorg-server (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Marco Cimmino (cimmo) wrote :

And actually if the issue is under kdm.conf as stated in comment #24 the correct component is kdm and not xorg-server

tags: added: lucid
removed: needs-lspci-vvnn needs-retested-on-lucid-by-june needs-xorglog
Revision history for this message
Marco Cimmino (cimmo) wrote :

And finally adding lspci -vvnn output, now please fix this, I think you have enough info here.

Marco Cimmino (cimmo)
Changed in xorg-server (Ubuntu):
assignee: nobody → Bryce Harrington (bryceharrington)
Revision history for this message
Marco Cimmino (cimmo) wrote :

This bug is happening for me on 50% of the startup, is very very annoying, attaching more logs, if someone is listening.

Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Marco Cimmino (cimmo) wrote :
Bryce Harrington (bryce)
tags: added: kubuntu
Revision history for this message
Marco Cimmino (cimmo) wrote :

Just found out that I have some very old /etc/init.d scripts I believe from 8.04 that no upgrade script ever deleted them, no idea if they can interferee or what. Attaching two that are suspicious.

Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

Do you still see this bug on lucid, Alexia?

Changed in xorg-server (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Alexia Death (alexiade) wrote : Re: [Bug 459639] Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

On Fri, Jun 18, 2010 at 4:54 AM, Bryce Harrington
<email address hidden> wrote:
> Do you still see this bug on lucid, Alexia?
>
> ** Changed in: xorg-server (Ubuntu)
>       Status: Confirmed => Incomplete
>
> --
> [Karmic] X server starts randomly in failsafe when starting from cold boot
> https://bugs.launchpad.net/bugs/459639
> You received this bug notification because you are a direct subscriber
> of the bug.
>
After clean install stopped seeing the bug, but the install was
accompanied by switching to new and faster hard-drive, so I cant say
anything about the actual status of the bug. It was always a matter of
seconds so the new harddrive is probably a factor.

--
--Alexia

Revision history for this message
Marco Cimmino (cimmo) wrote : Re: [Karmic] X server starts randomly in failsafe when starting from cold boot

I uninstalled all nvidia-* packages and installed again, so all old files should have been cleared out, but still happening the issue.

Changed in xorg-server (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Marco Cimmino (cimmo) wrote :

Adding new round of logging with Lucid up2date to 1st of July 2010 and KDE 4.4.5

Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Marco Cimmino (cimmo) wrote :
Revision history for this message
Rolf Bensch (rolfbensch) wrote :

I found the reason for this problem. The kernel initialises the framebuffer /dev/fb0 device with the vesa driver (vga16fb) before it starts loading the nvidia driver. You can see this in the attached syslog file.

Revision history for this message
Rolf Bensch (rolfbensch) wrote :

I patched kdm.conf with a sleep before any other commands will be executed. For debugging kdm.conf wites 2 messages into syslog: "start kdm and sleep" and "resume kdm after sleep". Maybe you need to extend the sleep time, if your graphic card takes more time to load the nvidia driver than mine. I respawn kdm, so I can cancel the message boxes if any error occurs and kdm will start up later.

This is only a workaround!

Does anybody has an idea how to recognise a ready loaded graphics driver from the kernel? Looking for /dev/fb0 is not safe for every hardware configuration. A solution should work with any free and proprietary graphics driver.

Revision history for this message
Rolf Bensch (rolfbensch) wrote :

Here is a syslog file with the debug messages from kdm. It shows that kdm starts before the nvidia drivers are loaded and the sleeping time before kdm resumes.

tags: added: patch
papukaija (papukaija)
summary: - [Karmic] X server starts randomly in failsafe when starting from cold
- boot
+ X server starts randomly in failsafe when starting from cold boot
Revision history for this message
Robbie Williamson (robbiew) wrote :

I see the nomination request, but is there confirmation that this bug occurs in Maverick?

Revision history for this message
Marco Cimmino (cimmo) wrote :

Robbie for my experience bugs get not automagically fixed, I can't test on Maverick right now, but if there is a problem that nvidia module is not loaded then this bug will raise in Maverick too.

Maybe this should be fixed in the nvidia driver or maybe in kdm, this I don't know, but until someone does not start working on it then nothing will be fixed.

Revision history for this message
Alexia Death (alexiade) wrote :

Actually its neither kdm nor nvidia bug. Its an straight out ubuntu/upstart bug. Upstart starts KDM before the nvidia driver in the kernel is ready is ready and X fails. Perhaps a proper fix would be an upstart job that is installed with the binary driver and checks if nvidia is ready and delays X start until it is.

affects: xorg-server (Ubuntu Maverick) → upstart (Ubuntu Maverick)
Changed in upstart (Ubuntu Maverick):
status: Confirmed → Triaged
Revision history for this message
quequotion (quequotion) wrote :

I think Alexia may be right. I'm having the same trouble with gdm. There are several bug reports scattered around that look like the same issue. Some of them do not involve nvidia, but have the same symptoms.

How could one script a check to make sure /some/ graphics driver is loaded before starting the login manager? That would be more elegant and efficient than a sleep, and more effective than just checking for nvidia.

similar bug reports:
532436 - failure possibly related to nvidia
573455 - i marked this as a duplicate of 532436
581302 - the description contains different details and is not connected to the nvidia driver, but the login manager fails in the same manner.
498315 - similar problem as I am having now, but I haven't looked into this yet. I also use ureadahead and this report proposes a connection
587607 - probably a duplicate of 581302, but not yet expired
496796 - probably unrelated, but worth a look
447226 - probably unrelated, but worth a look
forum thread (probably not the only one):
http://ubuntuforums.org/showthread.php?p=9742515

Revision history for this message
quequotion (quequotion) wrote :

This is basically Rolf's idea (#53), but I put the sleep in a different place for /etc/init/gdm.conf. In this case it just holds off the call to gdm-binary. This is woking for me for now, but I don't much like it.

@@ -44,4 +44,5 @@
    export XORGCONFIG

+ sleep 2 # WHAT WOULD BE BETTER HERE IS A LOOP THAT WAITS UNTIL A GRAPHICS DRIVER IS CONFIRMED LOADED.
    exec gdm-binary $CONFIG_FILE
end script

Revision history for this message
Colin Watson (cjwatson) wrote :

I believe that this should be less vitally urgent now that we've reverted the GRUB change to use gfxpayload=keep for Maverick. I don't think this has fixed the bug since this bug was present in Lucid, but I think it should reduce its incidence and am thus decreasing the importance to Medium.

I'd appreciate bug comments one way or the other.

Changed in upstart (Ubuntu Maverick):
importance: High → Medium
quequotion (quequotion)
Changed in upstart (Ubuntu Lucid):
status: New → Confirmed
Revision history for this message
quequotion (quequotion) wrote :

>>Watson

Considering that the bug appears to be in upstart or gdm and affects users of both grub-pc and grub-legacy (not that either has been mentioned anywhere in the bug report), I can't say I support this theory.

Also, any bug that causes login to be delayed, annoying, cumbersome, or impossible is a very important bug.
Users expect to get from power-on to desktop in as little time as possible with zero stress. At least I do.

tags: added: gdm kdm login maverick upstart
Revision history for this message
Robert J. Schulz (robert-rosaschulz) wrote :

one more "workaround" diskussion:

instead of a sleep something like this could help !?

    until ( lsmod | grep '^nvidia ' >/dev/null ); do sleep 1; done

??

Revision history for this message
Robert J. Schulz (robert-rosaschulz) wrote :
Revision history for this message
quequotion (quequotion) wrote :

>>Schulz

Does that work? It looks like what I had in mind but couldn't figure out in #59

I suppose I'll have to give it a try.

also, 585930 does look like a duplicate. seems this bug affects both kdm and gdm equally.

I wonder where and how upstart itself could be modified to include your loop.

Revision history for this message
Robert J. Schulz (robert-rosaschulz) wrote :

My loop in #62 does not work for me -- instead the gdm fails to start

a simple sleep 2 as escribed in #59
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/459639/comments/59
works best for me.

Revision history for this message
Antonio Barbuzzi (antoniob82) wrote :

Actually 'sleep 2' works most of times, but not always!

Revision history for this message
Marco Cimmino (cimmo) wrote :

Indeed for me this solution seems the best so far:
 until ( lsmod | grep '^nvidia ' >/dev/null ); do sleep 1; done

Revision history for this message
Cesare Mastroianni (cece) wrote :

Hi there. I removed the "2 seconds delay" workaround some time ago, after the latest nvidia drivers update.

Later, the problem/bug came back: however I missed to add the "2 seconds delay" trick, and it vanished some days later. I noticed that this peculiar behaviour happened when some automatic update was performed... I mean:

On Sept 3rd these packages have been updated:
Start-Date: 2010-09-03 09:06:18
Upgrade: libgudev-1.0-0 (151-12, 151-12.1), usb-creator-gtk (0.2.22, 0.2.22.1), udev (151-12, 151-12.1), python-aptdaemon (0.11+bzr345-0ubuntu4, 0.11+bzr345-0ubuntu4.1), aptdaemon (0.11+bzr345-0ubuntu4, 0.11+bzr345-0ubuntu4.1), wget (1.12-1.1ubuntu2, 1.12-1.1ubuntu2.1), python-aptdaemon-gtk (0.11+bzr345-0ubuntu4, 0.11+bzr345-0ubuntu4.1), libudev0 (151-12, 151-12.1), usb-creator-common (0.2.22, 0.2.22.1), mountall (2.15, 2.15.1), usb-creator (0.2.22, 0.2.22.1)
End-Date: 2010-09-03 09:09:06

After this update the bug comes back.

On Sept 08th these packages have been update:
Start-Date: 2010-09-08 10:11:02
Upgrade: gdebi (0.6.0ubuntu1, 0.6.0ubuntu2), gdebi-core (0.6.0ubuntu1, 0.6.0ubuntu2), sudo (1.7.2p1-1ubuntu5.1, 1.7.2p1-1ubuntu5.2), gwibber-service (2.30.1-0ubuntu1, 2.30.2-0ubuntu1), gwibber (2.30.1-0ubuntu1, 2.30.2-0ubuntu1), python-lazr.restfulclient (0.9.11-1ubuntu1, 0.9.11-1ubuntu1.1), lftp (4.0.2-1, 4.0.2-1ubuntu0.1)
End-Date: 2010-09-08 10:11:45

After this update the bug vanished.

I can't understand which package update trigged this behaviour ...

Ciao from Italy
CM

Revision history for this message
Alexia Death (alexiade) wrote :

Probably none of these specifically. It's a timing issue so it depends on how fast the system is loaded from the drive. For me, faster drive or installing server software equally hid the bug. Faster drive probably because nvidia loads faster now and the server software because X was delayed a second or two.

Looking at your changes, the update that made the issue appear probably made some start-up component faster, speculatively mountall looks interesting, but I haven't checked the change log. The next update updated at least one service, potentially making the startup again slightly slower.

The triggering factors of this bug can range from hardware to installed packages to how fragmented your drive is and how much drive seeking for components happens during load. None of these are really the cause. The cause is that upstart optimized for fast start up is starting X before the underlying system is ready in some systems and under some circumstances.

Revision history for this message
quequotion (quequotion) wrote :

"The triggering factors of this bug can range from hardware to installed packages to how fragmented your drive is and how much drive seeking for components happens during load. None of these are really the cause. The cause is that upstart optimized for fast start up is starting X before the underlying system is ready in some systems and under some circumstances."

Which means best-case scenario we need to look at reconfiguring upstart.

I was reading https://wiki.ubuntu.com/MeetingLogs/devweek1007/UpstartJobs and came across a good suggestion:

this command:
sudo initctl log-priority info

will cause upstart to output information in /var/log/syslog. I'm going to give it a shot later with & without "sleep 2" and see if I can get any interesting output.

That chatlog also has a few other insights into what may need to be done to get to the bottom of this.

Revision history for this message
Rolf Bensch (rolfbensch) wrote :

While analysing this problem dont't forget that vga16 and nvidia (and other graphic drivers) are sharing the same primary frame buffer device "/dev/fb0" (https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/459639/comments/52).

Vga16 is the first available graphics driver at boot time, and will be replaced by other graphic drivers later on.

In kdm.conf the watched event "graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1" isn't secure if a 2nd graphics driver is used.

To fix this, a new event should be emitted from all graphics drivers or from upstart or from udev or ... as start condition for kdm.conf. And upstart must know if there is any other graphics installed beside vga16 (ok, typically on every home and business pc, but what's about small systems and servers).

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Moved this back to kdm - while I appreciate there is a "Upstart could be better" issue in here, there's more than enough of those filed upstream and I'm hard at work on the next version of Upstart -- there's no quick fix in Upstart for dealing with this kind of sequencing issue yet

The fix for this bug will come from changes to the kdm.conf - the purpose of the PRIMARY_DEVICE_FOR_DISPLAY was to avoid these races - perhaps that udev rule or the kdm config need tweaking to make sure that a device isn't tagged as such when using the nvidia binary driver?

affects: upstart (Ubuntu Lucid) → kdebase-workspace (Ubuntu Lucid)
Revision history for this message
Antonio Barbuzzi (antoniob82) wrote :

Even if I agree with your reasons, actually the bug doesn't affect only kdm, but also gdm, so I'm not sure that kdebase-workspace is the correct place to move it.

Revision history for this message
Alex Murray (alexmurray) wrote :

Indeed, I can confirm this with gdm also so fixing it in upstart would really be best IMHO that way the fix is in all DMs

Revision history for this message
Cesare Mastroianni (cece) wrote : Re: [Bug 459639] Re: X server starts randomly in failsafe when starting from cold boot

Il 14/09/2010 13:21, Jonathan Thomas ha scritto:
> ** Also affects: gdm (Ubuntu)
> Importance: Undecided
> Status: New
>
>

The timing matter ("race conditions" or so) is quite relevant.

Nevertheless, each time I get a update from nvidia drivers my computer
stops to show the bug, and it starts it again only with some other next
update (not always, but often) related to some other packages.

The log today.

Start-Date: 2010-09-15 10:52:16
Upgrade: libsmbclient (3.4.7~dfsg-1ubuntu3.1, 3.4.7~dfsg-1ubuntu3.2),
smbclient (3.4.7~dfsg-1ubuntu3.1, 3.4.7~dfsg-1ubuntu3.2), nvidia-current
(256.52-0ubuntu0sarvatt3~lucid, 260.19.04-0ubuntu0~xup2~lucid),
nvidia-current-modaliases (256.52-0ubuntu0sarvatt3~lucid,
260.19.04-0ubuntu0~xup2~lucid), libwbclient0 (3.4.7~dfsg-1ubuntu3.1,
3.4.7~dfsg-1ubuntu3.2), samba-common (3.4.7~dfsg-1ubuntu3.1,
3.4.7~dfsg-1ubuntu3.2), nvidia-glx-185 (256.52-0ubuntu0sarvatt3~lucid,
260.19.04-0ubuntu0~xup2~lucid), samba-common-bin (3.4.7~dfsg-1ubuntu3.1,
3.4.7~dfsg-1ubuntu3.2), winbind (3.4.7~dfsg-1ubuntu3.1,
3.4.7~dfsg-1ubuntu3.2), nvidia-185-modaliases
(256.52-0ubuntu0sarvatt3~lucid, 260.19.04-0ubuntu0~xup2~lucid),
nvidia-settings (256.44-0ubuntu0sarvatt~lucid,
260.19.04-0ubuntu0sarvatt~lucid)
End-Date: 2010-09-15 10:55:45

After I got new nvidia 185 upgrade, the problem vanished again.

I don't know if this is relevant, I hope this will help to fix the
problem for ever.

Ciao
CM

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

adding to the desktop set of bugs now. Will have a look on Monday if we should workaround it or not with a fresh brain :)

Changed in gdm (Ubuntu Maverick):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Revision history for this message
Romain Motylicki (bronislas) wrote :

Hi,

I tried to improve the loop in #62. I made this though it is far from being perfect and probably quite "dirty" :

    modprobe nvidia
    until lsmod | grep "^nvidia"
    do :
    done

    sleep 2
    exec gdm-binary $CONFIG_FILE

I tried to remove the sleep command, but in that case, X always crashes. So I think that the module needs to be fully loaded.
If it still does not work for you, try to change the delay.

Revision history for this message
VPablo (villumar) wrote :

Today there is a bug fixed very similar to this: #615549
Probably this bug will be a duplicate from that. Hope to be fixed.

Revision history for this message
VPablo (villumar) wrote :
Revision history for this message
quequotion (quequotion) wrote :

>>VPablo
Synaptic just asked me to replace gdm.conf

this has been redone:
- and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
- or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
+ and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udevtrigger))

Looks like what Scott had in mind for a better workaround (I can't call it a fix until it gets into upstart, as I know it will one day).

also it wants to remove my sleep :( ..that said i never sleep much after an upgrade anyway.

Revision history for this message
Alexia Death (alexiade) wrote :

How about kdm?

Revision history for this message
Martin Pitt (pitti) wrote :

This suspiciously sounds like bug 615549, I'll mark this as a duplicate. Please help testing the gdm in lucid-proposed. Thanks!

Revision history for this message
quequotion (quequotion) wrote :

>>Alexia
There must be a similar line in kdm.conf (as gdm.conf is mostly copied from it). look for code like the subtracted part I posted above.

>>Martin
Quite likely. The workaround seems to have my system booting normally again (four successful reboots so far). There are about a dozen other possible duplicates floating around.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdm (Ubuntu Lucid):
status: New → Confirmed
Changed in gdm (Ubuntu Maverick):
status: New → Confirmed
Changed in gdm (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.