no autologin Mint 18 Cinnamon

[ehtron]

Hi
on an other machine with lm 18.1 cinnamon, i got the same problem.. sometimes the login screen.
on my main machine also.. at rare intervals.
seems a timing problem with mdm and plymouth.

im checked the services, and see ... /lib/systemd/system/plymouth-quit.service
after rc.local service.

also test.. set a

Code: Select all

sleep 15

into the /etc/rc.local ..
and wow..
autologin works every time..

a way to resolv the problem and finding the problem.

regards ehtron

[Trapper]

Hi

also test.. set a

Code: Select all

sleep 15

into the /etc/rc.local ..
and wow..
autologin works every time..

I can verify this to be the case. At least for me it is on an install I just did earlier this afternoon. Now to see if it holds. Time will tell that.

Also, I am not surprised. I have had suspicion for some time now that something was trying to happen prior to previously things finishing happening.

Thanks ehtron.

[chrisra]

In case anyone still has issues with autologin, what solved the problem for me once was adding my user to the "nopasswdlogin" group.

[Trapper]

Hi

also test.. set a

Code: Select all

sleep 15

into the /etc/rc.local ..
and wow..
autologin works every time..

I can verify this to be the case. At least for me it is on an install I just did earlier this afternoon. Now to see if it holds. Time will tell that.

Although I can verify that the 'sleep 15' does resolve autologin issues I have reverted back to my solution of disabling network manager and utilizing /etc/network/interfaces for my network connection. I have done so because there seems to be a problem between network manager and the dnscrypt-proxy, that I utilize. When utilizing network-manager the specialized nameserver dnscrypt-proxy requires is not honored. /etc/resolv.conf always sets to an incorrect nameserver. I do get autologin using the 'sleep 15' but I do not get internet connection. I have to restart dnscrypt-proxy after bootup to obtain a connection. By changing to /etc/network/interfaces I can remove 'sleep 15' from rc.local and still experience proper autologin along with proper nameserver resolution and proper internet connection.

[Mycr0]

Same here. Autologin refuses to work and changing the screen (on a multi-monitor system) is also ignored.

What I have noticed:
I have 2 systems with an updated LM from older versions => it continues to work
On 2 other systems with fresh installs of LM => fail

This only appears to occur when doing a "hard" boot. When restarting the PC after logging in once, the autologin works.

The following seems to have fixed it one one PC, need to try it on the other:

also test.. set a

Code: Select all

sleep 15

into the /etc/rc.local ..
and wow..
autologin works every time..

Link: viewtopic.php?f=46&t=223597&start=100#p1268727

[Trapper]

What I have noticed:
I have 2 systems with an updated LM from older versions => it continues to work
On 2 other systems with fresh installs of LM => fail

I have had autologin issues with everything from LM 17.3 onward. I do have to admit I have not tried upgrading from 17.2 to whatever may be necessary and then to 18.1. It's on the to do list now.

[Trapper]

Although I can verify that the 'sleep 15' does resolve autologin issues I have reverted back to my solution of disabling network manager and utilizing /etc/network/interfaces for my network connection. I have done so because there seems to be a problem between network manager and the dnscrypt-proxy, that I utilize.

I am providing this post just to update my above comment.

As it turns out, my problem between network-manager and dnscrypt-proxy actually was created by error entrys in dnscrypt-proxy's systemd dnscrypt-proxy.service and dnscrypt-proxy.socket when installing the ubuntu dnscrypt-proxy deb. Simple edits of those 2 files corrected the lack of internet after bootup when utilizing dnscrypt-proxy. Info on that can be found here (in an UPDATE near the end of the page):

http://www.webupd8.org/2014/08/encrypt- ... -with.html

I have reverted back to utilizing network-manager again. I am not using the 15 sleep suggested in another post. I am having proper login success so far. I am also discovering that systemd configuration settings for various apps I install have much to do with autologin failure. Determining what influence they are having on mdm to create the autologin failures is beyond me. Hopefully, with time and experience, app owners and devs will fine tune systemd configuration files to get better app behavior ...... and perhaps a way will be discovered to prevent ill running or misconfigured apps from affecting mdm's autologin.

I just wanted to present this post to state that network-manager turns out to not be a problem for me.

[sleeper12]

This is what worked for me:

In Auto Login Window, check 'Enable Automatic Login' only

Login as administrator to etc.mdm.mdm.conf

Set 'Timed Login Enable' to false

Add this line above [security]: SelectLastLogin=true

Save & reboot your system

[Trapper]

