Plymouth text-mode splash causes X to crash on first run due to shared tty7

This appears to be caused by stty calls in the init scripts that reset the isig flag on the current VT, which means the VT gets a SIGQUIT when Enter is pressed. I'm working on trying to confirm this scenario is the cause.

References:

http://<email address hidden>/msg07800.html
http://people.gnome.org/~michael/blog/2009-05-29.html

I think this theory has some legs. I had noticed some apparently random characters showing up on VT7 after stopping gdm manually during debugging.

I've now restarted the PC several times, not touched the keyboard until the gdm log-in screen appears. Select the user with the mouse and then begin typing the password. After 3 characters xserver crashes and restarts.

Use another tty to "sudo stop gdm" then Ctrl+Alt+F7. Once VT7 text console is revealed it shows a few kernel log messages from the drm driver (see bug #342122 "[i815] [drm:drm_release] *ERROR* reclaim_buffers_locked() deadlock") but, more importantly, there's some *quasi-random* characters appearing and, in most cases, they are the same across reboots - suggesting they are generated.

They look to be partial control-code representations.

E.g: " ^X ^C
or: ^]^]^]^]^]^]^]^]^]^]88888888888888888888888888 8888888888;

The latter happens if, as soon as the log-in dialog appears, I switch away to VT1 (Ctrl+Alt+F1), log-in, then "sudo stop gdm" and then Ctrl+Alt+F7.

If I stop the gdm process from a remote ssh session these characters don't show up.

So as not to lose this possibly useful snippet: If my password contains a numeral the crash happens as soon as that numeral is typed; otherwise the crash happens when I press Enter. E.g "my2pennies4" causes the crash when I press "2" whereas "letmeinnow" doesn't cause a crash until I press Enter.

I'm wondering if this might be caused by the automatically detected input devices?

$ egrep '(Adding input device|PreInit)' /var/log/Xorg.0.log
(II) config/udev: Adding input device "Video Bus" (/dev/input/event6)
(II) config/udev: Adding input device "Sony Vaio Keys" (/dev/input/event4)
(II) config/udev: Adding input device "Power Button" (/dev/input/event1)
(II) config/udev: Adding input device "AT Translated Set 2 keyboard" (/dev/input/event3)
(II) config/udev: Adding input device "PS/2 Mouse" (/dev/input/event7)
(II) config/udev: Adding input device "PS/2 Mouse" (/dev/input/mouse2)
(EE) PreInit returned NULL for ""PS/2 Mouse""
(II) config/udev: Adding input device "AlpsPS/2 ALPS GlidePoint" (/dev/input/event8)
(II) config/udev: Adding input device "AlpsPS/2 ALPS GlidePoint" (/dev/input/mouse3)
(EE) PreInit returned NULL for ""AlpsPS/2 ALPS GlidePoint""
(II) config/udev: Adding input device "Macintosh mouse button emulation" (/dev/input/event2)
(II) config/udev: Adding input device "Macintosh mouse button emulation" (/dev/input/mouse0)
(EE) PreInit returned NULL for ""Macintosh mouse button emulation""

I've been progressively disabling the input devices to discover if one of them may be the culprit via "/lib/udev/rules.d/65-xorg-evdev.rules" until everything but the GlidePad was disabled:

$ egrep '(Adding input device|PreInit)' /var/log/Xorg.0.log
(II) config/udev: Adding input device "AlpsPS/2 ALPS GlidePoint" (/dev/input/event8)

Using the GlidePad I clicked on the user-name to log-in, then began typing the password ("my2pennies4"). No password input markers show up (since the keyboard is not driven by evdev) *BUT* as soon as I press the "2" xserver crashes.

This seems to confirm that *something* is attached to tty7 and is processing the input instead of evdev - and then quitting (the SIGQUIT [signal 3] reports seem to confirm that).

This is the hacked udev rules file used at this point.

----- /lib/udev/rules.d/65-xorg-evdev.rules -----
ACTION!="add|change", GOTO="xorg_evdev_end"

# By default, we use the -evdev driver for every mouse, keyboard, touchscreen
# or touchpad; later rules can then change the driver for specific input
# devices.
ENV{ID_INPUT}=="", GOTO="xorg_evdev_end"
ENV{ID_INPUT}!="", GOTO="xorg_evdev_end"

