assertion failure without initramfs: ply-buffer.c:184: ply_buffer_append_bytes: Assertion `buffer != ((void *)0)' failed.

This function is called from many different paths in the code. Could you please boot with the option 'plymouth:debug=file:/var/log/plymouth-debug.log' and attach the resulting file?

Actually, I added some more assertions and settled on the following workaround for now:

--- plymouth-0.8.2/src/main.c 2012-04-14 09:15:23.000000000 -0400
+++ plymouth-0.8.2-patched/src/main.c 2012-04-13 23:38:39.337606192 -0400
@@ -148,6 +148,10 @@
                    const char *output,
                    size_t size)
 {
+ if (state->boot_buffer == NULL) {
+ state->boot_buffer = ply_buffer_new();
+ ply_trace ("on_session_output called with null state->boot_buffer");
+ }
   ply_buffer_append_bytes (state->boot_buffer, output, size);
   if (state->boot_splash != NULL)
     ply_boot_splash_update_output (state->boot_splash,

Added 'plymouth:debug=file:/var/log/plymouth-debug.log' to my default linux boot line and rebooted, but no /var/log/plymouth-debug.log file was created.

Attaching my /boot/grub/grub.cfg file.

Removed "quiet splash" from boot options and also redirected /etc/grub.d/30_os_prober and got an output file this time. Attaching.

Recompiled and installed plymouth with my workaround/patch and rebooted again. Attaching resultant debug file.

The attachment "Workaround for on_session_output() being called with null state->boot_buffer." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Bob,

The debug log you've attached doesn't show this workaround ever being triggered - there are no messages about on_session_output being called with a NULL boot_buffer. I also see that the two debug logs you attached were identical; did you perhaps attach the wrong one the second time, or did no debug log get written the second time?

Anyway, the interesting bit in the log is this:

[ply-terminal-session.c] ply_terminal_session_attach:ptmx not passed in, creating one
[ply-terminal-session.c] open_pseudoterminal:opening device '/dev/ptmx'
[ply-terminal-session.c] ply_terminal_session_attach:could not create pseudo-terminal: No space left on device
[main.c] main:could not create session: No space left on device

This is because plymouth starts before the virtual-filesystems event is emitted, guaranteeing a writable /dev. When using an initramfs, /dev/ will have been mounted before execing init, so this always succeeds; when it fails, attach_to_running_session() will deallocate the boot buffer, and nothing allocates it again the next time this function is called.

That gives enough information to hunt down a proper fix for this, thanks. Marking as triaged.

Newer plymouth upstream includes the following change:

     {
       state.should_be_attached = attach_to_session;
       if (!attach_to_running_session (&state))
- ply_trace ("could not create session: %m");
+ {
+ ply_trace ("could not redirect console session: %m");
+ if (! no_daemon)
+ ply_detach_daemon (daemon_handle, EX_UNAVAILABLE);
+ return EX_UNAVAILABLE;
+ }
     }

   state.boot_server = start_boot_server (&state);

This removes the assertion, but simply by causing plymouthd to exit instead.

That's going to be difficult to correct for. We start plymouth early in order to be able to capture early boot information, and so that mountall can communicate with it for any interactions necessary while fscking the filesystem; so we can't simply start plymouth later once /dev is mounted. So we need to do something other than what upstream has implemented here. If we're going to allow retrying console redirection later, though, we need to carefully examine the failure path in attach_to_running_session().

Oh, in fact this delta is due to a patch in the Ubuntu package (debian/patches/misc-changes.patch). So we're already trying to gracefully handle the missing-ptmx case, just not getting all the way there.

Bob, could you please try the bzr branch at lp:~vorlon/ubuntu/precise/plymouth/lp.981314? I think it should fix this problem correctly, without your workaround.

@#7:
 - The debug log you've attached doesn't show this workaround ever being triggered

I noticed that, too. After compiling the plymouth package from source, I installed all of the resultant .deb files, and I think the problem only happens when the text theme is used.

- I also see that the two debug logs you attached were identical; did you perhaps attach the wrong one the second time, or did no debug log get written the second time?

I dunno. Perhaps the debugging code won't overwrite an existing file?

@#10:
 - Bob, could you please try the bzr branch at lp:~vorlon/ubuntu/precise/plymouth/lp.981314?

Will do. Building now.

New debug log attached.

And with this build, you don't get the assertion failure at all, correct?

This bug was fixed in the package plymouth - 0.8.4-0ubuntu1

---------------
plymouth (0.8.4-0ubuntu1) quantal; urgency=low

  * New upstream release.
    - drop patches originating from or merged upstream: debug-fixes.patch,
      gcc45-arith-workaround.patch,
      main-Don-t-watch-for-keyboard-input-if-no-keyboard.patch,
      upstart-bridge.patch, upstream-*.patch
    - debian/rules: pass --with-log-viewer to explicitly request its
      inclusion.
    - update libplymouth2.symbols.
  * debian/patches/initramfsless-boot.patch: clean up our failure path when
    /dev/pts isn't available yet:
    - don't free a buffer that we might use again later
    - once we've created the session object, keep it around, instead of
      freeing it again and leaving a dangling reference to it in the loop
      exit handler list.
    it's not clear if this was working before, but it definitely hits an
    assert now. LP: #981314.
  * Build with --disable-libdrm_intel on !x86, to avoid an unnecessary
    dependency. LP: #927424.
 -- Steve Langasek <email address hidden> Sat, 05 May 2012 01:19:02 +0000