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.
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 session. c] open_pseudoterm inal:opening device '/dev/ptmx' session. c] ply_terminal_ session_ attach: could not create pseudo-terminal: No space left on device
[ply-terminal-
[ply-terminal-
[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.