System does not booth with last plymouth. SAK needed to unlock it.

The apport information in your report shows a root device of /dev/mapper/sda6_crypt. Are you using cryptsetup to decrypt this at boot time? What version of cryptsetup do you have installed?

It also shows that you're booting without the 'splash' option - why is this?

If you're using cryptsetup, plymouth should be included in the initramfs and already started before ever switching to the root filesystem, so it shouldn't matter what's listed as the start condition for plymouth.

The post-start command you've added in the plymouth job is definitely wrong.

I'm using cryptsetup 2:1.1.0~rc2-1ubuntu12 to unlock the root filesystem (sda6_crypt) and the home filesystem (sda7_crypt) that is unlocked with a keyfile located into the root fs.
Here's my /etc/crypttab

sda5_crypt /dev/sda5 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap
sda6_crypt /dev/disk/by-uuid/9fb5d009-5509-4886-9324-b43d9fd0d161 none luks
sda7_crypt /dev/disk/by-uuid/5402c06c-196d-4d97-a3da-ec45ff103ac0 /etc/crypt.key luks

I don't really know why I'm booting without the "splash" option, I can only think I don't remember having removed it from /etc/default/grub. Should I put it there? I thought that without the splash option plymouth would fallback to the text theme (if there is one)

root@Jarvis:~# plymouth-set-default-theme --list
details
fade-in
glow
script
solar
spinfinity
text
ubuntu-logo

Isn't the "script" one?

The only thing I want to clearly point out is that before "patching" the plymouth.conf file my system did not boot. It forced me to Alt+SysRq+K it and drop to a root shell prompt.
So I understand that you - a developer - knows that the post-start command is wrong, but now my system boots quite as fast as it did with 0.8.0-~8 (later versions did not boot) so I think about what may be wrong with it.

Looking at the attachments in this bug report, I noticed that "plymouth.diff" was flagged as a patch. A patch contains changes to an Ubuntu package that will resolve a bug, since this was not one I've unchecked the patch flag for it. In the future keep in mind the definition of a patch. You can learn more about what qualifies as a patch at https://wiki.ubuntu.com/Bugs/Patches. Thanks!

Yes, plymouth should fall back to the text plugin when not given 'splash', but you may have found a problem that's specific to the text plugin so I think we want to verify whether it happens when using splash.

Also, if plymouth is running in the initramfs like it should be, it doesn't matter what start condition the upstart job lists, because the process should already be running. So there are several possible causes here, none of which are reproducible for me:

 - plymouth is not present in the initramfs
 - plymouth is failing to start in the initramfs and cryptsetup is falling back to direct prompting for decrypting the root filesystem
 - plymouth is starting, but exiting abnormally after decrypting the root filesystem
 - plymouth is failing to write out the PID file to /dev/.initramfs/plymouth.pid
 - the PID file is getting written, but isn't being transferred correctly when chrooting to the real filesystem
 - the PID file is getting written, but upstart isn't picking it up properly

Perhaps there's something you're seeing that suggests which of these is taking place, so we can narrow the search.

I don't know how to verify it, but I can exclude tha last 2 entries as sudo
ls -la /dev/.initramfs returns the following:

root@Jarvis:/dev/.initramfs# ls -la
totale 0
drwxr-xr-x 2 root root 40 2010-02-25 13:14 .
drwxr-xr-x 16 root root 3880 2010-02-25 15:50 ..

I have also found this:

root@Jarvis:/var/log# grep plymouth daemon.log*
daemon.log:Feb 22 09:46:28 Jarvis init: plymouth-splash pre-start process
(1258) terminated with status 111
daemon.log:Feb 23 10:18:27 Jarvis init: plymouth-splash pre-start process
(1222) terminated with status 111
daemon.log:Feb 23 10:33:58 Jarvis init: plymouth main process (332) killed
by TERM signal
daemon.log:Feb 23 10:35:34 Jarvis init: plymouth main process (381) killed
by TERM signal
daemon.log:Feb 24 10:15:52 Jarvis init: plymouth main process (360) killed
by TERM signal
daemon.log:Feb 24 14:12:32 Jarvis init: plymouth main process (347) killed
by TERM signal
daemon.log:Feb 25 09:20:58 Jarvis init: plymouth main process (340) killed
by TERM signal
daemon.log:Feb 25 13:14:27 Jarvis init: plymouth main process (383) killed
by TERM signal
daemon.log.1:Feb 17 11:38:04 Jarvis init: plymouth main process (341) killed
by TERM signal
daemon.log.1:Feb 17 12:09:24 Jarvis init: plymouth-splash pre-start process
(1549) terminated with status 111
daemon.log.1:Feb 18 09:31:25 Jarvis init: plymouth-splash pre-start process
(1390) terminated with status 111
daemon.log.1:Feb 19 11:47:54 Jarvis init: plymouth-splash pre-start process
(1710) terminated with status 111
daemon.log.1:Feb 19 20:04:04 Jarvis init: plymouth-splash pre-start process
(1571) terminated with status 111
daemon.log.1:Feb 20 11:26:22 Jarvis init: plymouth-splash pre-start process
(1499) terminated with status 111
daemon.log.1:Feb 20 17:22:23 Jarvis init: plymouth-splash pre-start process
(1552) terminated with status 111
daemon.log.1:Feb 21 09:57:29 Jarvis init: plymouth-splash pre-start process
(1535) terminated with status 111

Please let me know if there's something else I can provide.

On Thu, Feb 25, 2010 at 11:13, Steve Langasek
<email address hidden>wrote:

> Yes, plymouth should fall back to the text plugin when not given
> 'splash', but you may have found a problem that's specific to the text
> plugin so I think we want to verify whether it happens when using
> splash.
>
> Also, if plymouth is running in the initramfs like it should be, it
> doesn't matter what start condition the upstart job lists, because the
> process should already be running. So there are several possible causes
> here, none of which are reproducible for me:
>
> - plymouth is not present in the initramfs
> - plymouth is failing to start in the initramfs and cryptsetup is falling
> back to direct prompting for decrypting the root filesystem
> - plymouth is starting, but exiting abnormally after decrypting the root
> filesystem
> - plymouth is failing to write out the PID file to
> /dev/.initramfs/plymouth.pid
> - the PID file is getting written, but isn't being transferred correctly
> when chrooting to the real filesystem
> - the PID file is getting written, but upstart isn't picking it up
> properly
>
> Perhaps there's something you're seeing that sugge...

I am wondering if the problems I'm experiencing in bug 499399 are related to this bug. I get similar symptoms: scripts init-bottom are run, then the whole thing hangs.

Output of lshw and a syslog are attached to that bug. (comments 18 and 19)

I also noticed in daemon.log:

Mar 5 22:07:48 localhost init: plymouth main process (219) killed by TERM signal

The output is from an alternate command-line install, as the live CD won't boot.

For what it's worth, the Fedora 12 implementation of Plymouth works on this machine.

Update:
As I've noted in my comments to bug 499399, I found a link between this behaviour and the kernel version that I'm running.

Karmic kernel is fine; various versions of 2.6.32 don't work.

Therefore, it may be a different bug.

On Thu, Feb 25, 2010 at 05:13:46PM -0000, Claudio Moretti wrote:
> sudo ls -la /dev/.initramfs returns the following:

> root@Jarvis:/dev/.initramfs# ls -la
> totale 0
> drwxr-xr-x 2 root root 40 2010-02-25 13:14 .
> drwxr-xr-x 16 root root 3880 2010-02-25 15:50 ..

That's actually inconclusive, because once upstart has read the PID file, it
deletes it.

> I have also found this:

> root@Jarvis:/var/log# grep plymouth daemon.log*
> daemon.log:Feb 22 09:46:28 Jarvis init: plymouth-splash pre-start process
> (1258) terminated with status 111

"111" is "connection refused", which strongly implies plymouth is not
running at this point; but brings us no closer to understanding why.

> Please let me know if there's something else I can provide.

What happens when you boot with 'splash'?

What's the output of: 'zcat /boot/initrd.img | cpio -t |grep plymouth'?

Can you add a script to /usr/share/initramfs-tools/scripts/init-bottom which
checks for /dev/.initramfs/plymouth.pid, and records the result to another
file under /dev/ ? (The script needs to be marked executable, and after
adding it you will need to run 'sudo update-initramfs -u' to have it take
effect).

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

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...