ATTRS{name}=="Video Bus", GOTO="xorg_evdev_end"
ATTRS{name}=="Macintosh mouse button emulation", GOTO="xorg_evdev_end"
ATTRS{name}=="PS/2 Mouse", GOTO="xorg_evdev_end"
ATTRS{name}=="Sony Vaio Keys", GOTO="xorg_evdev_end"
ATTRS{name}=="Power Button", GOTO="xorg_evdev_end"
ATTRS{name}=="AlpsPS/2 ALPS GlidePoint", KERNEL=="mouse*", GOTO="xorg_evdev_end"
ENV{ID_INPUT_MOUSE}=="?*", ENV{x11_driver}="evdev"
ENV{ID_INPUT_KEY}=="?*", ENV{x11_driver}="evdev"
ENV{ID_INPUT_TOUCHSCREEN}=="?*", ENV{x11_driver}="evdev"
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_driver}="evdev"

LABEL="xorg_evdev_end"

Further support for the supposition that another process is waiting for input events from the keyboard: using the accessible on-screen keyboard it is possible to log-in first time.

Putting together the keys that cause the reset with those that are ignored, it appears that whatever is listening to the keyboard is ignoring alpha but expecting a single numeral or Enter. What is more, the *only* numeral I find causes this reset is "2" - it seems beyond coincidence, but I've tried pressing 1,3,4,5,6,7,8,9,0 without xserver restarting, but as soon as "2" is pressed it happens.

Changing my user password to "my1pennies3" and clicking the "Log In" button (rather than pressing the Enter key on the keyboard), the xserver doesn't crash!

With the session started I was prompted for the password to the keyring (which was set to the original user password). As soon as I pressed "2" in the dialog the xserver restarted.

Strangest bug I ever did see!

Lovely, by that I mean I can confirm that with the '2', I experimented
with valid and invalid passwords, the problem is only happening with
the number 2 in the 6th poition of my password.

My crash happens as I type the 2, don't need to hit enter.
If the password is not valid one, then it does not crash either.

So it's a really weird one indeed!

Sean

On Saturday, March 6, 2010, TJ <email address hidden> wrote:
> Further support for the supposition that another process is waiting for
> input events from the keyboard: using the accessible on-screen keyboard
> it is possible to log-in first time.
>
> Putting together the keys that cause the reset with those that are
> ignored, it appears that whatever is listening to the keyboard is
> ignoring alpha but expecting a single numeral or Enter. What is more,
> the *only* numeral I find causes this reset is "2" - it seems beyond
> coincidence, but I've tried pressing 1,3,4,5,6,7,8,9,0 without xserver
> restarting, but as soon as "2" is pressed it happens.
>
> Changing my user password to "my1pennies3" and clicking the "Log In"
> button (rather than pressing the Enter key on the keyboard), the xserver
> doesn't crash!
>
> With the session started I was prompted for the password to the keyring
> (which was set to the original user password). As soon as I pressed "2"
> in the dialog the xserver restarted.
>
> Strangest bug I ever did see!
>
> --
> Xorg crashed at first login attempt
> https://bugs.launchpad.net/bugs/532047
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “xorg-server” package in Ubuntu: In Progress
>
> Bug description:
> Binary package hint: xorg
>
> Ubuntu Lucid, Gnome edition 64-Bit Alpha3 + Updates installed in Virtualbox.
>
> At Ubuntu login, click on Username and enter password,
> after the first keystroke of the password, X crashes and starts again.
> The next login attempt works flawlessly.
>
> ProblemType: Bug
> Architecture: amd64
> CurrentDmesg:
>  [   18.510206] eth0: no IPv6 routers present
>  [   41.740240] end_request: I/O error, dev fd0, sector 0
>  [   41.770924] end_request: I/O error, dev fd0, sector 0
>  [   42.865977] ISO 9660 Extensions: Microsoft Joliet Level 3
>  [   43.322226] ISO 9660 Extensions: RRIP_1991A
> Date: Thu Mar  4 18:26:24 2010
> DistroRelease: Ubuntu 10.04
> DkmsStatus: Error: [Errno 2] No such file or directory
> InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100224.1)
> Lsusb:
>  Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> MachineType: innotek GmbH VirtualBox
> Package: xorg 1:7.5+1ubuntu12
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-15-generic root=UUID=fefa9a42-a546-42c3-984a-c873258026d8 ro quiet splash
> ProcEnviron:
>  PATH=(custom, no user)
>  LANG=de_AT.UTF-8
>  SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.32-15.22-generic
> SourcePackage: xorg
> Uname: Linux 2.6.32-15-generic x86_64
> dmi.bios.date: 12/01/2006
> dmi.bios.vendor: innotek GmbH
> dmi.bios.version: VirtualBox
> dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:
> d...

