Ubuntu
plymouth package

Installing packages hangs on plymouth --ping

Bug #1705345 reported by giacof on 2017-07-19

616

This bug affects 118 people

	Status	Importance	Assigned to
plymouth (Ubuntu)	Fix Released	Critical	Brian Murray
Xenial	Fix Released	Undecided	Brian Murray
Artful	Fix Released	Undecided	Brian Murray

Bug Description

Impact
------
Many packages call pymouth --ping and if plymouthd is hung then the package installations can fail.

Test Case
---------
1) Run 'sudo /sbin/plymouthd --mode=boot --attach-to-session --pid-file=/run/plymouth/pid'
2) Observe plymouthd is running ('ps aux | grep plymouth')
3) stop the plymouthd process 'sudo kill -STOP $PID'
4) Run 'plymouth --ping --debug'
5) Observe that the plymouth --ping command hangs

With the version of plymouth from -proposed you will receive the following output instead.

bdmurray@clean-artful-amd64:~$ plymouth --ping --debug
[ply-event-loop.c:759] ply_event_loop_stop_watching_fd:stopping watching fd 6
[ply-event-loop.c:775] ply_event_loop_stop_watching_fd:removing destination for fd 6
[./plymouth.c:82] timeout_handler:ping: timed out waiting for plymouthd
[./ply-boot-client.c:810] ply_boot_client_detach_from_event_loop:detaching from event loop

Notice how the ping command times out.

Regression Potential
--------------------
Its possible that the timeout of 2 seconds isn't long enough but that seems unlikely.

Original Description
--------------------
I tried to upgrade linux kernel, from 4.10.0-26 to 4.10.0-28, but the installation hung on the following output lines:

sudo apt-get install unrar linux-generic linux-headers-generic linux-image-generic linux-signed-generic linux-signed-image-generic
Configurazione di linux-image-4.10.0-28-generic (4.10.0-28.32)...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.10.0-28-generic /boot/vmlinuz-4.10.0-28-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.10.0-28-generic /boot/vmlinuz-4.10.0-28-generic

Then I looked at the running processes, and noticed this one was blocking post-installation:

plymouth --ping

I could not but manually kill plymouth, then the script resumed just to freeze again a few line later and so on, but is that safe for the installation?