This is what worked for me:
In Auto Login Window, check 'Enable Automatic Login' only
Login as administrator to etc.mdm.mdm.conf
Set 'Timed Login Enable' to false
Add this line above [security]: SelectLastLogin=true
Save & reboot your system

I am testing this on LM18.1 MATE 64 bit. So far it is holding okay. This is the content of my /etc/mdm/mdm.conf. Is it in line with yours?

Code: Select all

[daemon]

AutomaticLoginEnable=true

AutomaticLogin=trapper

TimedLoginEnable=false

SelectLastLogin=true

[security]

I'll keep this setup as long as autologin works and I will let you know if I experience an autologin failure.

[Cosmo.]

I think, that is now only waste of time to investigate this further. Mint 18.2 will bring a new display manager and the chances, that there will ever come a fix for LM 18 / 18.1 appear as zero.

[sleeper12]

Trapper, yes that is same as mine. For me, this is the fix...so far anyway.

[sleeper12]

Forgot to mention I still have TimedLoginDelay=10 listed as well. Probably doesn't matter since it's set to false anyway,

[Trapper]

Trapper, yes that is same as mine. For me, this is the fix...so far anyway.

Okay. I have this set up on 2 boxes now that I had been using lightdm previously to prevent the autologin failure. I will keep testing this. Cosmo. is right regarding the switch to a new display manager in 18.2 and continuing researching this might seem moot. I still continue to try mine and others ideas though. The only thing I have found that worked 100% so far is replacing mdm with lightdm. It would be awesome if your suggestions resolved the problems. So far it's promising.

[sleeper12]

I'm on LM 18 with 2 laptops and this fix seems to have worked on both. If any change, I'll post here. But, I suspect all is fine now. I was getting the 'select a user' screen on most every boot before, but no more. Just hope I haven't jinxed it now...Lol!

[sleeper12]

Well, the jinx is on. I just got the 'select a user' login screen again on one laptop. So, it seems this isn't a true fix after all even though it's still holding on my other machine. Sorry 'bout that.

[Trapper]

Well, the jinx is on. I just got the 'select a user' login screen again on one laptop. So, it seems this isn't a true fix after all even though it's still holding on my other machine. Sorry 'bout that.

It's still holding on both of my machines with the mdm.conf I have. That's the weirdness that's persisted since LM 17.3. Things work well for a time but then go south. Sometimes temporarily or sometimes permanently. Some people never experience the problem but others are majorly plagued. Look how long this thread is, how many different things are experienced and what a wide assortment of unsuccessful workarounds/fixes have been tried. Some things work for some people but not for others. The only common denominators are a combination of mdm and systemd. The problem does not seem to exist with other display managers and also didn't exist prior to systemd.

A side thought that doesn't apply to the above: I note that the only way I can get my current configuration written to mdm.conf is to do it manually. It doesn't write out correctly for me if done through the gui.

[sleeper12]

Yeah, it's a strange bug for sure. I decided to try placing 'SelectLastLogin=true' first in mdm.conf on the machine that failed. It's working, but too soon to tell if it will hold.

[Trapper]

Yeah, it's a strange bug for sure. I decided to try placing 'SelectLastLogin=true' first in mdm.conf on the machine that failed. It's working, but too soon to tell if it will hold.

Well, here's the thing; Bright and early this AM I started one of the machines and up pops the mdm login screen. After login I rebooted and this time I got a proper auto login. In my case I adjusted nothing in mdm.conf and my results were the same as yours. All I am saying is that maybe relocating 'SelectLastLogin=true' was helpful for you but maybe it really wasn't.

I've always had the experience of the login screen every once in a while. I used to be presented with it all the time until I made adjustments to systemd related files for clamav and dnscrypt-proxy. After that I usually had proper auto login but every now and then I'd still get an auto login failure. I strongly suspicion this mdm problem is somehow related to apps that require connection to the internet during start up.

The only way I totally resolved the auto login failure issue was by switching to lightdm as the default display manager. Eventually I went so far as to actually remove mdm because occasionally it would revert itself back to being the default display manager without any interaction from me.

[sleeper12]

Ok, I'll just wait & see what happens with my current setup. As you indicated, it's very difficult to test since the login screen only pops up now & then. If it appears again, I'll just go back to the timed login. I can live with that I suppose.

[sleeper12]

The login screen came back on one machine, so I switched to timed login on that one. Autologin is holding on the other machine, so I'll leave it as is for now. Seems to me there must be a difference between the two machines entries, but darned if I know what it is.