I can say the following:
- It does not matter what password (length, strength) was set at install.
- When I enter the number 2, X crashes.
- It does not matter where (at what position) in the password the number 2 is pressed.
- (this bug is not in Kubuntu)

Thanks for the confirmation Sean and tankdriver - after a 16 hour debugging session I was beginning to doubt my own findings!

I have a couple of ideas as to how this is happening, and where to look.

I've discovered that an obscure interaction between plymouth graphical boot splash and X, when plymouth falls back to text mode, is the cause of this strange behaviour.

A temporary workaround is to disable plymouth-splash:

sudo mv /etc/init/plymouth-splash.conf /etc/init/plymouth-splash.conf.disabled

The workaround works for me.
Thank you.

This is not an X bug, this is a well understood bug in plymouth that is in the process of being fixed.

I can confirm that hitting the "2" key at any time after initial system boot will crash X. On my system, the Enter key will NOT crash X. So if I change my password to anything that does not contain the number 2, X will boot into the Gnome desktop. Ubuntu will work perfectly fine until, whenever, wherever, you press the "2" key. At that point, you get the X crash and are dumped back to the log-in screen. After the second log-in, everything is fine.

I don't know what information is required about my system, so I will give the basics: Dell Latitude D830 notebook, NVidia Quadro NVS graphics, Core 2 Duo CPU, 4 GB RAM, Lucid x64 ("clean" install from Alpha3 Live CD plus all patches/updates). NVidia proprietary drivers (195). (Plymouth splash is not working for me)

I've had this bug for a long time, but since yesterday, it doesn't crash anymore!

Pressing Enter causes a crash. This effects me too. It happens:

a) At first login after I press the Enter key. Then there is a crash and I am back at the login screen. Then after the second login the Enter works properly.

b) After first login when I avoided to press the Enter and used a mouse click on the Login button instead. Then I am logged and after pressing the Enter there is a crash and I am back at the login screen. Then after the second login the Enter works properly.

The temporary workaround intended to disable plymouth-splash:
sudo mv /etc/init/plymouth-splash.conf /etc/init/plymouth-splash.conf.disabled

does not work for me, because there is no /etc/init/plymouth-splash.conf file on my installation.

Running: OS Ubuntu 10.04 alpha 3 64-bit fully updated ...

On Mon, Mar 08, 2010 at 08:01:55PM -0000, VladimirCZ wrote:
> The temporary workaround intended to disable plymouth-splash [...]
> does not work for me, because there is no /etc/init/plymouth-splash.conf
> file on my installation.

Why isn't there? It's part of the plymouth package; if you have plymouth
installed you should have this file, and if you don't have plymouth
installed you don't have this bug.

If you have plymouth installed and have removed the file... you shouldn't do
that. You will need to purge the plymouth package and reinstall it (sudo
apt-get purge plymouth; sudo apt-get install plymouth) to restore the
missing conffile.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I still have this bug.

I followed the Steve Langasek's instructions:
1) purge and install the plymouth package
2) checked the /etc/init/ folder and found a few new plymouth related files that had not been there before
3) restarted PC and faced the same double loging problem
4) then executed: sudo mv /etc/init/plymouth-splash.conf /etc/init/plymouth-splash.conf.disabled
5) restarted PC and the workaround works since then = single login

