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

I'm still having this issue. No updates have fixed anything for me yet.

I had exactly one reboot where the bug didn't occur (when I reinstalled plymouth after reading it was fixed), and then it was back.

I'm also having this each time I boot up, and my machine has been updated
many times since I first posted.

The problem is understood and fix should be available shortly. As frustrating as it is, there have been no plymouth updates to justify comments about it still being an issue so please help keep this bug manageable by clicking the "Does this bug also affect you?" button at the top if it does.

Is there a work around for this yet ? I tried the one suggested but I still get logged out on hitting the 2 key. I can handle some beta/alpha problems but getting logged out in the middle of doing something in Firefox is a little hard to take. Can't I just install another login manager and do away with Plymouth entirely ?

This bug was fixed in the package plymouth - 0.8.0~-13

---------------
plymouth (0.8.0~-13) lucid; urgency=low

  [ Steve Langasek ]
  * Don't attach /proc/cmdline to apport reports, this is already in the
    standard info that gets collected...

  [ Alberto Milone ]
  * ubuntu_logo theme:
    - New logo from Otto Greenslade.
    - Switch off dots starting from the ones on the left instead of
      switching them off all at once.

  [ Scott James Remnant ]
  * Move the Ubuntu logo up as discussed with Otto, this makes the mouse
    cursor appear between the logo and dots and solves the optical illusion
    of the logo being too low. LP: #535014.
  * Don't include message about disk checks, which can come from mountall.
  * Drop the rc script splash functions, we don't want the SysV-rc compat
    stuff messing around with the splash screen - this can be entirely
    managed by Upstart now. LP: #528787, #537262.

  * Plymouth Fix Mega Patch:
    - This hasn't yet been broken up into enough bits to send upstream, and
      doesn't *quite* address all the issues yet, but it's a major step.

    - Rewrite the VT handling, rather than abusing /dev/tty0 keep all VT
      operations on the actual VT (tty7), this avoids issues where we set
      the graphics mode of the wrong VT or put the wrong VT into VT_PROCESS
      mode. LP: #520460, #522598, #526321, #533135
    - Don't attempt VT switch when using non-VT consoles.
    - Make VT mandatory for renderer plugins, so we fallback gracefully to
      text when the console is not a VT. LP: #516825, #527083.
    - Restore VT when finished displaying the splash unless plymouth quit
      is called with --retain-splash. LP: #506297.
    - Activate VT from text and details plugins, rather than haphardly in
      the main code, this means the textual boot is also on VT7.
      LP: #518352, #520122.
    - Add a --has-active-vt command that can let gdm inquire whether it
      should reuse Plymouth's VT; fixes the issue where Plymouth has no
      visible splash screen and X ends up on VT1. LP: #519641, #533572.

    - Don't open terminal device in X11, fixes the issue where X will crash
      when debugging plugins using the X11 renderer.
    - Add --tty option to plymouthd for debugging when X is running and
      thus using an alternate VT.

    - Improve deactivate command so that the terminal is no longer watched
      for keyboard input, session is closed, etc. LP: #528787, #531650.
    - Ignore mode changes while deactivated, otherwise we can end up
      resetting the VT back into text mode while X is starting up.
      LP: #523788, #502509.

    - Fix races with simultaneous quit and deactivate commands, or multiples
      of those commands.
    - Ignore --show-splash, --hide-splash, etc. commands while deactivated.
    - Add reactivate command for testing purposes.

    - Don't scan out drm buffer contents to fbcon when not called with
      quit --retain-splash. LP: #527180.

    - Avoid resetting the terminal to unbuffered mode on every write, this
      results in setting X's VT into raw mode and results in the X server
      crashing on key presses. LP: #532047, #534861, #519460, #520...

Be careful when updating. I just did, rebooted and mountall couldn't find some libplybootclient.so.2 library, so my laptop doesn't boot. I've reported this as bug #538298. Wait for a matching mountall update before updating (if I'm right to think that's the problem).

The update to mountall indeed fixes the problem. It's already in the repositories for i386, but not for amd64 just yet. If you happen to run into the problem as I did, the steps to get a booting system are in bug #538298. Then just wait for mountall before updating plymouth.

Confirmed: latest update fixes the problem.

Yes, for me this update fixed it too.

Yes, for me this update fixed it too.

Still experiencing it:
root@Jarvis:~# apt-cache policy plymouth
plymouth:
  Installato: 0.8.0~-14
  Candidato: 0.8.0~-14
  Tabella versione:
 *** 0.8.0~-14 0
        500 http://archive.ubuntu.com lucid/main Packages
        100 /var/lib/dpkg/status
root@Jarvis:~# apt-cache policy plymouth-x11
plymouth-x11:
  Installato: 0.8.0~-14
  Candidato: 0.8.0~-14
  Tabella versione:
 *** 0.8.0~-14 0
        500 http://archive.ubuntu.com lucid/main Packages
        100 /var/lib/dpkg/status
root@Jarvis:~# apt-cache policy libplymouth2
libplymouth2:
  Installato: 0.8.0~-14
  Candidato: 0.8.0~-14
  Tabella versione:
 *** 0.8.0~-14 0
        500 http://archive.ubuntu.com lucid/main Packages
        100 /var/lib/dpkg/status