ProblemType: BugDistroRelease: Ubuntu 17.04
Package: plymouth 0.9.2-3ubuntu15
ProcVersionSignature: Ubuntu 4.10.0-26.30-generic 4.10.17
Uname: Linux 4.10.0-26-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.4-0ubuntu4.4
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Jul 19 22:32:14 2017
DefaultPlymouth: /usr/share/plymouth/themes/ubuntu-gnome-logo/ubuntu-gnome-logo.plymouth
InstallationDate: Installed on 2017-05-22 (58 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
MachineType: Dell Inc. Precision M4800
ProcCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-26-generic.efi.signed root=/dev/mapper/vg-root ro quiet splash vt.handoff=7
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=it_IT.UTF-8
SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-26-generic.efi.signed root=/dev/mapper/vg-root ro quiet splash vt.handoff=7SourcePackage: plymouth
TextPlymouth: /usr/share/plymouth/themes/ubuntu-gnome-text/ubuntu-gnome-text.plymouth
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/02/2014
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A06
dmi.board.name: 0T3YTY
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA06:bd01/02/2014:svnDellInc.:pnPrecisionM4800:pvr01:rvnDellInc.:rn0T3YTY:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: Precision M4800
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

See original description

Tags:

Revision history for this message

giacof (giacof) wrote on 2017-07-19:

BootLog.txt Edit (11.6 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (109.9 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (3.0 KiB, text/plain; charset="utf-8")
EtcDefaultGrub.txt Edit (1.2 KiB, text/plain; charset="utf-8")
JournalErrors.txt Edit (116.8 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (19.4 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (601 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (8.0 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.0 KiB, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (4.5 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (8.7 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (219.3 KiB, text/plain; charset="utf-8")

giacof (giacof) on 2017-07-19

description:

updated

Revision history for this message

Launchpad Janitor (janitor) wrote on 2017-08-11:

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

Changed in plymouth (Ubuntu):
status:	New → Confirmed

Brian Murray (brian-murray) on 2017-09-15

tags:

added: artful

Revision history for this message

Brian Murray (brian-murray) wrote on 2017-10-18:

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please check to see if the command 'plymouth --ping' continues to hang in a terminal. In the event that it does it would help us out if you could run it under strace e.g. 'strace plymouth --ping' so that we can determine why the process is hanging. Thanks for your assistance!

Changed in plymouth (Ubuntu):
status:	Confirmed → Incomplete
tags:	added: plymouth-ping

Revision history for this message

David Wahler (dwahler) wrote on 2017-10-18: Re: Installing new kernel hangs on plymouth --ping

plymouth.strace Edit (6.9 KiB, text/plain)

I hit this bug while trying to install a kernel upgrade (going from the default 4.13.0-16-generic to 4.13.8-041308, from the mainline PPA). I managed to get an strace from running "plymouth --ping". In the attached trace file, the hang happened on the last call to epoll_pwait.

I also tried attaching strace to plymouthd, but when I did that, it caused plymouthd to immediately exit (which in turn caused plymouth --ping to return). After that, subsequent runs of "plymouth --ping" returned immediately (getting ECONNREFUSED on the "/org/freedesktop/plymouthd" socket), and I haven't been able to reproduce the bug since.

Revision history for this message

David Wahler (dwahler) wrote on 2017-10-18:

plymouthd.strace Edit (1.5 KiB, text/plain)

And here's the trace from plymouthd.

Steve Langasek (vorlon) on 2017-10-18

Changed in plymouth (Ubuntu):
status:	Incomplete → New

Revision history for this message

giacof (giacof) wrote on 2017-10-19:

output of `strace plymouth --ping` Edit (6.0 KiB, text/plain)

Here is mine. It actually hangs on the last line.

antidrugue (antidrugue) on 2017-10-31

Changed in plymouth (Ubuntu):
status:	New → Confirmed

Revision history for this message

Rolands Kusiņš (tower98) wrote on 2017-11-22:

plymouth_ping_20171122.strace Edit (6.3 KiB, text/plain)

In attachment output of:
# strace plymouth --ping

Currently used:
# uname -r
4.13.0-16-generic

Trying update to:
4.13.0-17-generic

Killed plymouth --ping from parallel session between upgrade steps.

Revision history for this message

A. R. (aroman-a) wrote on 2017-11-22:

Same problem here, apt upgrade froze when doing regular upgrade from 4.13.0-16-generic to 4.13.0-17-generic.

giacof (giacof) on 2017-11-22

description:	updated
description:	updated

Revision history for this message

cljk (marcel-pokrandt) wrote on 2017-11-23:

I have the same issue.... on last dist-ugprade the system hang on updating apport and now on updating the kernel

Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.13.0-17-generic /boot/vmlinuz-4.13.0-17-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.13.0-17-generic /boot/vmlinuz-4.13.0-17-generic

Killling "plymouth --ping" kind of "helps"

Revision history for this message

Sven (buurman) wrote on 2017-12-22:

#10

strace_plymouth.log Edit (6.3 KiB, text/plain)

I have the same issue, apparently a sudo apt full-upgrade hung and I interrupted it by shutting down my laptop. Upon trying to install something unrelated it told me I had to run sudo dpkg --configure -a to continue with the previous upgrade. That still hangs:

$ sudo dpkg --configure -a
Setting up linux-image-4.13.0-21-generic (4.13.0-21.24) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
The link /initrd.img is a dangling linkto /boot/initrd.img-4.13.0-21-generic
vmlinuz(/boot/vmlinuz-4.13.0-21-generic
) points to /boot/vmlinuz-4.13.0-21-generic
(/boot/vmlinuz-4.13.0-21-generic) -- doing nothing at /var/lib/dpkg/info/linux-image-4.13.0-21-generic.postinst line 491.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.13.0-21-generic /boot/vmlinuz-4.13.0-21-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.13.0-21-generic /boot/vmlinuz-4.13.0-21-generic

I can see using ps axuf that it hangs on a plymouth ping, this hangs in a terminal as well. See the attachment for the output of strace plymouth --ping

Revision history for this message

Sven (buurman) wrote on 2017-12-22:

#11

Update to #10:
After killing the original plymouthd process (the one running '@sbin/plymouthd --mode=boot --attach-to-session --pid-file=/run/plymouth/pid' as root) the installation continued and seems to have installed succesfully.

After reboot ubuntu started succesfully and I can also install the other tools I originally wanted to install.

This seems to be a workaround though I'd advice rebooting immediately after the apt install or update completed successfully, since plymouth is responsible for the splash/login screen and logging out/suspending will likely result in a crash of some kind.

Revision history for this message

Stephen Early (steve-greenend) wrote on 2018-01-10:

#12

I am seeing the same thing. plymouthd doesn't hang around after every boot, but it does so a reasonably large percentage of the time. Additionally, when plymouthd continues to run after boot, machine shutdown hangs for a long time before completing (presumably some kind of systemd timeout).

Running strace against plymouthd when it's stuck causes it to exit normally.

root@asp:~# ps axu |grep plymouth
root 320 0.0 0.2 164820 44100 ? S 12:23 0:00 @sbin/plymouthd --mode=boot --attach-to-session --pid-file=/run/plymouth/pid
root 1166 0.0 0.0 12936 1016 ? Ss 12:23 0:00 /bin/plymouth --wait
root 1311 0.0 0.0 12936 1020 ? S 12:23 0:00 /bin/plymouth quit
root 5398 0.0 0.0 12936 1024 pts/2 SN+ 12:26 0:00 plymouth --ping
root 6023 0.0 0.0 12936 1020 ? S 12:28 0:00 plymouth --ping
root 7537 0.0 0.0 14356 1060 pts/3 S+ 12:58 0:00 grep --color=auto plymouth
root@asp:~# strace -p 320
strace: Process 320 attached
ioctl(10, PIO_CMAP, 0x559a2b77f178) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 10, {EPOLLERR|EPOLLHUP, {u32=730276688, u64=94120643601232}}) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 10, NULL) = 0
rt_sigaction(SIGWINCH, {sa_handler=SIG_DFL, sa_mask=[WINCH], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f0996fec140}, {sa_handler=0x7f09975b2820, sa_mask=[WINCH], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f0996fec140}, 8) = 0
ioctl(10, TIOCSLCKTRMIOS, {B0 -opost -isig -icanon -echo ...}) = 0
ioctl(10, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
ioctl(10, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(10, TCGETS, {B38400 opost isig icanon echo ...}) = 0
close(10) = 0
close(7) = 0
unlink("/run/plymouth/pid") = 0
sendto(8, "\6", 1, MSG_NOSIGNAL, NULL, 0) = 1
epoll_ctl(3, EPOLL_CTL_DEL, 4, NULL) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 6, NULL) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 7, NULL) = -1 EBADF (Bad file descriptor)
epoll_ctl(3, EPOLL_CTL_DEL, 11, NULL) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 12, NULL) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 8, NULL) = 0
close(11) = 0
close(12) = 0
close(8) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++
root@asp:~# ps axu |grep plymouth
root 5405 0.0 0.0 14356 1080 pts/3 S+ 12:59 0:00 grep --color=auto plymouth

I am seeing the same thing.  plymouthd doesn't hang around after every boot, but it does so a reasonably large percentage of the time.  Additionally, when plymouthd continues to run after boot, machine shutdown hangs for a long time before completing (presumably some kind of systemd timeout).

Running strace against plymouthd when it's stuck causes it to exit normally.

root@asp:~# ps axu |grep plymouth
root       320  0.0  0.2 164820 44100 ?        S    12:23   0:00 @sbin/plymouthd --mode=boot --attach-to-session --pid-file=/run/plymouth/pid
root      1166  0.0  0.0  12936  1016 ?        Ss   12:23   0:00 /bin/plymouth --wait
root      1311  0.0  0.0  12936  1020 ?        S    12:23   0:00 /bin/plymouth quit
root      5398  0.0  0.0  12936  1024 pts/2    SN+  12:26   0:00 plymouth --ping
root      6023  0.0  0.0  12936  1020 ?        S    12:28   0:00 plymouth --ping
root      7537  0.0  0.0  14356  1060 pts/3    S+   12:58   0:00 grep --color=auto plymouth
root@asp:~# strace -p 320
strace: Process 320 attached
ioctl(10, PIO_CMAP, 0x559a2b77f178)     = 0
epoll_ctl(3, EPOLL_CTL_MOD, 10, {EPOLLERR|EPOLLHUP, {u32=730276688, u64=94120643601232}}) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 10, NULL)   = 0
rt_sigaction(SIGWINCH, {sa_handler=SIG_DFL, sa_mask=[WINCH], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f0996fec140}, {sa_handler=0x7f09975b2820, sa_mask=[WINCH], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f0996fec140}, 8) = 0
ioctl(10, TIOCSLCKTRMIOS, {B0 -opost -isig -icanon -echo ...}) = 0
ioctl(10, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
ioctl(10, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
ioctl(10, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(10, TCGETS, {B38400 opost isig icanon echo ...}) = 0
close(10)                               = 0
close(7)                                = 0
unlink("/run/plymouth/pid")             = 0
sendto(8, "\6", 1, MSG_NOSIGNAL, NULL, 0) = 1
epoll_ctl(3, EPOLL_CTL_DEL, 4, NULL)    = 0
epoll_ctl(3, EPOLL_CTL_DEL, 6, NULL)    = 0
epoll_ctl(3, EPOLL_CTL_DEL, 7, NULL)    = -1 EBADF (Bad file descriptor)
epoll_ctl(3, EPOLL_CTL_DEL, 11, NULL)   = 0
epoll_ctl(3, EPOLL_CTL_DEL, 12, NULL)   = 0
epoll_ctl(3, EPOLL_CTL_DEL, 8, NULL)    = 0
close(11)                               = 0
close(12)                               = 0
close(8)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
root@asp:~# ps axu |grep plymouth
root      5405  0.0  0.0  14356  1080 pts/3    S+   12:59   0:00 grep --color=auto plymouth

Revision history for this message

dino99 (9d9) wrote on 2018-01-16:

#13

That version is now dead
http://news.softpedia.com/news/ubuntu-17-04-zesty-zapus-has-reached-end-of-life-upgrade-to-ubuntu-17-10-now-519360.shtml

To get a real idea about such issue, do a fresh install, as 'rolling' upgrade brings conflicting/borked old settings.

Changed in plymouth (Ubuntu):
status:	Confirmed → Invalid

Steve Langasek (vorlon) on 2018-01-16

Changed in plymouth (Ubuntu):
status:	Invalid → Confirmed

Revision history for this message

Morsok (morsok) wrote on 2018-01-17:

#14

This is clearly not invalid dino99 i'm having the issue for months now, it's a pain and I installed 17.10 directly.

Revision history for this message

cljk (marcel-pokrandt) wrote on 2018-01-19:

#15

Nothing new on this?
On every update I have to call "killall plymouth" several times....

Does it have sth to do with nvidia driver?

Revision history for this message

Dan McDonald (danmcdonald) wrote on 2018-01-30:

#16

Download full text (16.3 KiB)

Just want to add some additional details to this that might help.

$ systemctl status
● dan-Lenovo-Y50-70
    State: starting
     Jobs: 6 queued
   Failed: 7 units
    Since: Mon 2018-01-29 07:19:45 MST; 13h ago
...

$ sudo tail -n 15 /var/log/boot.log
[ OK ] Reached target Network.
[ OK ] Started Unattended Upgrades Shutdown.
         Starting OpenBSD Secure Shell server...
         Starting Permit User Sessions...
         Starting Network Name Resolution...
         Starting Network Manager Wait Online...
[ OK ] Started Permit User Sessions.
         Starting GNOME Display Manager...
         Starting Hold until boot process finishes up...
         Starting Network Manager Script Dispatcher Service...
[ OK ] Started Network Manager Script Dispatcher Service.
[ OK ] Started Hostname Service.
[ OK ] Started GNOME Display Manager.
[ OK ] Started Modem Manager.
[ OK ] Started OpenBSD Secure Shell server.

$ systemctl list-units --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● apparmor.service loaded failed failed AppArmor initialization
● hylafax.service loaded failed failed LSB: Start and stop the hylafax server
● trousers.service loaded failed failed LSB: starts tcsd
● virtualbox.service loaded failed failed LSB: VirtualBox Linux kernel module
● xinetd.service loaded failed failed LSB: Starts or stops the xinetd daemon.

$ journalctl -u apparmor
-- Logs begin at Mon 2018-01-29 07:19:45 MST, end at Mon 2018-01-29 21:20:13 MST. --
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: Starting AppArmor initialization...
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: * Starting AppArmor profiles
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.bin.webbrowser-app in /etc/apparmor.d/usr.bin.webbrowser-app at line 26: Could not open '/usr/share/apparmor/hardwar
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor in /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor at li
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.bin.webbrowser-app in /etc/apparmor.d/usr.bin.webbrowser-app at line 26: Could not open '/usr/share/apparmor/hardwar
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor in /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor at li
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: ...fail!
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: apparmor.service: Main process exited, code=exited, status...

Just want to add some additional details to this that might help.

$ systemctl status
● dan-Lenovo-Y50-70
    State: starting
     Jobs: 6 queued
   Failed: 7 units
    Since: Mon 2018-01-29 07:19:45 MST; 13h ago
...

$ sudo tail -n 15 /var/log/boot.log
[  OK  ] Reached target Network.
[  OK  ] Started Unattended Upgrades Shutdown.
         Starting OpenBSD Secure Shell server...
         Starting Permit User Sessions...
         Starting Network Name Resolution...
         Starting Network Manager Wait Online...
[  OK  ] Started Permit User Sessions.
         Starting GNOME Display Manager...
         Starting Hold until boot process finishes up...
         Starting Network Manager Script Dispatcher Service...
[  OK  ] Started Network Manager Script Dispatcher Service.
[  OK  ] Started Hostname Service.
[  OK  ] Started GNOME Display Manager.
[  OK  ] Started Modem Manager.
[  OK  ] Started OpenBSD Secure Shell server.

$ systemctl list-units --state=failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION                            
● apparmor.service    loaded failed failed AppArmor initialization                
● hylafax.service     loaded failed failed LSB: Start and stop the hylafax server 
● trousers.service    loaded failed failed LSB: starts tcsd                       
● virtualbox.service  loaded failed failed LSB: VirtualBox Linux kernel module    
● xinetd.service      loaded failed failed LSB: Starts or stops the xinetd daemon.

$ journalctl -u apparmor
-- Logs begin at Mon 2018-01-29 07:19:45 MST, end at Mon 2018-01-29 21:20:13 MST. --
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: Starting AppArmor initialization...
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]:  * Starting AppArmor profiles
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.bin.webbrowser-app in /etc/apparmor.d/usr.bin.webbrowser-app at line 26: Could not open '/usr/share/apparmor/hardwar
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor in /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor at li
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.bin.webbrowser-app in /etc/apparmor.d/usr.bin.webbrowser-app at line 26: Could not open '/usr/share/apparmor/hardwar
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: AppArmor parser error for /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor in /etc/apparmor.d/usr.lib.mediascanner-2.0.mediascanner-extractor at li
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Jan 29 07:19:46 dan-Lenovo-Y50-70 apparmor[886]:    ...fail!
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: Failed to start AppArmor initialization.
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: apparmor.service: Unit entered failed state.
Jan 29 07:19:46 dan-Lenovo-Y50-70 systemd[1]: apparmor.service: Failed with result 'exit-code'.

$ sudo lsof -p348
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND   PID USER   FD      TYPE             DEVICE SIZE/OFF    NODE NAME
plymouthd 348 root  cwd       DIR              253,0     4096       2 /
plymouthd 348 root  rtd       DIR              253,0     4096       2 /
plymouthd 348 root  txt       REG                0,1    84224    2103 /sbin/plymouthd (deleted)
plymouthd 348 root  mem       CHR              226,1              337 /dev/dri/card1
plymouthd 348 root  DEL       REG                0,1            13258 /lib/x86_64-linux-gnu/libbsd.so.0.8.6
plymouthd 348 root  DEL       REG                0,1            13336 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1
plymouthd 348 root  DEL       REG                0,1            13362 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
plymouthd 348 root  DEL       REG                0,1            13344 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
plymouthd 348 root  DEL       REG                0,1            13361 /usr/lib/x86_64-linux-gnu/libdatrie.so.1.3.3
plymouthd 348 root  DEL       REG                0,1            13351 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10400.2
plymouthd 348 root  DEL       REG                0,1            13273 /lib/x86_64-linux-gnu/libexpat.so.1.6.5
plymouthd 348 root  DEL       REG                0,1            13252 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
plymouthd 348 root  DEL       REG                0,1            13348 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
plymouthd 348 root  DEL       REG                0,1            13358 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
plymouthd 348 root  DEL       REG                0,1            13349 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
plymouthd 348 root  DEL       REG                0,1            13341 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
plymouthd 348 root  DEL       REG                0,1            13338 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
plymouthd 348 root  DEL       REG                0,1            13379 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
plymouthd 348 root  DEL       REG                0,1            13353 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0
plymouthd 348 root  DEL       REG                0,1            13357 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
plymouthd 348 root  DEL       REG                0,1            13339 /usr/lib/x86_64-linux-gnu/libthai.so.0.3.0
plymouthd 348 root  DEL       REG                0,1            13360 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.14.0
plymouthd 348 root  DEL       REG                0,1            13350 /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.4000.12
plymouthd 348 root  DEL       REG                0,1            13327 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0
plymouthd 348 root  DEL       REG                0,1            13280 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1
plymouthd 348 root  DEL       REG                0,1            13352 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.10
plymouthd 348 root  DEL       REG                0,1            13359 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1
plymouthd 348 root  DEL       REG                0,1            13332 /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4000.12
plymouthd 348 root  DEL       REG                0,1            13328 /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.4000.12
plymouthd 348 root  DEL       REG                0,1            13368 /usr/lib/x86_64-linux-gnu/plymouth/label.so
plymouthd 348 root  DEL       REG                0,1            13264 /lib/x86_64-linux-gnu/libz.so.1.2.11
plymouthd 348 root  DEL       REG                0,1            13335 /usr/lib/x86_64-linux-gnu/libpng16.so.16.34.0
plymouthd 348 root  DEL       REG                0,1            13275 /lib/x86_64-linux-gnu/libply-splash-graphics.so.4.0.0
plymouthd 348 root  DEL       REG                0,1            13366 /usr/lib/x86_64-linux-gnu/plymouth/script.so
plymouthd 348 root  DEL       REG                0,1            13363 /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
plymouthd 348 root  DEL       REG                0,1            13372 /usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so
plymouthd 348 root  DEL       REG                0,1            13278 /lib/x86_64-linux-gnu/libnss_files-2.26.so
plymouthd 348 root  DEL       REG                0,1            13287 /lib/x86_64-linux-gnu/libpthread-2.26.so
plymouthd 348 root  DEL       REG                0,1            13230 /lib/x86_64-linux-gnu/libudev.so.1.6.6
plymouthd 348 root  DEL       REG                0,1            13247 /lib/x86_64-linux-gnu/libm-2.26.so
plymouthd 348 root  DEL       REG                0,1            13266 /lib/x86_64-linux-gnu/libdl-2.26.so
plymouthd 348 root  DEL       REG                0,1            13263 /lib/x86_64-linux-gnu/librt-2.26.so
plymouthd 348 root  DEL       REG                0,1            13250 /lib/x86_64-linux-gnu/libc-2.26.so
plymouthd 348 root  DEL       REG                0,1            13248 /lib/x86_64-linux-gnu/libply-splash-core.so.4.0.0
plymouthd 348 root  DEL       REG                0,1            13288 /lib/x86_64-linux-gnu/libply.so.4.0.0
plymouthd 348 root  DEL       REG                0,1            13277 /lib/x86_64-linux-gnu/ld-2.26.so
plymouthd 348 root  DEL       REG                0,1            13299 /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
plymouthd 348 root    0u      CHR                1,3      0t0       6 /dev/null
plymouthd 348 root    1u      CHR                1,3      0t0       6 /dev/null
plymouthd 348 root    2u      CHR                1,3      0t0       6 /dev/null
plymouthd 348 root    3u  a_inode               0,13        0   12125 [eventpoll]
plymouthd 348 root    4r     FIFO               0,12      0t0   13609 pipe
plymouthd 348 root    5w     FIFO               0,12      0t0   13609 pipe
plymouthd 348 root    6u     unix 0xffff9826c04fd800      0t0    1596 @/org/freedesktop/plymouthd type=STREAM
plymouthd 348 root    7u  netlink                         0t0    1599 KOBJECT_UEVENT
plymouthd 348 root    8u     unix 0xffff9826b84b1c00      0t0   31754 @/org/freedesktop/plymouthd type=STREAM
plymouthd 348 root    9u      CHR              226,1      0t0     337 /dev/dri/card1
plymouthd 348 root   10u      CHR                4,1      0t0      20 /dev/tty1
plymouthd 348 root   11u     unix 0xffff9826b7f47800      0t0   23852 @/org/freedesktop/plymouthd type=STREAM
plymouthd 348 root   12w      REG              253,0     1665 7471192 /var/log/boot.log (deleted)

$ sudo -H strace plymouth --ping
execve("/bin/plymouth", ["plymouth", "--ping"], [/* 17 vars */]) = 0
brk(NULL)                               = 0x55a9d4559000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=279753, ...}) = 0
mmap(NULL, 279753, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe21d500000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libply.so.4", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000E\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=88632, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe21d4fe000
mmap(NULL, 2185728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe21d108000
mprotect(0x7fe21d11d000, 2093056, PROT_NONE) = 0
mmap(0x7fe21d31c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7fe21d31c000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\22\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1960656, ...}) = 0
mmap(NULL, 4061792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe21cd28000
mprotect(0x7fe21cefe000, 2097152, PROT_NONE) = 0
mmap(0x7fe21d0fe000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d6000) = 0x7fe21d0fe000
mmap(0x7fe21d104000, 14944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe21d104000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=31744, ...}) = 0
mmap(NULL, 2128864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe21cb20000
mprotect(0x7fe21cb27000, 2093056, PROT_NONE) = 0
mmap(0x7fe21cd26000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fe21cd26000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14632, ...}) = 0
mmap(NULL, 2109712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe21c91c000
mprotect(0x7fe21c91f000, 2093056, PROT_NONE) = 0
mmap(0x7fe21cb1e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fe21cb1e000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360a\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=144776, ...}) = 0
mmap(NULL, 2221160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe21c6fd000
mprotect(0x7fe21c717000, 2093056, PROT_NONE) = 0
mmap(0x7fe21c916000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7fe21c916000
mmap(0x7fe21c918000, 13416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe21c918000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe21d4fc000
arch_prctl(ARCH_SET_FS, 0x7fe21d4fd040) = 0
mprotect(0x7fe21d0fe000, 16384, PROT_READ) = 0
mprotect(0x7fe21c916000, 4096, PROT_READ) = 0
mprotect(0x7fe21cb1e000, 4096, PROT_READ) = 0
mprotect(0x7fe21cd26000, 4096, PROT_READ) = 0
mprotect(0x7fe21d31c000, 4096, PROT_READ) = 0
mprotect(0x55a9d2d1d000, 4096, PROT_READ) = 0
mprotect(0x7fe21d545000, 4096, PROT_READ) = 0
munmap(0x7fe21d500000, 279753)          = 0
set_tid_address(0x7fe21d4fd310)         = 8955
set_robust_list(0x7fe21d4fd320, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7fe21c702c70, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fe21c710150}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fe21c702d00, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fe21c710150}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fe21cd5f140}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
brk(NULL)                               = 0x55a9d4559000
brk(0x55a9d457a000)                     = 0x55a9d457a000
epoll_create1(EPOLL_CLOEXEC)            = 3
pipe2([4, 5], O_CLOEXEC)                = 0
epoll_ctl(3, EPOLL_CTL_ADD, 4, {EPOLLERR|EPOLLHUP, {u32=3562378048, u64=94187900212032}}) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 4, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=3562378048, u64=94187900212032}}) = 0
openat(AT_FDCWD, "/proc/cmdline", O_RDONLY) = 6
read(6, "BOOT_IMAGE=/boot/vmlinuz-4.13.0-"..., 4096) = 116
close(6)                                = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 6
setsockopt(6, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
connect(6, {sa_family=AF_UNIX, sun_path=@"/org/freedesktop/plymouthd"}, 29) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLERR|EPOLLHUP, {u32=3562393360, u64=94187900227344}}) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 6, {EPOLLERR|EPOLLHUP, {u32=3562393360, u64=94187900227344}}) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 6, {EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=3562393360, u64=94187900227344}}) = 0
epoll_pwait(3, [{EPOLLOUT, {u32=3562393360, u64=94187900227344}}], 64, -1, NULL, 8) = 1
sendto(6, "P\0", 2, MSG_NOSIGNAL, NULL, 0) = 2
epoll_ctl(3, EPOLL_CTL_MOD, 6, {EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=3562393360, u64=94187900227344}}) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 6, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=3562393360, u64=94187900227344}}) = 0
epoll_pwait(3,

I get similar output when using strace to attach to existing plymouthd and kernel package configuration works again.

Revision history for this message

dino99 (9d9) wrote on 2018-02-03:

#17

To all affected users:
- always 'purge' when removing a package, to also remove its settings (avoiding disturbing the system later)
- often run gtkorphan & bleachbit (as root carefully) to get a cleaned system

This report probably should be against a particular app not having the expected settings (ex: webbrowser, above). So purging that (these) app(s) might help.

Changed in plymouth (Ubuntu):
status:	Confirmed → Incomplete

Revision history for this message

Steve Langasek (vorlon) wrote on 2018-02-03:

#18

This has nothing to do with purging packages. Please ignore the previous comment.

Changed in plymouth (Ubuntu):
status:	Incomplete → Triaged

Revision history for this message

Nemanja Boric (4burgos) wrote on 2018-02-08:

#19

I have the same problem, encountered at the first update after fresh 17.10 installation.

Francis Ginther (fginther) on 2018-02-16

tags:

added: id-5a862ec3e29bfd25c55193e7

Steve Langasek (vorlon) on 2018-02-23

Changed in plymouth (Ubuntu):
importance:	Undecided → Critical

Revision history for this message

Pi Delport (pi-delport) wrote on 2018-02-26:

#20

Output of "strace plymouth --ping" in gnome-terminal Edit (6.3 KiB, text/plain)

I'm consistently hitting this bug on kernel upgrades, among other things, on Ubuntu 17.10.

I'm working around it by manually killing the hung "plymouth --ping" process, which seems to make dpkg proceed successfully.

Brian Murray (brian-murray) on 2018-02-28

summary:

- Installing new kernel hangs on plymouth --ping
+ Installing packages hangs on plymouth --ping

Brian Murray (brian-murray) on 2018-02-28

tags:

added: bugpattern-written

Revision history for this message

Brian Murray (brian-murray) wrote on 2018-03-07:

#21

It'd be interesting to see the output of 'plymouth --debug --ping' when plymouth is hanging. Thanks in advance.

Revision history for this message

Brian Murray (brian-murray) wrote on 2018-03-07:

#22

Ah, I was able to recreate the problem of 'plymouth --ping' hanging with the following test case on an Ubuntu 16.04 system.

1) Run 'sudo /sbin/plymouthd --mode=boot --attach-to-session --pid-file=/run/plymouth/pid'
2) Observe plymouthd is running ('ps aux | grep plymouth')
3) stop the plymouthd process 'sudo kill -STOP $PID'
4) Run 'plymouth --ping --debug'