But a questions stays: Why there were not the plymouth related files before?
In Synaptic the package was marked as installed, but the files were missing.
I just installed Alpha 3 64-bit and then updated it several times.
I made no operations via terminal that could remove the files.
So it must have been some installation / update bug ...

The workaround didn't worked for me. It fixes the problem only a few seconds after the system startup, when i can press 2 or enter as often as i want. But a few (minutes) later, hitting enter crashes the system again (for only one time).

I tried the above instructions and while the bug is fixed for the login screen, when I press Enter the first time during the session X crashes.

I believe it may be related to the most recent kernel (2.6.32-16), as before I updated to this kernel, I never experienced this issue, but afterwards, I will login from GDM only to have it reset and I have to enter my password again. Sometimes it doesn't even go to the GDM screen, but it shows a TTY screen with strange characters.

Madde, Matteo: I've had both the login problem, and the later "Enter or 2" problem. The difficulty is the keyboard scancodes, so different keyboards can have different triggers if the keyboards have different scancode assignments.

Whenever it happens later, it seems that my crashed X session had been on tty1 (VT1) rather than on tty7 (VT7) or higher. I suspect this symptom might involve the getty program (and maybe plymouth as well).

If your /var/log/Xorg.0.log.old file is still around from the crash I wonder if you could check the beginning of the file to see on what VT X had started (and save it somewhere for possible posting later)?

I've had trouble reproducing the VT1/late crash problem since uninstalling and reinstalling plymouth, but as I typed this reply the first time a few minutes ago X crashed when I typed "2". (Whew!). I checked my session and it had started on tty1 and thus had been vulnerable to whatever getty had been doing to tty1.

There are reports on the situation with late (after the problem key had previously been pressed in an X session--login or after) in LP: #529230. In both my case, and the case of the original reporter, X had started on tty1 (VT1). I don't know about the new case.

I wonder if this late crash problem is related to the situation closed for karmic in LP: #396226.

Interesting.
- My Xorg.0.log.old file says that X session --which crashed-- was running on VT7.
- The current Xorg.0.log file says the present, stable X session is running on VT8.

There is a bug for the random characters on the tty: Bug 535316

I have the same issue. According to the Xorg.0.log and Xorg.0.log.old files, my first X session was running on VT1 and my second one on VT7.

When I switch to VT1 after the second login, I can see what seems to be a unsuccesful attempt to log in :

init: unreadahead-other main process (717) terminated with status 4

Ubuntu lucid (development branch) daedalus tty1

daedalus login: ***
                   Password:

Ubuntu lucid (development branch) daedalus tty1

daedalus login:

The VT7 and VT8 I reported earlier were for my desktop (fresh 64-bit install, binary nvidia driver, text-mode plymouth). My laptop (fresh 32-bit install, Intel 945GM, graphical-mode plymouth) also has VT7 for the crashy session and VT8 for the working one according to the log files.

Does anyone else see VT7 and VT8 in their Xorg.0.log[.old] files? I use autologin in both, BTW.

Seems to be fixed for me now since I updated initscripts, sysv-rc and sysvinit-utils in an update today.

@ManhattanOS: not in my case. The patch sysvinit-utils received was related to unkillable processes at shutdown, which seems unrelated. This bug is somewhat intermittent -- how many times did you successfully reboot cleanly into the desktop/login screen?

Ben, what you are seeing is bug 535316.

@Noel: yes it is.

Are the two bugs related somehow ?

I also suffer this problem.
Xorg.0.log: VT 7
Xorg.0.log.old: VT 8

Would this explain why the login screen appears on my right hand ( of dual screen setup) and when I hit enter it appears on the left hand screen and I have to login again?
The second login works.

I have similar problem, but I can get past GDM with Enter with ease, but when working, writing something in console or text editor, after some random enter it crashes. I think reason is the same - Plytmouth.

@Tony: the right hand/left hand login screen bug is covered in bug #395314 (there's a workaround in comment 11, https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/395314/comments/11).

@Pēteris, yes, those are Bug 535318 and Bug 535316, which are really duplicates, since the latter is the cause of the former.

@Pablomme So far I must've rebooted a dozen or so times. I have not seen this issue recurring, yet it was affecting me before. Unless it is a bug with very similar problems. For me, it seems to have been solved.

