No graphical login. boot.log: MDM started twice: 1st OK; 2nd fail

Bug #1333314 reported by Manuel Iglesias Alonso
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linux Mint
New
Undecided
Unassigned

Bug Description

Cinnamon Mint 17 Qiana, x86_64, nvidia GeForce GT 220, proprietary driver: nvidia-331.
Always happens: Graphical login never appears.
Checking /var/log/boot.log it seems mdm is started twice: {
...........................
 * Stopping anac(h)ronistic cron[ OK ]
 * Loading cpufreq kernel modules...  [ OK ]
 * Starting MDM Display Manager[ OK ]
 * Stopping Send an event to indicate plymouth is up[ OK ]
 * CPU0...  * CPU1...  * CPU2...  * CPU3...  * CPUFreq Utilities: ...  [ OK ]
 * Starting MDM Display Manager[fail]
 * Starting Postfix Mail Transport Agent postfix  [ OK ]
...........................
}
Running (as root)
/etc/init.d/mdm start
Starts mdm all right and graphical login screen appears.
Adding '/etc/init.d/mdm start' to /etc/rc.local solves (temporarily) the problem.
Likely position of '2 * mdm start' in /var/log/syslog: {
...........................
Jun 23 13:13:47 Linux-2 anacron[1328]: Normal exit (0 jobs run)
Jun 23 13:13:47 Linux-2 acpid: 9 rules loaded
Jun 23 13:13:47 Linux-2 acpid: waiting for events: event logging is off
Jun 23 13:13:47 Linux-2 postfix/master[1660]: daemon started -- version 2.11.0, configuration /etc/postfix
...........................
}
Note:
If mdm debug is enabled, there is (in syslog) only debug information after /etc/rc.local has been invoked.

Tags: mdm
Revision history for this message
Manuel Iglesias Alonso (glesialo) wrote :
Revision history for this message
Clement Lefebvre (clementlefebvre) wrote :

hi Manuel,

In Mint, MDM shouldn't be started by init.d but by upstart.

So it shouldn't have files in /etc/rc2.d but just have /etc/init/upstart.conf

In LMDE it's the other way around. There we don't use upstart but init.d.

Can you check whether you're booting with upstart, and that MDM doesn't provide any files in /etc/rc2.d ?

Revision history for this message
Manuel Iglesias Alonso (glesialo) wrote :

Have to leave now, will check it later, but here is a listing: {
for dir in /etc/rc?.d; do FindAllFiles $dir; done
/etc/rc0.d/K10unattended-upgrades
/etc/rc0.d/K20hddtemp
/etc/rc0.d/K20kerneloops
/etc/rc0.d/K20postfix
/etc/rc0.d/K20rsync
/etc/rc0.d/K20speech-dispatcher
/etc/rc0.d/K20virtualbox-guest-utils
/etc/rc0.d/README
/etc/rc0.d/S20sendsigs
/etc/rc0.d/S30urandom
/etc/rc0.d/S31umountnfs.sh
/etc/rc0.d/S40umountfs
/etc/rc0.d/S59cryptdisks-early
/etc/rc0.d/S60umountroot
/etc/rc0.d/S89casper
/etc/rc0.d/S90halt
/etc/rc1.d/K20hddtemp
/etc/rc1.d/K20kerneloops
/etc/rc1.d/K20postfix
/etc/rc1.d/K20rsync
/etc/rc1.d/K20saned
/etc/rc1.d/K20smartmontools
/etc/rc1.d/K20speech-dispatcher
/etc/rc1.d/K20virtualbox-guest-utils
/etc/rc1.d/README
/etc/rc1.d/S30killprocs
/etc/rc1.d/S70dns-clean
/etc/rc1.d/S70pppd-dns
/etc/rc1.d/S90single
/etc/rc2.d/README
/etc/rc2.d/S05loadcpufreq
/etc/rc2.d/S19cpufrequtils
/etc/rc2.d/S20hddtemp
/etc/rc2.d/S20kerneloops
/etc/rc2.d/S20postfix
/etc/rc2.d/S20rsync
/etc/rc2.d/S20smartmontools
/etc/rc2.d/S20speech-dispatcher
/etc/rc2.d/S20virtualbox-guest-utils
/etc/rc2.d/S50saned
/etc/rc2.d/S70dns-clean
/etc/rc2.d/S70pppd-dns
/etc/rc2.d/S99grub-common
/etc/rc2.d/S99ondemand
/etc/rc2.d/S99rc.local
/etc/rc3.d/README
/etc/rc3.d/S05loadcpufreq
/etc/rc3.d/S19cpufrequtils
/etc/rc3.d/S20hddtemp
/etc/rc3.d/S20kerneloops
/etc/rc3.d/S20postfix
/etc/rc3.d/S20rsync
/etc/rc3.d/S20smartmontools
/etc/rc3.d/S20speech-dispatcher
/etc/rc3.d/S20virtualbox-guest-utils
/etc/rc3.d/S50saned
/etc/rc3.d/S70dns-clean
/etc/rc3.d/S70pppd-dns
/etc/rc3.d/S99grub-common
/etc/rc3.d/S99ondemand
/etc/rc3.d/S99rc.local
/etc/rc4.d/README
/etc/rc4.d/S05loadcpufreq
/etc/rc4.d/S19cpufrequtils
/etc/rc4.d/S20hddtemp
/etc/rc4.d/S20kerneloops
/etc/rc4.d/S20postfix
/etc/rc4.d/S20rsync
/etc/rc4.d/S20smartmontools
/etc/rc4.d/S20speech-dispatcher
/etc/rc4.d/S20virtualbox-guest-utils
/etc/rc4.d/S50saned
/etc/rc4.d/S70dns-clean
/etc/rc4.d/S70pppd-dns
/etc/rc4.d/S99grub-common
/etc/rc4.d/S99ondemand
/etc/rc4.d/S99rc.local
/etc/rc5.d/README
/etc/rc5.d/S05loadcpufreq
/etc/rc5.d/S19cpufrequtils
/etc/rc5.d/S20hddtemp
/etc/rc5.d/S20kerneloops
/etc/rc5.d/S20postfix
/etc/rc5.d/S20rsync
/etc/rc5.d/S20smartmontools
/etc/rc5.d/S20speech-dispatcher
/etc/rc5.d/S20virtualbox-guest-utils
/etc/rc5.d/S50saned
/etc/rc5.d/S70dns-clean
/etc/rc5.d/S70pppd-dns
/etc/rc5.d/S99grub-common
/etc/rc5.d/S99ondemand
/etc/rc5.d/S99rc.local
/etc/rc6.d/K10unattended-upgrades
/etc/rc6.d/K20hddtemp
/etc/rc6.d/K20kerneloops
/etc/rc6.d/K20postfix
/etc/rc6.d/K20rsync
/etc/rc6.d/K20speech-dispatcher
/etc/rc6.d/K20virtualbox-guest-utils
/etc/rc6.d/README
/etc/rc6.d/S20sendsigs
/etc/rc6.d/S30urandom
/etc/rc6.d/S31umountnfs.sh
/etc/rc6.d/S40umountfs
/etc/rc6.d/S59cryptdisks-early
/etc/rc6.d/S60umountroot
/etc/rc6.d/S89casper
/etc/rc6.d/S90reboot
/etc/rcS.d/README
/etc/rcS.d/S25brltty
/etc/rcS.d/S26cryptdisks-early
/etc/rcS.d/S45virtualbox-guest-x11
/etc/rcS.d/S47lm-sensors
/etc/rcS.d/S51mintsystem
/etc/rcS.d/S55urandom
/etc/rcS.d/S70x11-common
}