bdmurray@clean-xenial-amd64:~$ plymouth --ping --debug
[ply-event-loop.c:759] ply_event_loop_stop_watching_fd:stopping watching fd 6
[ply-event-loop.c:775] ply_event_loop_stop_watching_fd:removing destination for fd 6

Revision history for this message

Sven (buurman) wrote on 2018-03-08:

#23

I just tested plymouth --ping and it hangs again. Aborting and rerunning it with --debug gives the same output as you:

haster@schootbak3:~
$ plymouth --ping
^C

haster@schootbak3:~
$ plymouth --debug --ping
[ply-event-loop.c:759] ply_event_loop_stop_watching_fd:stopping watching fd 6
[ply-event-loop.c:775] ply_event_loop_stop_watching_fd:removing destination for fd 6

Brian Murray (brian-murray) on 2018-03-29

Changed in plymouth (Ubuntu):
assignee:	nobody → Brian Murray (brian-murray)

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-03-30:

#24

This bug was fixed in the package plymouth - 0.9.3-1ubuntu4

---------------
plymouth (0.9.3-1ubuntu4) bionic; urgency=medium

* debian/patches/timeout-for-ping.ptach: Don't wait forever for a reply from
a ping command. (LP: #1705345)

-- Brian Murray <email address hidden> Fri, 30 Mar 2018 07:41:54 -0700

Changed in plymouth (Ubuntu):
status:	Triaged → Fix Released

Brian Murray (brian-murray) on 2018-04-02

Changed in plymouth (Ubuntu Xenial):
status:	New → In Progress
Changed in plymouth (Ubuntu Artful):
status:	New → In Progress
Changed in plymouth (Ubuntu Xenial):
assignee:	nobody → Brian Murray (brian-murray)
Changed in plymouth (Ubuntu Artful):
assignee:	nobody → Brian Murray (brian-murray)

Brian Murray (brian-murray) on 2018-04-02

description:

updated

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2018-04-03: Please test proposed package

#25

Hello giacof, or anyone else affected,

Accepted plymouth into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/plymouth/0.9.2-3ubuntu19 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in plymouth (Ubuntu Artful):
status:	In Progress → Fix Committed
tags:	added: verification-needed verification-needed-artful

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2018-04-03:

#26

Hello giacof, or anyone else affected,

Accepted plymouth into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/plymouth/0.9.2-3ubuntu13.4 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in plymouth (Ubuntu Xenial):
status:	In Progress → Fix Committed
tags:	added: verification-needed-xenial

Revision history for this message

Brian Murray (brian-murray) wrote on 2018-04-03:

#27

Verified in artful:

Setting up plymouth-theme-ubuntu-text (0.9.2-3ubuntu19) ...
update-initramfs: deferring update (trigger activated)
Setting up plymouth-theme-ubuntu-logo (0.9.2-3ubuntu19) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.125ubuntu12) ...
update-initramfs: Generating /boot/initrd.img-4.13.0-21-generic
bdmurray@clean-artful-amd64:~$ plymouth --ping --debug
[ply-event-loop.c:759] ply_event_loop_stop_watching_fd:stopping watching fd 6
[ply-event-loop.c:775] ply_event_loop_stop_watching_fd:removing destination for fd 6
[./plymouth.c:82] timeout_handler:ping: timed out waiting for plymouthd
[./ply-boot-client.c:810] ply_boot_client_detach_from_event_loop:detaching from event loop