This bug seems to be inconsistent. I will go for several days without having any issues, but then I'll have it again for a few reboots. I have not been able to correlate the behavior with any updates, but I'm not convinced that the behavior disappearing for several reboots necessarily means that the problem has been resolved.

I still have it all the time. Last Lucid update was Tuesday.

Sean

Hy!

I'm having this issue with the NVIDIA 173 (not nvidia-current because of Bug #534754) driver and an up2date lucid...
And yes I have cryptsetup installed (with pammount for my luks encrypted home)...

How can I help?

I read here: "plymouth (Ubuntu) Fix released. Milestone Ubuntu 10.04-beta1"
There has no fix arrived here.
My X still sometimes appears on my 1st and sometimes on my 8th virtual console.
'~$ uname -a; Linux T42 2.6.32-17-generic #26-Ubuntu SMP Fri Mar 19 23:58:53 UTC 2010 i686 GNU/Linux'

When I put my notebook in docking-station, with secondary monitor attached, I still get the same behavior as before (have to press Alt-SysRq-K to get X restart). The bug is fixed for me when booting WITHOUT secondary monitor attached. So it seems that Plymouth doesn't work correctly with multiple screens.
Any idea?
I'm using Nouveau-driver.

I have installed Lucid Lynx final release (system if fully updated right now) and this bug persists :-( Whenever I boot and press <Enter> or <2> X crashed and restart, It's annoying !

Horrible bug, affects me too

Still borked here, as of latest Lucid, long after "final" release.

WTF is going on ????

This bug has been fixed for a long time. However, the latest update breaks maverick once again. Please note that I have removed "quiet splash" from the boot params as I personally hate the splash, so Plymouth doesn't seem to be causing it. This has started happening only today after update, with X started on tty7, killed with "enter", then restarted on tty8.

This is broken for me as well.

Same problem, filed bug #625239 about problem in maverick, however I think this one is the correct bug.

Is this change the problem causer?

      + 121_only_switch_vt_when_active.diff:
        Add a check to prevent the X server from changing the VT when killing
        GDM from the console.

Subscribed RAOF as it appears this is a regression from the last upload.

As Scott said, we need to file a new bug about this issue. I tried the workaround given in this bug description and it worked, which meansthat the problem is affecting Plymouth once again.

Looks like the regression in Maverick has been filed as bug #625239
and has been marked as confirmed.

Sorry if this is not the right bug to comment on, but I spent hours yesterday just trying to figure out where I should be commenting. I just commented on bug #529230 (comments 21 and 22) because that seems the best fit, but it's listed as a duplicate of this bug. This bug's description does not fit my issue as closely, and the temporary workaround does not help me. I did, however, see a very slight difference in behavior relating to the suggested workaround, as commented here:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/529230/comments/22

I would very much appreciate it if someone could just help point me in the right direction. If I should stick with commenting on this bug, or copy my comments from bug #529230 here, I will. I'd just like to provide as much information as I can to help make this issue disappear :) Thanks!

FYI: I've posted a comment on bug #625239, as suggested by John on bug #529230.

Still crashing my X server on lucid, nvidia-current and using all the latest patches.
Any news?

Please do not reopen this bug. If you are seeing X crashes in lucid you should open a new bug, not assume that your issue is the same as one that has already been fixed.

@Steve Langasek:
To me, your response seems a bit harsh, as it appears (to me) to imply that my judgement must be bad, and I must be jumping to conclusions. I venture, you might be the one jumping to conclusions - or at least using a definition of the word 'fixed' that is incompatible with mine :)

I have been waiting with filing this for weeks, months now, diligently reading _every single_ word in this, and many related bugs, not only on launchpad but also, e.g. on Arch linux. Forgive me if after carefully observing the behaviour again and again I have concluded that _indeed_ this is my problem. I don't know how the supposedly released fix doesn't help me, but I'm totally right (from a user perspective) that this _is_ the same bug in behaviour, symptoms, side-phenomena and probable causes.

As far as I can tell this bug was already against Lucid, so to me it just appears the fix doesn't cover all cases. I _could_ of course open a duplicate of this bug... ? I don't understand. Call me silly if you wish.