root@Jarvis:~# apt-cache policy mountall
mountall:
  Installato: 2.8
  Candidato: 2.8
  Tabella versione:
 *** 2.8 0
        500 http://archive.ubuntu.com lucid/main Packages
        100 /var/lib/dpkg/status

root@Jarvis:~# uname -a
Linux Jarvis 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9 16:33:12 UTC 2010 x86_64 GNU/Linux

@Claudio: does X crash as described in this bug, or does plymouth simply drop you to VT1 (with the desktop accessible by pressing Ctrl-Alt-F7) without any crashing on pressing "2" or "Enter"? I get this on my laptop, although not on my desktop. This is a different problem, though, the present bug report is about the crashing.

What I just described is covered by bug #538214, by the way.

Bug behaviour: pressing 2 or Enter causes gdm restart.

On Sun, Mar 14, 2010 at 18:29, pablomme <email address hidden> wrote:

> What I just described is covered by bug #538214, by the way.
>
> --
> Plymouth text-mode splash causes X to crash on first run due to shared tty7
> https://bugs.launchpad.net/bugs/532047
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in X.Org X server: Invalid
> Status in “plymouth” package in Ubuntu: Fix Released
> Status in “xorg-server” package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: plymouth
>
> Lucid adopted the Plymouth graphical splash service that uses the Kernel
> Mode Setting (KMS) facilities to provide a flicker-free graphical splash
> during start-up. For older video chipsets and drivers (e.g. intel i815) that
> *do not* support KMS plymouth falls back to using a text console (using the
> text plugin). It attaches to tty7 and outputs Linux terminfo control codes
> to draw a colour progress-bar at the bottom of the display.
>
> There is an unfortunate interaction between plymouth and X. X also uses
> tty7. When the X/GDM log-in screen appears for the first time plymouth is
> still running. A script triggers a quit message to the plymouth daemon. It
> seems that plymouth is waiting for either the "2" key or "Enter" key to be
> pressed, whereupon a SIGQUIT (signal 3) is sent to tty7. This causes both
> plymouth *and* X to terminate.
>
> So, if a password contains "2" or the user logs in by pressing "Enter"
> after typing their password, the user experience is that X 'crashes'
> (however, gdb reveals that X receives SIGQUIT).
>
> Some stray plymouth control codes can be witnessed on tty7 if X is stopped
> and tty7 console is on-screen.
>
> Upstart (/sbin/init) then restarts gdm (which launches X) and the second
> session performs correctly.
>
> *** A temporary workaround is to disable the plymouth-splash upstart job
> ***
>
> sudo mv /etc/init/plymouth-splash.conf
> /etc/init/plymouth-splash.conf.disabled
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/xorg-server/+bug/532047/+subscribe
>

I agree with those above that the X/GDM crash bug is fixed, but like pablomme, I now get bug #538214 instead. i.e. I wind up on VT1 instead of VT7.

Also I get a report of plymouthd crashing after I log in and I no longer have plymouth on shutdown.

It is fixed for me now.

This problem still exists for me with current versions of lucid:

ii mountall 2.8 filesystem mounting tool
ii plymouth 0.8.0~-14 graphical boot animation and logger - main package
ii plymouth-x11 0.8.0~-14 graphical boot animation and logger - X11 interface

I use

GRUB_CMDLINE_LINUX_DEFAULT=""

(so no splash and no quiet). Could this be relevant?

Attaching Xorg.log of X catching SIGQUIT (in gdm when pressing enter right after entering the username).

The majority of users have confirmed that this bug is fixed, so marking this again as fixed and unmarking bug #529230 as a duplicate.

Confirmation: I did a lucid update this morning (Mar 15th), and this
behaviour has been fixed for me.

Sean

On 15 March 2010 06:01, Steve Langasek <email address hidden> wrote:

> The majority of users have confirmed that this bug is fixed, so marking
> this again as fixed and unmarking bug #529230 as a duplicate.
>
> ** Changed in: plymouth (Ubuntu)
> Status: New => Fix Released
>
> --
> Plymouth text-mode splash causes X to crash on first run due to shared tty7
> https://bugs.launchpad.net/bugs/532047
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in X.Org X server: Invalid
> Status in “plymouth” package in Ubuntu: Fix Released
> Status in “xorg-server” package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: plymouth
>
> Lucid adopted the Plymouth graphical splash service that uses the Kernel
> Mode Setting (KMS) facilities to provide a flicker-free graphical splash
> during start-up. For older video chipsets and drivers (e.g. intel i815) that
> *do not* support KMS plymouth falls back to using a text console (using the
> text plugin). It attaches to tty7 and outputs Linux terminfo control codes
> to draw a colour progress-bar at the bottom of the display.
>
> There is an unfortunate interaction between plymouth and X. X also uses
> tty7. When the X/GDM log-in screen appears for the first time plymouth is
> still running. A script triggers a quit message to the plymouth daemon. It
> seems that plymouth is waiting for either the "2" key or "Enter" key to be
> pressed, whereupon a SIGQUIT (signal 3) is sent to tty7. This causes both
> plymouth *and* X to terminate.
>
> So, if a password contains "2" or the user logs in by pressing "Enter"
> after typing their password, the user experience is that X 'crashes'
> (however, gdb reveals that X receives SIGQUIT).
>
> Some stray plymouth control codes can be witnessed on tty7 if X is stopped
> and tty7 console is on-screen.
>
> Upstart (/sbin/init) then restarts gdm (which launches X) and the second
> session performs correctly.
>
> *** A temporary workaround is to disable the plymouth-splash upstart job
> ***
>
> sudo mv /etc/init/plymouth-splash.conf
> /etc/init/plymouth-splash.conf.disabled
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/xorg-server/+bug/532047/+subscribe
>