Revision history for this message
Manuel Iglesias Alonso (glesialo) wrote :

Only '/etc/init/mdm.conf': {
...................
start on ((filesystem
           and runlevel [!06]
           and started dbus
           and plymouth-ready)
          or runlevel PREVLEVEL=S)
...................
}

Revision history for this message
Manuel Iglesias Alonso (glesialo) wrote :

If you check the (attached) '/var/log/boot.log' file, there is another service, started twice, that also fails the second time: {
* Starting network connection manager[ OK ]
 * Starting SMB/CIFS File and Active Directory Server[ OK ]
 * Starting SMB/CIFS File and Active Directory Server[fail]
 * Setting up X socket directories...  [ OK ]
}

Here are the starting conditions of '/etc/init/smbd.conf': {
...................
start on (local-filesystems and net-device-up)
...................
}

What are the starting conditions of '/etc/init/mdm.conf' and '/etc/init/smbd.conf' in a working system?

Revision history for this message
Manuel Iglesias Alonso (glesialo) wrote :

[Solved]
I updated to kernel ' 3.13.0-30-generic' (because about once every ten times my computer didn't poweroff after shutdown -still testing with the new kernel) and the MDM bug has gone.
I had added some bash lines to '/etc/rc.local' so that MDM was started only if it wasn't running. Before the kernel update MDM (and other services) was started, sometimes, as many as six times (one after the other as registered in '/var/log/boot.log') and '/etc/rc.local' always had to start it again. Now, after the kernel update, there isn't a 'Starting MDM... [fail]' in '/var/log/boot.log' and '/etc/rc.local' never has to start MDM.

Revision history for this message
Carlos Martini (carlos-mendesmartini) wrote :

Hello,

Same problem happened here just today.

My workaround was to edit the file:

/etc/init/mdm.conf

And comment out the line:

test -f /etc/profile && . /etc/profile

After reboot, the problem was solved.

Just in time:

carlos@Tecnologia ~ $ uname -a
Linux Tecnologia 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

So, I'll try to update kernel next week.

Revision history for this message
Carlos Martini (carlos-mendesmartini) wrote :

Hello, again.

Bad and sad news.

Same problem with my netbook Asus, kernel 3.13.0-32.

I commented out that line in order to fix it.

Revision history for this message
Sem Brignoli (hamacaweb) wrote :

Same Problem here after kernel update, i`m commenting from live CD, i`m adding comment in mdm.conf

Revision history for this message
Claudio Negri (ngrcld) wrote :

Same problem here, in Linux Mint 17 without proprietary video card drivers.
It happened after latest updates (I did all the updates, from level 1 to level 5).
The workaround from Carlos Martini works for me.

Revision history for this message
Emil Chou (emiljou) wrote :

Same problem happened to me today.

I'm using Linux Mint 17.1 X64 with kernel 3.16.0-28. I also tried to load system with older kernel from grub menu but without luck.

Fortunately the workaround from Carlos Martini works for me.

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.