For the record, I just visited here because it happened again. This time, I caught the "scroll lock" coming on all by itself in the corner of my eye, at which moment I froze to see whether the crash would happen by itself. It didn't. I then changed vt's to vt1 to investigate. It turned out I had 3 X servers running (:1, :2 and :3; don't know what the third one is around for). The first session (mine) was on vt2 (the apparent root cause). The other two were on vt8 and vt9, as expected. The vt8 and vt9 had '-isig', where vt2 had 'isig' (in stty -F output).

Needless to say, switching back to my X session (the one on vt2) and pressing other keys to complete the command, everything was fine. Just pressing the Enter key crashed the X server. Note that the other X servers kept on running happily. After logging in again, my session is now on an X server in vt10.... (so we have :2 (vt8), :3 (vt9) and :1 (vt10)

Perhaps of interest: I have what you might call a very fast booting system: dual SSD in lvm2 stripes, everything nicely block aligned for the SSDs. My regular boot time used to be around 6 seconds (measured in bootchart). It is now in the 8-9s range. Some of the time, boot time will be slightly longer (up to 20s) and perhaps that is when the symptoms don't occur.
Other specs: Q9550, 8Gb RAM (you can see where all his going to end up being quick...) i386-generic-pae and nvidia-current

Also note, that I have on all occasions performed (many) other keyboard operations before observing the crash: I practically _live_ in shell windows (being a dev + sysadmin addicted to ssh,screen,vim). This is particularly apparent from the fact that in the just-documented occasion, my wife had actually 'switched user' to a second X session, and the problem only manifested itself after switching back to my own session, unlocking the screen, and entering a few commands in the terminal window. It was the flashing-on of the scrollock light that caught my attention in time this time to slow down and observe exactly the situation.

Now if you absolutely insist on me opening a new bug, I will just do so.
Awaiting your confirmation,

Thanks,
Seth

FWIW: I've started running with my own naive modification of /etc/init/gdm.conf, to see whether it changes symptoms. Here the diff (I use etckeeper with git, so this is git diff output):

diff --git a/init/gdm.conf b/init/gdm.conf
index 5600d4c..d36acdc 100644
--- a/init/gdm.conf
+++ b/init/gdm.conf
@@ -8,6 +8,12 @@ author "William Jon McCann <email address hidden>"

 start on (filesystem
           and started dbus
+ and started tty1
+ and started tty2
+ and started tty3
+ and started tty4
+ and started tty5
+ and started tty6
           and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udevtrigger))

At least the first reboot after this change was (a) very quick (b) launched gdm/X on tty7. I will report back on how things go from here

Mmm... <sarcasm>perhaps I should just reopen the bug so we can get a response</sarcasm>

You know, in my opinion this is a critical bug. There are _many_ people right on this very bug and others who have been reporting crashes after the supposed fix was released. I'm guessing that the fix just didn't cut it for these people?

I'll wait another few days, and then I'll probably either repoen this or open a new one, depending on the status of these bugs.

@Seth: Are you also watching bug #625239? This is where I've posted all of my feedback, and there is active work going on there. It's difficult for me to be certain of whether we're experiencing the very same bug or not. I'm also on Lucid, nvidia-current, current updates and on a fast machine, and experiencing X resets after first boot (to VT2) and ending up on VT8 after second login.

@Krug: so that sums up all the symptoms. Do you ever see the scrolllock light come on / flash just before the crash is imminent?
It seems like no risk of crash exists for a while since boot, and then at a certain point (perhaps due to some very slow upstart/init job completing or giving up), something is changed (with me, (sometimes?) resulting in a visual change of the scrollock light) and results in an 'armed' vt2 session, meaning that pressing enter any time from that point in time is certain to crash the X session.

Perhaps I could also try to crash it with some of the named alternative 'trigger' keys, but I haven't (consciously) tried. Most of the time, the crash would hit me before I realized what was going on, being a keyboard person and living mainly in terminal windows. I'll re-read that bug (I must admit I have been skipping some of your recent comments because the raw stream of thoughts was getting a bit confusing to my mind) :)

