Boots to tty1 before login

[Uncle_Snail]

About me: I have been using Linux a few years now, so I generally have some idea of what I'm doing. I am using Linux Mint 18.1 with Cinnamon, and it is a fresh install, as of a few days ago, but I have installed quite a few programs and done a bit of customization (including updating my nvidia graphics drivers to nvidia 340 using the driver manager. This driver is compatible with my card, and it is what I had before the switch to 18.1).

The background: I had the "show desktop" applet error, where the windows become transparent. I couldn't look it up on the Internet at the time, because all my windows were transparent. Thus, I pressed ctrl+alt+F1 to drop into the tty1 terminal. I tried to restart the x server, but I couldn't remember the command correctly (I did not end up doing anything, so I am quite sure I did not wreck anything. It just showed me suggestions of what I might be trying to type). (I know how to restart x now :)
I then switched back to tty7 to see that the problem persisted, and I could not restart (because the restart window was also transparent). Thus, I switched to tty1 and restarted with the "shutdown -r 0" command.

The problem: Now every time I start the computer it boots to tty1 for a few seconds, until the x server starts, and the cinnamon login screen loads. Not only is this annoying, but it seems to be slowing down the boot process by at least a few seconds. Edit: it also shows in tty1 mode after the x server is stopped when shutting down, for a few seconds before the computer turns off.

The follow-up: I tried making sure I was in tty7 before restarting, and testing if that fixed it, but I can't get it right. I don't want to try any of the other solutions I could find, because they are all for people who really "messed things up", and I don't want to reinstall graphics drivers, or cinnamon, or add anything to the grub startup command, because I am pretty sure those have nothing to do with the problem. Probably the answer is quite simple and obvious, I just need the right person to help me. I have switched to tty1 before in Mint 17.2 and I do not think there were ever any problems like this. If grub was automatically edited somehow by me switching to tty1, I'll change it, but I've edited grub before and I wanted to leave it unedited until I really had to change it, because I wanted to leave this install "pure", without any random fixes that may not have been the correct method. It's bound to happen, as I make lots of mistakes, and have to learn, but as far as I can help it, I will leave this install clutter free of incorrect workarounds.

Thanks in advance everyone. The Linux community is really amazing. :)