Revision history for this message

Brian Murray (brian-murray) wrote on 2018-04-03:

#28

Verified in xenial:

Setting up plymouth-theme-ubuntu-text (0.9.2-3ubuntu13.4) ...
update-initramfs: deferring update (trigger activated)
Setting up plymouth-label (0.9.2-3ubuntu13.4) ...
Setting up plymouth-theme-ubuntu-logo (0.9.2-3ubuntu13.4) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.122ubuntu8.1) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-38-generic
bdmurray@clean-xenial-amd64:~$ plymouth --ping --debug
[ply-event-loop.c:759] ply_event_loop_stop_watching_fd:stopping watching fd 6
[ply-event-loop.c:775] ply_event_loop_stop_watching_fd:removing destination for fd 6
[./plymouth.c:82] timeout_handler:ping: timed out waiting for plymouthd
[./ply-boot-client.c:810] ply_boot_client_detach_from_event_loop:detaching from event loop

Brian Murray (brian-murray) on 2018-04-03

tags:

added: verification-done verification-done-artful verification-done-xenial
removed: verification-needed verification-needed-artful verification-needed-xenial

Revision history for this message

Harald Sitter (apachelogger) wrote on 2018-04-05:

#29

Pretty sure the change caused bug #1761478

Revision history for this message

