plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed.

Bug #1082742 reported by Marcin Juszkiewicz
138
This bug affects 26 people
Affects Status Importance Assigned to Milestone
plymouth (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Plymouth on Chromebook always ends with this message. I added manual overrides for all plymouth jobs in /etc/init/ but I am tired of telling each user how to work around a problem.

There were suggestions that this is because of kernel cmdline: "cros_secure console= console=tty1 printk.time=1 quiet nosplash rootwait root=/dev/mmcblk0p7 rw loglevel=0" because plymouth only takes first one while kernel is using the last one...
---
ApportVersion: 2.6.2-0ubuntu5
Architecture: armhf
DefaultPlymouth: Error: command ['readlink', '/etc/alternatives/default.plymouth'] failed with exit code 1:
DistroRelease: Ubuntu 13.04
MarkForUpload: True
Package: plymouth 0.8.8-0ubuntu1
PackageArchitecture: armhf
ProcCmdLine: cros_secure console= console=tty1 printk.time=1 quiet nosplash rootwait root=/dev/mmcblk0p7 rw loglevel=0
ProcFB: 0
ProcKernelCmdLine: cros_secure console= console=tty1 printk.time=1 quiet nosplash rootwait root=/dev/mmcblk0p7 rw loglevel=0
Tags: raring
TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
Uname: Linux 3.4.0 armv7l
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm audio cdrom dialout dip plugdev video

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : BootDmesg.txt

apport information

tags: added: apport-collected raring
description: updated
Revision history for this message
Marcin Juszkiewicz (hrw) wrote : BootLog.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : Dependencies.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : Lsusb.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : ProcEnviron.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : ProcModules.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : UdevDb.txt

apport information

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : UdevLog.txt

apport information

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in plymouth (Ubuntu):
status: New → Confirmed
Revision history for this message
jaduncan (jaduncan) wrote :

I think this is actually an X hang bug - when I remove the plymouth entries entirely from /etc/init (not neat, I know) I get the same blank screen and lock but without the plymouth error message. Any ideas on how to check if it's a framebuffer issue?

Revision history for this message
Marcin Juszkiewicz (hrw) wrote :

On my system (without /etc/init/plymouth*.conf files) I have slim (x login manager) started just fine.

Revision history for this message
jaduncan (jaduncan) wrote :

Is that with your PPA xorg video driver installed? Can you reproduce that success without? We should look at the differences between our configs.

Revision history for this message
Marcin Juszkiewicz (hrw) wrote : Re: [Bug 1082742] Re: plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed.

W dniu 26.11.2012 09:40, jaduncan pisze:
> Is that with your PPA xorg video driver installed?

Yes

> Can you reproduce that success without?

Can try later.

> We should look at the differences between our configs.

I hope one day to have two devices for such work. One for all the
hacking and second running only packaged work.

Revision history for this message
jaduncan (jaduncan) wrote :

I hope one day to have two devices for such work. One for all the hacking and second running only packaged work.

Well, in this case you could always just have two USB sticks/SD cards to boot off. If your base rootfs is small enough to send or you've got notes on how you set it up I'll even try that directly for you.

Revision history for this message
Andrew Kirby (mrandrewkirby) wrote :

> when I remove the plymouth entries entirely from /etc/init (not neat, I know) I get the same blank screen and lock but without the plymouth error message. Any ideas on how to check if it's a framebuffer issue?

I can confirm this too, also disabling DRI in xorg.conf doesn't work either.

Revision history for this message
Matt Sealey (mwsealey) wrote :

For the edification of the reporters I can confirm this doesn't just happen on Chromebook but on an Efika MX running kernel 3.7, using the imx-drm staging driver. Xorg seems to crash a hell of a lot too, but I can't tell if it's related. Using xserver-xorg-video-modesetting or -fbdev makes no difference (it will explode the same way), and trying to get Plymouth out of the way makes no difference.

Xorg, modesetting driver/libkms and Plymouth using the same seems to get ARM systems no matter what they are into a complete tizzy - indicative of something far, far more serious floating around (maybe plymouth or xorg is being miscompiled/misconfigured for armhf?) than just some esoteric Chromebook bug.

At some point Xorg will segfault and what you see behind it is this Plymouth message about ply_terminal_open. The console= lines on the kernel command line make absolutely no difference here - my cmdline is "console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 rootwait rw quiet splash".

I did notice that no matter what I do with mkinitramfs or update-initramfs with "-v" option. it seems like no plymouth themes or configurations are being copied into the ramdisk which seems quite odd to me. A lot of X11 libraries are thrown in, a lot of Plymouth support libs, and a file ubuntu-text.so but the actual splash images, logos are annoyingly missing if you correctly enable initramfs-tools/conf.d/splash FRAMEBUFFER=y. It doesn't seem like the plymouth hooks are doing the right thing at all.. they DO seem to do the exact right thing under a much older Ubuntu (Maverick), though, where themes and images are put into the ramdisk.

BTW boot.log is also showing some kind of mountall: Event failed before console_setup runs and then it says Starting userspace splash daemon. However, what event failed is a mystery; all the boot.log entries say OK and the system continues to boot after also saying "unexpectedly disconnected from boot status daemon"...

Has anyone figured out anything regarding this bug or anything related as to why Plymouth has so many problems here on ARM with a DRM/KMS framebuffer?

Revision history for this message
Robie Basak (racb) wrote :

"I am tired of telling each user how to work around a problem."

Frustratingly, you didn't mention the workaround in this bug, and Googling found your G+ post which says "cd /etc/init; for p in plymouth*;do echo "manual" > ${p}.override;done" which doesn't quite work.

For those stuck, the answer is that the override files need to be called, eg. plymouth.override, NOT plymouth.conf.override.

With that correction, X fails to start, but Ctrl+Alt+F1 [Ctrl+Alt+←] at least gets me a terminal with which I can view /var/log/Xorg.0.log and see the problem, which I don't think is related to this bug any more.

Revision history for this message
Jeff Grant (jeffrmg) wrote :

I too see this bug and X fails to display with my user account, but I find it interesting that the Guest account works just fine. I can browse the web in firefox all day with it. So I thought the issue may be account related. Any ideas are welcome - I'll keep poking around.

Revision history for this message
Sebastian Pop (sebpop) wrote :

After "apt-get remove gdm lightdm", I get by default to the command line, and there "startx" crashes the kernel.
From /var/log/syslog, it looks like a problem in exynos_user_fb_create:

Apr 14 10:37:25 nap kernel: [ 12.657138] Unable to handle kernel paging request at virtual address 0040a000
Apr 14 10:37:25 nap kernel: [ 12.657218] pgd = eca38000
Apr 14 10:37:25 nap kernel: [ 12.657269] [0040a000] *pgd=00000000
Apr 14 10:37:25 nap kernel: [ 12.657354] Internal error: Oops: 5 [#1] SMP ARM
Apr 14 10:37:25 nap kernel: [ 12.657410] Modules linked in: qcserial uvcvideo usb_wwan videobuf2_vmalloc usbserial xhci_hcd joydev isl29018(C) mw
ifiex_sdio mwifiex industrialio(C) ehci_hcd rfcomm cfg80211 sbs_battery cyapa btmrvl_sdio ohci_hcd btmrvl bluetooth usbcore dwc3_exynos usb_common spi
dev dwc3
Apr 14 10:37:25 nap kernel: [ 12.658072] CPU: 0 Tainted: G C (3.4.0-5-chromebook #5-Ubuntu)
Apr 14 10:37:25 nap kernel: [ 12.658162] PC is at page_address+0x14/0xf4
Apr 14 10:37:25 nap kernel: [ 12.658230] LR is at exynos_user_fb_create+0x22c/0x2dc
Apr 14 10:37:25 nap kernel: [ 12.658300] pc : [<800db9c0>] lr : [<80293de0>] psr: 800f0013
Apr 14 10:37:25 nap kernel: [ 12.658331] sp : ecec1d28 ip : ecec1d50 fp : ecec1d4c
Apr 14 10:37:25 nap kernel: [ 12.658396] r10: eca5dd40 r9 : 00000001 r8 : 00000001
Apr 14 10:37:25 nap kernel: [ 12.658454] r7 : 806e8848 r6 : eca5db40 r5 : 806e09a4 r4 : edd5c680
Apr 14 10:37:25 nap kernel: [ 12.658518] r3 : 806e0964 r2 : 00000000 r1 : eca5dd40 r0 : 0040a000
Apr 14 10:37:25 nap kernel: [ 12.658586] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Apr 14 10:37:25 nap kernel: [ 12.658656] Control: 10c5387d Table: aca3806a DAC: 00000015
Apr 14 10:37:25 nap kernel: [ 12.658718] Process Xorg (pid: 956, stack limit = 0xecec02f8)
Apr 14 10:37:25 nap kernel: [ 12.658778] Stack: (0xecec1d28 to 0xecec2000)
Apr 14 10:37:25 nap kernel: [ 12.658845] 1d20: 806e0964 edd5c680 806e09a4 eca5db40 806e8848 00000001
Apr 14 10:37:25 nap kernel: [ 12.658928] 1d40: ecec1d94 ecec1d50 80293de0 800db9b8 805a8d9b ecec1d60 80496f68 eca5dd40

Revision history for this message
Patola (patola) wrote :

Just for the sake of it, I got this problem and it had nothing to do with plymouth. It was caused by a 13.04 update which removed /etc/X11/xorg.conf.d along with exynos5.conf. I just had to do this:
- get into ChromeOS shell (Ctrl-Alt-[←])
- log in as chronos, then sudo su -
- make some directory (mkdir /tmp/x) and mount my SDcard root partition on it (mount /dev/mmcbkl1p7 /tmp/x)
- chroot to it (chroot /tmp/x)
- recreate the xorg.conf.d directory: mkdir /etc/X11/xorg.conf.d
- recreate the exynos5.conf file:
cat > /etc/X11/xorg.conf.d/exynos5.conf <<EOZ
Section "Device"
Identifier "Mali FBDEV"
Driver "armsoc"
Option "fbdev" "/dev/fb0"
Option "Fimg2DExa" "false"
Option "DRI2" "true"
Option "DRI2_PAGE_FLIP" "false"
Option "DRI2_WAIT_VSYNC" "true"
# Option "Fimg2DExaSolid" "false"
# Option "Fimg2DExaCopy" "false"
# Option "Fimg2DExaComposite" "false"
Option "SWcursorLCD" "false"
EndSection

Section "Screen"
Identifier "DefaultScreen"
Device "Mali FBDEV"
DefaultDepth 24
EndSection

EOZ

- exit from the chroot: exit
- umount the chroot: umount /tmp/x
- reboot to Ubuntu

Revision history for this message
Patola (patola) wrote :

OBS.: I got exynos5.conf file from this script: https://gist.github.com/vvuk/4986933

Revision history for this message
fark mcface (e-face) wrote :

In my case ("clean" 13.04 on internal drive) the exynos5.conf file is present but I still get the error.

Revision history for this message
aantoon (harpitap) wrote :

I have the same bug on 12.04 alternate 32bit.
followed by "error: unexpectedly disconnected from boot status daemon"

Revision history for this message
Tom Brown (tomubun4) wrote :

I ended up at this bug because I saw the message in the title while running http://goo.gl/s9ryd per http://chromeos-cr48.blogspot.com/2013/05/chrubuntu-one-script-to-rule-them-all_31.html
I found a work-around at http://ubuntuforums.org/showthread.php?t=2162179 : use http://goo.gl/kpzxn instead. This gets a version of the script from jay0lee on github instead of googledrive.

Revision history for this message
Jay Zee (jayzee) wrote :

Just a bit of extra info -- it's possible that this has been mentioned before.

I am using Acer C710-2834 with Chrome OS installed via s9ryd script.

In my case there are two (2) distinct behaviors.

1. Happens when the Chromebook is Running on Battery power.
The message >>> plymouthd: ply-terminal.c:611: ply_terminal_open: Assertion 'terminal != ((void *)0)' failed
appears and stays on the screen (forever, I guess).
The log-in screen will not appear by itself.
To get to the log-in screen, I have to close the cover and then reopen it.
At various tries, different elements of the log-in screen will appear but I typically get the password text box.
Typing the password will get me to the desktop.

2. Happens when the Chromebook is Running on Power Supply / Mains (the battery is inserted and "charging")
The message >>> plymouthd: ply-terminal.c:611: ply_terminal_open: Assertion 'terminal != ((void *)0)' failed
appears and stays on the screen for short time (2 to 3 sec).
The fully rendered and working log-in screen will appear by itself.
Typing the password will get me to the desktop.

Hope this helps

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.