@Krug: PS. do you have a founded opinion on my workaround/fix in comment #91 ? My systems seems a bit slower to the desktop while booting, but I haven't had the problem manifest itself. I might start explicitely logging the virtual terminals for any X sessions somehow so I can be sure that I'm actually on vt7 now).

To me the approach is a bit 'iffy' because I'd really think that X should work without problems on a vt2 (e.g. when people have disabled vt2-vt6 for many plausible reasons). Now, if this is really just a race condition somewhere, my approach could be a good starting point (just synchronize stuff). But perhaps, the root cause is more a false assumption about virtual terminal allocation numbers. vt7 has been grafted in collective linux memory over the last decade(s?)...

@Seth: Oddly, I don't think my laptop has a scroll lock light, so I can't confirm or deny that correlation. I honestly don't quite understand your workaround in #91, sorry. And sorry if my comments got verbose--I'll try to keep them succinct ;-) I'm a bit over my head, but I'm doing my best to provide any diagnostics I can to those who can help. Check out #625239, as I've stumbled upon two different workarounds that work for me, by simply making tiny changes to the boot line.

@Seth: Please join us over at bug #625239. I'd love to see one of your failing Xorg.0.logs and a plymouth-debug.log if you could manage it in order to compare them to those contributed by Jamie and Dino. In Dino's case we can see that gdm is trying to follow plymouth to plymouth's tty (which should be tty7), but there is confusion somewhere.

You may also want to take a look at closed karmic bug #396226. It explains why starting on the same tty as getty is bad news, though I think the reason is that the restart of getty sets the ISIG flag on the shared terminal rather than an issue of control. When I set this flag manually on tty7 from another terminal I can go back to tty7, press enter, and X gives this crash. I think I remember that you could tell whether the session is "primed" by looking at the stty from another terminal with sudo stty --file /dev/stty1 --all , but the scroll-lock sounds much better. Unfortunately I only have caps lock and num lock lights.

I think your suggestion in 91 is interesting, but I guess there is the speed issue, and there is the issue that if someone ever decides only to run 5 tty's it won't be very obvious why gdm isn't starting.

Seems like a good work-around to me, though, until this is fixed.

after I upgraded the system to maverick, when I start any gui java application from eclipse X crashes

Backtrace:
[ 10634.359] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a0fa8]
[ 10634.359] 1: /usr/bin/X (0x400000+0x60fcd) [0x460fcd]
[ 10634.359] 2: /lib/libpthread.so.0 (0x7fa4bb939000+0xfb40) [0x7fa4bb948b40]
[ 10634.359] 3: /usr/lib/xorg/modules/libfb.so (fbCopyNtoN+0x6e) [0x7fa4b78f222e]
[ 10634.359] 4: /usr/lib/xorg/extra-modules/modules/glesx.so (0x7fa4b584c000+0x36709) [0x7fa4b5882709]
[ 10634.359] 5: /usr/lib/xorg/extra-modules/modules/glesx.so (0x7fa4b584c000+0x37e75) [0x7fa4b5883e75]
[ 10634.359] 6: /usr/bin/X (0x400000+0xd82e0) [0x4d82e0]
[ 10634.360] 7: /usr/bin/X (0x400000+0xd13d9) [0x4d13d9]
[ 10634.360] 8: /usr/bin/X (0x400000+0x2c2d9) [0x42c2d9]
[ 10634.360] 9: /usr/bin/X (0x400000+0x2184b) [0x42184b]
[ 10634.360] 10: /lib/libc.so.6 (__libc_start_main+0xfe) [0x7fa4ba8a4d8e]
[ 10634.360] 11: /usr/bin/X (0x400000+0x213d9) [0x4213d9]
[ 10634.360] Segmentation fault at address 0x18
[ 10634.360]
Caught signal 11 (Segmentation fault). Server aborting
[ 10634.360]

Thanks for your comment, jedioetzi. I wonder if you would find it worthwhile to look further for another report, or to open a new one, perhaps with the command:

ubuntu-bug xorg

The 532047 bug has been marked fixed (and it was), and therefore may not show up on many triagers' bug searches. (In addition those experiencing this bug were getting SIGINT and SIGQUIT from particular key presses. Yours is a segment fault.)

