[06:33] <tjaalton> hey, there's this nasty bug in lightdm upstart job that causes it to race with plymouth-splash. it's kinda easy to fix, but not for the case where plymouth is on the initrd (like when cryptsetup is used) because it won't emit events to the later phase
[06:35] <tjaalton> so the plan is to create a job that emits an event "on startup or started plymouth-splash"
[06:36] <tjaalton> but is there a 'generic' event for when the system has passed initrd phase?
[07:06] <stgraber> passed the initrd phase => startup
[07:07] <stgraber> upstart only starts when we switch from the initrd to the real system, so "startup" would currently work. Maybe one day we'll have upstart in initrd, then that will no longer be true.
[07:24] <tjaalton> well, that didn't seem to work or I failed in some other way
[07:24] <tjaalton> start on startup or started plymouth-splash
[07:24] <tjaalton> emits plymouth-splash-running-4-shure
[07:25] <tjaalton> and in script; "exec initctl emit --no-wait plymouth-splash-running-4-shure"
[07:25] <tjaalton> but debug log didn't show any sign of that
[07:25] <tjaalton> maybe I'll just try harder this time..
[08:05] <jodh> tjaalton: there is no generic "passed initrd" event as upstart doesn't know about that phase of the boot - it happens before upstart starts.
[08:08] <tjaalton> jodh: ok, the bug in question is https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/982889 and comment #120 is what I'm trying to accomplish
[08:09] <tjaalton> jodh: should that be possible?
[08:15] <xnox> jodh: tjaalton: don't we emit something to plymouth to indicate that we passed initrd....?
[08:16] <tjaalton> xnox: doesn't work when plymouth was started from initrd
[08:16] <tjaalton> the bug is trivial to fix for the normal case, but the special case makes it.. special
[08:16] <jodh> xnox: we pass "update-root-fs --read-write" to plymouth when the disk is writeable.
[08:17] <xnox> jodh: yeah. which is quite late for this bug, isn't it?
[08:18] <xnox> quite racy with's lightdm starton.
[08:19] <jodh> tjaalton: I think what slangasek actually means in #120 is for this secondary job to check for a "plymouth" process running (or "plymouth --ping" returning successfully).
[08:20] <tjaalton> jodh: yes, maybe it's the details that got me confused then
[08:21] <tjaalton> like, when to run that job
[08:21] <tjaalton> and should it just sleep N until plymouth is running and then emit the event?
[08:22] <tjaalton> maybe it shouldn't have any preconditions, just check for plymouth and be done with it
[08:24] <jodh> tjaalton: that's the only way it could work I think - check "status plymouth-splash" and check "plymouth --ping" return code.
[08:28] <tjaalton> alright I'll give it a go
=== Md_ is now known as Md