On Sun, 2010-03-14 at 16:22 +0000, Claudio Moretti wrote:

> Still experiencing it:
>
Could you provide "cat /proc/fb" output for me, and confirm whether you
see an Ubuntu logo during boot, or the words "Ubuntu 10.04" in text

Scott
--
Scott James Remnant
<email address hidden>

On Mon, 2010-03-15 at 01:59 +0000, Marc A. Donges wrote:

> This problem still exists for me with current versions of lucid:
>
Could you describe the problem you're seeing?

Does plymouth show a graphical logo or do you see "Ubuntu 10.04" written
in text?

Scott
--
Scott James Remnant
<email address hidden>

Still experiencing it, too. I have the text boot splash, not the graphical logo one.
My description from https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/529230/comments/9 still stands.
I use "quiet splash nomodeset" in the grub linux line, because KMS doesn't work with my graphics adapter (Radeon HD 4200, it throws me in textmode at startup though ctrl-alt-f7 works, but after going to standby and back /dev/sda gives errors on every read. I tried to look for bugs related to my HD4200, but couldn't find ANY in LP.)
Oh, and when I turn off the computer the last thing I see is text telling me that plymouth was shut down with the kill signal. I think that is new. On reboot apport tells me that plymouthd didn't properly stop and wants to report it, but then says it's https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/537262

schaefer@cal:~$ cat /proc/fb
0 VGA16 VGA
schaefer@cal:~$ lspci
[...]
01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4200]
[...]

Henning

On Mon, 2010-03-15 at 14:03 +0000, Henning Schröder wrote:

> Still experiencing it, too. I have the text boot splash, not the graphical logo one.
>
Thanks. This is bug #538213 - which is specifically about the text boot
splash

Scott
--
Scott James Remnant
<email address hidden>

Fixed for me too

On Monday, March 15, 2010 at 13:02:30 (-0000), Scott James Remnant wrote:
> On Mon, 2010-03-15 at 01:59 +0000, Marc A. Donges wrote:
>
> > This problem still exists for me with current versions of lucid:
> >
> Could you describe the problem you're seeing?

Yes, of course. But I have not yet encountered my original problem after
the last update of plymouth (X dying far (even hours) into a session
when I hit enter), so this may in fact be fixed.

Instead, gdm now dies reliably when I hit enter for the first time during
that boot (which is new).

> Does plymouth show a graphical logo or do you see "Ubuntu 10.04" written
> in text?

Neither. I do not use splash as a boot option, as mentioned earlier in…
this bug.

Marc

--
  _ _ Marc A. Donges +49 721 6904-2130
  'v' Klosterweg 28 / E110
 / \ 76131 Karlsruhe
  W W

Reproduced in daily (today) liveCD in virtualbox, bootup shows "text-splash" (+errror messages, broken pipe, etc.).
Enter restarts gdm reproducibly after first login.

Bug should be reopened?

@arand
Please see bug 538213

On Tue, 2010-03-16 at 20:22 +0000, Marc A. Donges wrote:

> On Monday, March 15, 2010 at 13:02:30 (-0000), Scott James Remnant wrote:
> > On Mon, 2010-03-15 at 01:59 +0000, Marc A. Donges wrote:
> >
> > > This problem still exists for me with current versions of lucid:
> > >
> > Could you describe the problem you're seeing?
>
> Yes, of course. But I have not yet encountered my original problem after
> the last update of plymouth (X dying far (even hours) into a session
> when I hit enter), so this may in fact be fixed.
>
> Instead, gdm now dies reliably when I hit enter for the first time during
> that boot (which is new).
>
Sorry, I'm confused.

You said above that the problem still existed for you; then you said you
haven't encountered your original problem, but then you say you have had
a problem?

It's not at all clear to me what problem (if any) you're suffering from.

Scott
--
Scott James Remnant
<email address hidden>

I am seeing this after installing from today's alternate ISO build...

I looked at bug 538213 and tried the updated plymouth package but that did not fix the issue at all...

I still get the X terminiation if I hit enter on the first login attempt after boot.

On Wed, 2010-03-17 at 18:39 +0000, Jeff Lane wrote:

> I am seeing this after installing from today's alternate ISO build...
>
Do you have cryptsetup installed?

Scott
--
Scott James Remnant
<email address hidden>

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