(note, I do not use my computer on Sunday, so if I do not get back to you right away, I'm sorry.)

[deepakdeshp]

I have the same behaviour too with Mint 18.2

[sgtor]

I'm pretty sure it does that at bootup anyway. It's a console asking for login creds. Are you sure it's not just the same and you're just noticing it now.

One thing you can try is this to see what may be slowing things down at bootup.

Code: Select all

dmesg | grep -i error; dmesg | grep -i warning

[austin.texas]

Now every time I start the computer it boots to tty1 for a few seconds, until the x server starts, and the cinnamon login screen loads. Not only is this annoying, but it seems to be slowing down the boot process by at least a few seconds. Edit: it also shows in tty1 mode after the x server is stopped when shutting down, for a few seconds before the computer turns off.

After it boots to the x session, please run this long, complicated command and post the result.

Code: Select all

w

[Uncle_Snail]

I'm pretty sure it does that at bootup anyway. It's a console asking for login creds. Are you sure it's not just the same and you're just noticing it now.

No, this is different. Normally it hides the terminal anyway, until you change that feature.

[Uncle_Snail]

After it boots to the x session, please run this long, complicated command and post the result.

Code: Select all

w

I don't have time to restart now, and run right after boot, I have to leave for the day.
However, running that code now produces this result.

Code: Select all

09:23:54 up 44 min,  1 user,  load average: 0.02, 0.04, 0.06
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
snail    tty7     :0               08:39   44:20  40.44s  0.09s cinnamon-sessio

[austin.texas]

That shows that there is no login active on tty1 - otherwise, it would be listed.

Code: Select all

 ~ $ w
 09:38:51 up 25 min,  2 users,  load average: 0.12, 0.17, 0.13
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
dan      tty1                      09:38   11.00s  0.09s  0.03s -bash
dan      tty7     :0               09:13   25:12  27.85s  0.26s cinnamon-session --session cinnamon

[sgtor]

That shows that there is no login active on tty1 - otherwise, it would be listed.

Code: Select all

 ~ $ w
 09:38:51 up 25 min,  2 users,  load average: 0.12, 0.17, 0.13
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
dan      tty1                      09:38   11.00s  0.09s  0.03s -bash
dan      tty7     :0               09:13   25:12  27.85s  0.26s cinnamon-session --session cinnamon

I see user dan on tty1

[austin.texas]

I see user dan on tty1

Yes, I am showing you what it looks like when someone is logged in on tty1 - as opposed to your results with no one logged in there.

[sgtor]

my mistake I didn't get the context from the previous post to yours.

[sgtor]

I'm pretty sure it does that at bootup anyway. It's a console asking for login creds. Are you sure it's not just the same and you're just noticing it now.

No, this is different. Normally it hides the terminal anyway, until you change that feature.

I was thinking about what you said here and maybe you did change the grub settings since you mentioned that also. The thing is you would have had to type sudo update-grub to make that happen. What you're describing though sounds like a normal bootup to me since I have the splash screen turned off.
if you run this

Code: Select all

cat /etc/default/grub

and see if it has this in there:
GRUB_CMDLINE_LINUX_DEFAULT=""

If it does that is why you're seeing what you are.

Change it back to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

then you would run

sudo update-grub

[Uncle_Snail]

and see if it has this in there:
GRUB_CMDLINE_LINUX_DEFAULT=""

If it does that is why you're seeing what you are.

Change it back to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

then you would run

No, that line is not there.
It already reads:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Maybe that second line is causing it, but I never ran sudo update grub either, so changes shouldn't have taken affect.

[Uncle_Snail]

That shows that there is no login active on tty1 - otherwise, it would be listed.

True, there is no login on user tty1. What happens is, it shows the tty1 interface asking to log in for a few seconds before it switches to tty7, where I can login normally. I am working on setting up some other fresh installs to test the problem, and try to find the cause. I know this is not the normal behavior, however, and it is not the way the fresh install started out. It began doing this only after switching to tty1 once.
I may also take a video of the startup screen, if that will help, but you may be able to replicate the issue if you switch to tty1, login, then restart. When it boots up again, you may see what I mean.

[austin.texas]

I did that, but could not reproduce the tty1 reference.
I logged out of Mint 18 Cinnamon and got the login screen.
From there I went to tty1 and logged in, then > sudo shutdown -r now
Rebooted to the x session.

Code: Select all

dmesg >> dmesg.txt && xed dmesg.txt

No mention of tty1 in dmesg...

[sgtor]

Did you ever run this to see what errors may be present at bootup?

Code: Select all

dmesg | grep -i error; dmesg | grep -i warning

I have to say again though it just sounds like a normal bootup to me. If it's only slowing by a few seconds it doesn't seem wrong. The bootup process will slow over time as you make certain changes to the system. Just one example is if you add a new mount point into fstab then it's going to slow by a few seconds for the extra time to do that mount.

A video actually would be the best though, it's hard to understand the issue without seeing it since it does sound normal to me.

[Uncle_Snail]

Did you ever run this to see what errors may be present at bootup?

Code: Select all

dmesg | grep -i error; dmesg | grep -i warning

Okay, I ran that, and it seems like that could be a part of the problem. Here is the result.

Code: Select all

[    3.489530] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
[    6.160004] mdmwebkit[1293]: segfault at 8 ip 00007f9765f8582d sp 00007ffc0ebc81d0 error 4 in libGL.so.340.102[7f9765ed7000+c7000]

sda 5 is my root file system partition. It looks like it had trouble mounting for some reason. I'm not sure about the second line, but segfaults are always annoying. It appears something in the new OS is causing a segfault with the most recent nvidia graphics driver, 340.102.
I think here in lies the problem.

If it's only slowing by a few seconds it doesn't seem wrong. The bootup process will slow over time as you make certain changes to the system. Just one example is if you add a new mount point into fstab then it's going to slow by a few seconds for the extra time to do that mount.

This would seem like a reasonable explanation, because except for when upgrading my system or backing things up every now and then, I usually have my external hard drive unplugged. It has about 7 partitions on it that have to be mounted. However, I have booted up several times now with it unplugged and the problem persists, so I do not think that's the issue.

A video actually would be the best though, it's hard to understand the issue without seeing it since it does sound normal to me.

Okay, I will take a video of it once I reboot in a few minutes. I think that would be helpful.
For now though, I will share a picture that I took just now from when I booted up this morning. It would seem the login screen was effected this time as well, which wasn't usually happening. This is not my normal login screen, as I have mine set to the default linux mint login. I will try to get a normal login and see if the segfault and mounting error are still there. Maybe this time there was that issue, and that is causing the login problem, but not the rest. I don't know.
Thanks for all the help and suggestions.

After a reboot, I will try switching back to the Nouveau graphics driver the comes on Mint, and see if the problem persists.

[austin.texas]

Don't worry about the errors=remount-ro line - that seems to be standard.
The segfault line is not normal.

[Uncle_Snail]

Don't worry about the errors=remount-ro line - that seems to be standard.
The segfault line is not normal.

Okay, its good to know the remount isn't an issue. I also did start looking into that segfault a little, but I haven't had the time to really look at it too much yet.

Okay. I just finished up my tests, and it seems the problem has been pinned down. I switched back to the Nouveau drivers and the problem is completely fixed.

It seems the driver is causing some kind of error. I installed it through the driver manager this time, and it was the recommended driver. It is the same driver I was running on Mint 17.2, and I never had a problem there. However, then I had downloaded it from NVidia's web site and installed it manually, manually disabling Nouveau and adding a file to force stop it from running.

From the video I took of the restart I know how long it took the computer to reboot from pressing the start button, and it was about 1 minute. I timed it again now that the problem is fixed, and it was 24 seconds. This is about how long it has always been in the past, even when running the NVidia drivers on 17.2, so I don't think the driver specifically is what was causing the slow down.

The video I took is after the problem changed to also include messing up the login screen, so it does not represent the original problem. However, I will upload a picture of what I am talking about, and explain how it looked right when the problem started, and up until now.

restart screen smaller.png

This would appear when shutting off (where this screenshot was taken) and booting up, for about 2 or 3 seconds. In the past, I have seen text when booting or shutting down, but it has not been the tty1 terminal (as far as I know), and it has been there because of decisions on my part to show it, generally, or when I am doing some kind of special login. By default on Mint, the text is hidden.

I suppose my next step is to try installing the new drivers through a download from NVidia, rather than the driver manager, like I did last time.

It is also worth noting that this means there may be no connection between switching to the tty1 terminal and this issue. However, I think I had installed the drivers and restarted at least once before this issue arose, and then I first noticed it after switching to tty1, and because the issue had to do with tty1 showing on startup, I thought they might be connected, and maybe I switched incorrectly or something. I will also try to discover if I can reproduce the issue using the Nouveau drivers, or if it is only with NVidia.

Thanks again for all the help.

[austin.texas]

I suppose my next step is to try installing the new drivers through a download from NVidia, rather than the driver manager, like I did last time.

NVIDIA: how to install the latest video card drivers

[Uncle_Snail]

Okay. I reinstalled the NVidia drivers through the driver manager, just as before, and tried restarting, to see if the problem was there immediately after installing the drivers.
Nothing went wrong, and everything seems to be working correctly.
I then switched to tty1, and tried restarting from there, attempting to reconstruct the same situation as last time, to see if I got the same error. However, I cannot reconstruct the issue. I have a few more ideas to try out, but for now, it seems as though I can't get the error to be caused again.



Once again, thank you for all the help. Without the community, I may have simply had to live with the error.

(Do you think I should add [solved] to the topic now, because it is fixed for me? We have helped track down the issue, but it is still not entirely clear what caused it. I would say it was a faulty install for just me, and a reinstall fixed it, but it seems deepakdeshp also had this issue, even though I can't reproduce this problem now. I will keep trying to reproduce it for a little while though, and see what I can come up with.)