Comment 33 for bug 625239

@Jamie:

Since I'm only another member of the community it's completely possible that I won't be able to see this through to a fix. A glance from a plymouth or gdm developer may mean more progress than I could make in days. If it's ok with you, though, maybe we can move this towards a successful triage state on our own so it will be easy for a developer to find the problem. I appreciate your willingness to try things. I may not recognize when we have enough info.

I think your reply was very interesting.

1. You have a system that flies. This bug may be a problem caused by a race condition. A faster system may have different results than a slower one. How many processors or cores does your system have? What speed? I ask this to look for correlations between your report and those by others.

2. You are configured to use splash and it is working.

3. The timestamp on your file is correct. Because you were occasionally starting on tty2, I had myself half convinced that it would have an old date and that gdm wasn't even trying to start on the same virtual terminal as plymouth. It may be that gdm thinks plymouth's active terminal is tty1 (or maybe even tty2).

4. Between the time you see the splash and you see the login you see a blink. There isn't supposed to be a blink. That may be where your virtual console is switching from tty7 to tty1 and X is sealing its fate by starting there (or may not).

Some basics first:

You said you are running plymouth version plymouth 0.8.2-2ubuntu2. What version of gdm and upstart are you running?

Next:

Could you try adding the boot option plymouth:debug in grub and on that boot recreate the problem? Could you then attach the plymouth debugging log, gdm log, and the log from the failing X. It will probably be in Xorg.0.log.old after you restart. The failing X log will contain a traceback and say something about a quit signal or another signal depending upon the key you pressed when it crashed.

@Dino:
If you are still with us. Would you mind terribly telling us, when it fails for you, what you see? What versions of plymouth, gdm, and upstart are you running? What is your computer like? Like Jamie, does the creation time of /var/run/gdm/firstserver.stamp match the login time (it should). I'm just trying to confirm there aren't two separate underlying reasons for starting X on tty1 or tty2.

Warning: If this is a race condition just adding plymouth:debug might change the timing and "fix" the problem by slowing plymouth down. The logs may still be helpful. I'm thinking that it's a race condition and that Dino's compiz experiment changed the timing. I certainly may be wrong.

The purpose of the logs is to make sure plymouth is running on tty7 as expected, to see if gdm is asking if plymouth is active on plymouth's virtual terminal, and to watch where X starts. The idea is to get an idea where things get directed to tty1. We won't need the auth logs. They simply helped establish the interference from the getty process. We already know if you are starting X on tty1 that we have this problem.

Whether you each have the time and inclination to continue on with me or not, thanks to you both for posting your experiences.