Brian Murray (brian-murray) wrote on 2018-04-05: Re: [Bug 1705345] Re: Installing packages hangs on plymouth --ping

#30

On Thu, Apr 05, 2018 at 11:08:55AM -0000, Harald Sitter wrote:
> Pretty sure the change caused bug #1761478

That is incorrect.

--
Brian Murray

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-04-12:

#31

This bug was fixed in the package plymouth - 0.9.2-3ubuntu19

---------------
plymouth (0.9.2-3ubuntu19) artful; urgency=medium

* debian/patches/timeout-for-ping.ptach: Don't wait forever for a reply from
a ping command. (LP: #1705345)

-- Brian Murray <email address hidden> Mon, 02 Apr 2018 10:47:26 -0700

Changed in plymouth (Ubuntu Artful):
status:	Fix Committed → Fix Released

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2018-04-12: Update Released

#32

The verification of the Stable Release Update for plymouth has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-04-12:

#33

This bug was fixed in the package plymouth - 0.9.2-3ubuntu13.4

---------------
plymouth (0.9.2-3ubuntu13.4) xenial; urgency=medium

* debian/patches/timeout-for-ping.ptach: Don't wait forever for a reply from
a ping command. (LP: #1705345)

-- Brian Murray <email address hidden> Mon, 02 Apr 2018 10:55:21 -0700

Changed in plymouth (Ubuntu Xenial):
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

Duplicates of this bug

Bug #1715830
Bug #1723451
Bug #1723806
Bug #1725525
Bug #1730740
Bug #1730935
Bug #1737025
Bug #1737860
Bug #1742293
Bug #1744874
Bug #1745791
Bug #1746805
Bug #1747518
Bug #1747579
Bug #1747581
Bug #1747671
Bug #1747681
Bug #1747683
Bug #1747732
Bug #1747772
Bug #1747832
Bug #1747861
Bug #1747866
Bug #1747885
Bug #1748106
Bug #1748370
Bug #1748390
Bug #1748587
Bug #1748727
Bug #1748917
Bug #1749012
Bug #1749038
Bug #1749145
Bug #1749550
Bug #1749726
Bug #1750871
Bug #1751382
Bug #1751416
Bug #1752159
Bug #1761063

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

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

Ubuntuplymouth package

Installing packages hangs on plymouth --ping

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
plymouth package