Whatever you decide, thanks for posting your experience and good luck with maverick.

Hi,

I'm on Natty 64 bit and I'm experiencing the same symptoms (and also the same backtrace) of this bug:

https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/529230

which is marked as duplicate of the one on which I'm commenting on.

I can confirm the bug happening on pressing enter or "2", however it does not happen on the first time they are pressed but randomly.

Xorg.log is attached

On Tue, May 24, 2011 at 08:59:31PM -0000, Steven wrote:

> I'm on Natty 64 bit and I'm experiencing the same symptoms (and also the
> same backtrace) of this bug:
>
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/529230

> which is marked as duplicate of the one on which I'm commenting on.

And this bug is marked as fixed. Please open a new bug report for any
issues you're experiencing in natty.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I've opened bug 887445 and found out that it is related to this bug. The same problem remains in 11.10.
It crashes if I press 2 or ENTER.

This bug is definitly not fixed in 11.10.

I have the same problem in 11.10.

I had this problem with ubuntu 11.10 when I pressing "2" or "Enter" at login screen or in my account the first time I enter. A temporary solution that work for me is:

Edit the file /etc/init/plymount-splash.conf and remove the line "or stopped udev-fallback-graphics".

So it should be:

start on (started plymouth
           and (graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY = 1
                or drm-device-added PRIMARY_DEVICE_FOR_DISPLAY = 1)

I have this problem with a Toshiba Portegé Z930 and Ubuntu 12.04. But I get instead a black screen with a mouse cursor and a console cursor blinking. After pressing 2 or ENTER, lightdm starts again.

I leave a "tail -f /var/log/Xorg.0.log" on the tty1 before pressing 2 or ENTER, and then I press it, and I can see the crash log. I'm attaching it.

#105 workaround does NOT fix the problem for me. Removing the /etc/init/plymount-splash.conf does, however.

Additional attachment

hi, sorry if i post a question in a very old tread but i couldn't find an appropriate one for my problem that is the one described here but i have
ubuntu 12.04 precise-64 bit

i tried to open xorg.0.log.old but i need a software to open backup files... what i should use? (sorry i'm neubbie)

if this problem was already solved for my release please post the link to that discussion and i will try to solve my problem by myself

Hello Niccolo,

Launchpad is not a forum, but a platform to track and solve bugs. To solve your problem, please use one of the numerous Ubuntu forums you can find :)

@Niccolo

Welcome.

I don't think this old bug report is a way to get this problem solved as it is already closed. Since you have already looked for a current bug report and can't find one I'd suggest you file a new one yourself. Please don't be shy. I'd suggest you use the approach at https://wiki.ubuntu.com/X/Reporting since `ubuntu-bug xorg` will collect a lot of pertinent information automatically. That page has lots of useful advice.

WRT your question about viewing your xorg log files yourself, I would would suggest starting gedit and navigate to /var/log/ and the files you want to examine. askubuntu.com is great for getting answers to this kind of question, by the way. Here on Launchpad is the best place to get bugs worked on.

@Jorge

The message about the quit signal is just like the ones that occurred with this sort of bug. It might be good to see if there is an error in the still older xorg log.

@Both

I think closed bugs don't appear on developers' lists so a new bug report is much better, as Steve Langasek suggested to someone above. In addition gdm was involved in this old bug but now lightdm is used for the sign on screen so this really is a brand new bug even though there are probably events in common and the symptoms are the same.

If you are both having the same problem on Precise perhaps one of you can file the bug and the other can mark it as affecting him as well . You both should attach the logs produced by `ubuntu-bug xorg` to help move the bug toward triaging.

Thanks.

Hi Mathieu, thanks for your answer and sorry if i misunderstood the format...

Anyway, i report the bug is still present in the newest LTS version of Ubuntu (precise 12.04) and i cannot find a solution to fix it neither in this platform or in any ubuntu forum (i came here by suggestion from italian forum :-)

@John S.Gruber: i read your post just now.. thank you for your suggestions, i will write a new post describing my problem and eventually take a look on askubuntu.com. I'll try to be not shine :)))

PS Sorry again if my approach is forum-style