Plymouth text-mode splash causes X to crash on first run due to shared tty7
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
X.Org X server |
Invalid
|
Undecided
|
Unassigned | ||
plymouth (Ubuntu) |
Fix Released
|
High
|
Scott James Remnant (Canonical) | ||
xorg-server (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
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/
tankdriver (stoneraider-deactivatedaccount) wrote : | #1 |
- BootDmesg.txt Edit (23.9 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (4.6 KiB, text/plain; charset="utf-8")
- GdmLog.txt Edit (20.5 KiB, text/plain; charset="utf-8")
- GdmLog1.txt Edit (20.7 KiB, text/plain; charset="utf-8")
- GdmLog2.txt Edit (20.7 KiB, text/plain; charset="utf-8")
- Lspci.txt Edit (5.0 KiB, text/plain; charset="utf-8")
- PciDisplay.txt Edit (425 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (1.3 KiB, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (1.3 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (1.9 KiB, text/plain; charset="utf-8")
- RelatedPackageVersions.txt Edit (253 bytes, text/plain; charset="utf-8")
- UdevDb.txt Edit (61.5 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (134.2 KiB, text/plain; charset="utf-8")
- XorgLog.txt Edit (25.4 KiB, text/plain; charset="utf-8")
- XorgLogOld.txt Edit (25.8 KiB, text/plain; charset="utf-8")
- Xrandr.txt Edit (1.4 KiB, text/plain; charset="utf-8")
- setxkbmap.txt Edit (233 bytes, text/plain; charset="utf-8")
- xdpyinfo.txt Edit (17.2 KiB, text/plain; charset="utf-8")
- xkbcomp.txt Edit (47.2 KiB, text/plain; charset="utf-8")
affects: | xorg (Ubuntu) → xorg-server (Ubuntu) |
tags: | added: crash |
Changed in xorg-server (Ubuntu): | |
status: | New → Confirmed |
Changed in xorg-server (Ubuntu): | |
assignee: | nobody → TJ (intuitivenipple) |
status: | Confirmed → In Progress |
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_
They look to be partial control-code representations.
E.g: " ^X ^C
or: ^]^]^]^
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/
$ 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/
ACTION!
# 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_
ENV{ID_INPUT}!="", GOTO="xorg_
ATTRS{name}=="Video Bus", GOTO="xorg_
ATTRS{name}
ATTRS{name}=="PS/2 Mouse", GOTO="xorg_
ATTRS{name}=="Sony Vaio Keys", GOTO="xorg_
ATTRS{name}=="Power Button", GOTO="xorg_
ATTRS{name}
ENV{ID_
ENV{ID_
ENV{ID_
ENV{ID_
LABEL="
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!
SeanBoran (sean-boran) wrote : Re: [Bug 532047] Re: Xorg crashed at first login attempt | #7 |
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:/
> 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=
> ProcEnviron:
> PATH=(custom, no user)
> LANG=de_AT.UTF-8
> SHELL=/bin/bash
> ProcVersionSign
> 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:bvninnotekG
> d...
tankdriver (stoneraider-deactivatedaccount) wrote : Re: Xorg crashed at first login attempt | #8 |
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.
Changed in plymouth (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → High |
assignee: | nobody → TJ (intuitivenipple) |
Changed in xorg-server (Ubuntu): | |
status: | In Progress → Confirmed |
summary: |
- Xorg crashed at first login attempt + Plymouth text-mode splash causes X to crash on first run due to shared + tty7 |
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/
description: | updated |
tankdriver (stoneraider-deactivatedaccount) wrote : | #11 |
The workaround works for me.
Thank you.
Steve Langasek (vorlon) wrote : | #12 |
This is not an X bug, this is a well understood bug in plymouth that is in the process of being fixed.
Changed in xorg-server (Ubuntu): | |
assignee: | TJ (intuitivenipple) → nobody |
status: | Confirmed → Invalid |
Changed in plymouth (Ubuntu): | |
status: | Confirmed → In Progress |
assignee: | TJ (intuitivenipple) → nobody |
Stephan Muhs (stephan-dinoco) wrote : | #13 |
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)
Yann Dìnendal (yannbreliere) wrote : | #14 |
I've had this bug for a long time, but since yesterday, it doesn't crash anymore!
VladimirCZ (vlabla) wrote : | #15 |
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.
VladimirCZ (vlabla) wrote : | #16 |
The temporary workaround intended to disable plymouth-splash:
sudo mv /etc/init/
does not work for me, because there is no /etc/init/
Running: OS Ubuntu 10.04 alpha 3 64-bit fully updated ...
Steve Langasek (vorlon) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #18 |
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/
> 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://
<email address hidden> <email address hidden>
Simon Baconnais (smon-deactivatedaccount) wrote : | #19 |
I still have this bug.
VladimirCZ (vlabla) wrote : | #20 |
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/
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 ...
Madde (cev-madde) wrote : | #21 |
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).
Matteo Rossi (teo-red90) wrote : | #22 |
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.
kpmcdole (kpmcdole) wrote : | #23 |
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.
Changed in xorg-server: | |
status: | New → Invalid |
John S. Gruber (jsjgruber) wrote : | #24 |
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/
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.
pablomme (pablomme) wrote : | #25 |
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.
Noel J. Bergman (noeljb) wrote : | #26 |
There is a bug for the random characters on the tty: Bug 535316
Benjamin Séguret (mithranduck-deactivatedaccount) wrote : | #27 |
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: ***
Ubuntu lucid (development branch) daedalus tty1
daedalus login:
pablomme (pablomme) wrote : | #28 |
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.
kpmcdole (kpmcdole) wrote : | #29 |
Seems to be fixed for me now since I updated initscripts, sysv-rc and sysvinit-utils in an update today.
pablomme (pablomme) wrote : | #30 |
@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?
Noel J. Bergman (noeljb) wrote : | #31 |
Ben, what you are seeing is bug 535316.
Benjamin Séguret (mithranduck-deactivatedaccount) wrote : | #32 |
@Noel: yes it is.
Are the two bugs related somehow ?
JanG (jan-ge) wrote : | #33 |
I also suffer this problem.
Xorg.0.log: VT 7
Xorg.0.log.old: VT 8
Tony Mugan (tmugan) wrote : | #34 |
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.
Pēteris Krišjānis (pecisk-gmail) wrote : | #35 |
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.
Rocko (rockorequin) wrote : | #36 |
@Tony: the right hand/left hand login screen bug is covered in bug #395314 (there's a workaround in comment 11, https:/
Noel J. Bergman (noeljb) wrote : | #37 |
@Pēteris, yes, those are Bug 535318 and Bug 535316, which are really duplicates, since the latter is the cause of the former.
kpmcdole (kpmcdole) wrote : | #38 |
@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.
Draycen DeCator (ddecator) wrote : | #39 |
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.
SeanBoran (sean-boran) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #40 |
I still have it all the time. Last Lucid update was Tuesday.
Sean
Daniel Drummond (dmdrummondx) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #41 |
I'm still having this issue. No updates have fixed anything for me yet.
Rocko (rockorequin) wrote : | #42 |
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.
Drew Shetley (amshetle) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #43 |
I'm also having this each time I boot up, and my machine has been updated
many times since I first posted.
Robert Hooker (sarvatt) wrote : | #44 |
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.
Changed in plymouth (Ubuntu): | |
milestone: | none → ubuntu-10.04-beta-1 |
assignee: | nobody → Scott James Remnant (scott) |
Michael Z Freeman (michael-z-freeman) wrote : | #45 |
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 ?
Launchpad Janitor (janitor) wrote : | #46 |
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...
Changed in plymouth (Ubuntu): | |
status: | In Progress → Fix Released |
pablomme (pablomme) wrote : | #47 |
Be careful when updating. I just did, rebooted and mountall couldn't find some libplybootclien
pablomme (pablomme) wrote : | #48 |
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.
Charles (charles-bovy) wrote : | #49 |
Confirmed: latest update fixes the problem.
Rafał Cieślak (rafalcieslak256) wrote : | #50 |
Yes, for me this update fixed it too.
VladimirCZ (vlabla) wrote : | #51 |
Yes, for me this update fixed it too.
Claudio Moretti (flyingstar16) wrote : | #52 |
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://
100 /var/lib/
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://
100 /var/lib/
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://
100 /var/lib/
root@Jarvis:~# apt-cache policy mountall
mountall:
Installato: 2.8
Candidato: 2.8
Tabella versione:
*** 2.8 0
500 http://
100 /var/lib/
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
pablomme (pablomme) wrote : | #53 |
@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.
pablomme (pablomme) wrote : | #54 |
What I just described is covered by bug #538214, by the way.
Claudio Moretti (flyingstar16) wrote : | #55 |
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:/
> 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/
> /etc/init/
>
>
>
> To unsubscribe from this bug, go to:
> https:/
>
Fred (ian-bews) wrote : | #56 |
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.
Daniel Drummond (dmdrummondx) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #57 |
It is fixed for me now.
Marc D. (koshy) wrote : | #58 |
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_
(so no splash and no quiet). Could this be relevant?
Marc D. (koshy) wrote : | #59 |
- Xorg.log of X catching SIGQUIT Edit (27.9 KiB, application/x-trash)
Attaching Xorg.log of X catching SIGQUIT (in gdm when pressing enter right after entering the username).
Changed in plymouth (Ubuntu): | |
status: | Fix Released → New |
Steve Langasek (vorlon) wrote : | #60 |
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 |
SeanBoran (sean-boran) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #61 |
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:/
> 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/
> /etc/init/
>
>
>
> To unsubscribe from this bug, go to:
> https:/
>
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 532047] Re: Plymouth text-mode splash causes X to crash on first run due to shared tty7 | #62 |
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>
Scott James Remnant (Canonical) (canonical-scott) wrote : | #63 |
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>
Henning Schröder (hgschroeder) wrote : | #64 |
Still experiencing it, too. I have the text boot splash, not the graphical logo one.
My description from https:/
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:/
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
Scott James Remnant (Canonical) (canonical-scott) wrote : | #65 |
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>
Matteo Rossi (teo-red90) wrote : | #66 |
Fixed for me too
Marc D. (koshy) wrote : | #67 |
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
Martin Erik Werner (arand) wrote : | #68 |
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?
Draycen DeCator (ddecator) wrote : | #69 |
@arand
Please see bug 538213
Scott James Remnant (Canonical) (canonical-scott) wrote : | #70 |
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>
Jeff Lane (bladernr) wrote : | #71 |
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.
tags: | added: iso-testing |
Scott James Remnant (Canonical) (canonical-scott) wrote : | #72 |
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>
u-foka (ufooka) wrote : | #73 |
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?
Detlef Lechner (detlef-lechner) wrote : | #74 |
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'
Charles (charles-bovy) wrote : | #75 |
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.
petrj (petrjanousek-net) wrote : | #76 |
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 !
euthymos (euthymos) wrote : | #77 |
Horrible bug, affects me too
Mark Lord (launchpad-rtr) wrote : | #78 |
Still borked here, as of latest Lucid, long after "final" release.
WTF is going on ????
Delan Azabani (azabani) wrote : | #79 |
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.
Pablo (paul-hahn) wrote : | #80 |
This is broken for me as well.
Bilal Akhtar (bilalakhtar) wrote : | #81 |
Same problem, filed bug #625239 about problem in maverick, however I think this one is the correct bug.
Bilal Akhtar (bilalakhtar) wrote : | #82 |
Is this change the problem causer?
+ 121_only_
Add a check to prevent the X server from changing the VT when killing
GDM from the console.
Bilal Akhtar (bilalakhtar) wrote : | #83 |
Subscribed RAOF as it appears this is a regression from the last upload.
Bilal Akhtar (bilalakhtar) wrote : | #84 |
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.
John S. Gruber (jsjgruber) wrote : | #85 |
Looks like the regression in Maverick has been filed as bug #625239
and has been marked as confirmed.
Jamie Krug (jamie-thekrugs) wrote : | #86 |
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:/
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!
Jamie Krug (jamie-thekrugs) wrote : | #87 |
FYI: I've posted a comment on bug #625239, as suggested by John on bug #529230.
Seth (bugs-sehe) wrote : | #88 |
Still crashing my X server on lucid, nvidia-current and using all the latest patches.
Any news?
Changed in plymouth (Ubuntu): | |
status: | Fix Released → In Progress |
Steve Langasek (vorlon) wrote : | #89 |
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.
Changed in plymouth (Ubuntu): | |
status: | In Progress → Fix Released |
Seth (bugs-sehe) wrote : | #90 |
@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
Seth (bugs-sehe) wrote : | #91 |
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-
or drm-device-added card0 PRIMARY_
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
Seth (bugs-sehe) wrote : | #92 |
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.
Jamie Krug (jamie-thekrugs) wrote : | #93 |
@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.
Seth (bugs-sehe) wrote : | #94 |
@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) :)
Seth (bugs-sehe) wrote : | #95 |
@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?)...
Jamie Krug (jamie-thekrugs) wrote : | #96 |
@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.
John S. Gruber (jsjgruber) wrote : | #97 |
@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.
jedioetzi (jedioetzi) wrote : | #98 |
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
[ 10634.359] 1: /usr/bin/X (0x400000+0x60fcd) [0x460fcd]
[ 10634.359] 2: /lib/libpthread
[ 10634.359] 3: /usr/lib/
[ 10634.359] 4: /usr/lib/
[ 10634.359] 5: /usr/lib/
[ 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_
[ 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]
John S. Gruber (jsjgruber) wrote : | #99 |
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.
Steven (steven3000) wrote : | #100 |
- Xorg.1.log.old Edit (35.8 KiB, application/x-trash)
Hi,
I'm on Natty 64 bit and I'm experiencing the same symptoms (and also the same backtrace) of this bug:
https:/
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
Steve Langasek (vorlon) wrote : | #101 |
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:/
> 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://
<email address hidden> <email address hidden>
Gunnar (ubuntu-hwbqs6tox) wrote : | #102 |
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.
isatis39871 (isatis39871) wrote : | #103 |
This bug is definitly not fixed in 11.10.
eduardo (poyart) wrote : | #104 |
I have the same problem in 11.10.
Juan Carlos (juanki23pr) wrote : | #105 |
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/
So it should be:
start on (started plymouth
and (graphics-
or drm-device-added PRIMARY_
Jorge Suárez de Lis (ys) wrote : | #106 |
- Black screen before pressing ENTER - Toshiba Portegé Z930 Edit (569.3 KiB, image/jpeg)
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/
#105 workaround does NOT fix the problem for me. Removing the /etc/init/
Jorge Suárez de Lis (ys) wrote : | #107 |
niccolo dematteis (nicodema) wrote : | #108 |
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
Mathieu Marquer (slasher-fun) wrote : | #109 |
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 :)
John S. Gruber (jsjgruber) wrote : | #110 |
@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:/
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.
niccolo dematteis (nicodema) wrote : | #111 |
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 :-)
niccolo dematteis (nicodema) wrote : | #112 |
@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
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 people. gnome.org/ ~michael/ blog/2009- 05-29.html
http://