[05:16] <JamesB192> add an 'initctl -emit rootfs_decrypt' or something to the end of the stanza that requires input triggering the next steps.
[05:16] <JamesB192> which is to say probably.
[14:57] <cubicool> Is it possible for an upstart job to "grab focus" somehow during boot and ask the user for some input before continuing? (In my case, to get a password interactively)
[17:29] <cubicool> Is it possible for an upstart job to "grab focus" somehow during boot and ask the user for some input before continuing? (In my case, to get a password interactively)
[17:29] <cubicool> Sorry to keep asking, but my project is pretty much dead until I figure this out. :/
[17:30] <cubicool> I guess I could try the lists.
[18:24] <sadmac> cubicool: I think if you add console output to the job it should do it
[18:24] <sadmac> that's one line
[18:25] <sadmac> "console output"
[18:25] <sadmac> no quotes
[18:25] <cubicool> Well, it certainly prints my output and wants to read input, but the rest of the init continues unhindered.
[18:25] <cubicool> And in my case, the rest of the startup will require a drive being unecrypted via a password.
[18:26] <cubicool> (That is to say, my job already has that line. :))
[18:26] <sadmac> cubicool: ah, I see...
[18:26] <sadmac> cubicool: you need that job not to show up as running until it has what it needs, and you need everything else to wait for that job
[18:26] <cubicool> And so what happens is GDM starts up and my query is still on TTY1, although it's difficult to see because other output has scrolled it off screen.
[18:27] <cubicool> Yes, but the more I learn about upstart the more I think this kind of thing is either not possible or simply not wise.
[18:27] <sadmac> cubicool: depends on what you want to do. drive decryption is typically an initrd issue for us
[18:27] <cubicool> We have a client, however, that must have this functionality; and the distros they could use (Fedora or Ubu) both use upstart now.
[18:28] <cubicool> Really? That's not a bad idea with a sufficiently smart initrd.
[18:28] <sadmac> cubicool: fedora's encrypted root implementation does it in initrd
[18:28] <cubicool> Iinteresting.
[18:28] <sadmac> since, well, root is encrypted
[18:28] <cubicool> In my case now it's not actually /, but a special /data mount.
[18:29] <cubicool> But it needs to be up quick before their proprietary stuff starts up
[18:29] <sadmac> you need to tell their proprietary stuff not to start until /data is ready. what does it start on now?
[18:29] <cubicool> It's hard to say. They can't give us a lot of information.
[18:30] <sadmac> that's kind of a problem
[18:30] <cubicool> All they can tell us is that they must be able to interactively decrypt the drive via a password as one of the VERY first actions. :/
[18:30] <sadmac> that could require adjusting a lot of the surrounding upstart config
[18:30] <cubicool> So probably more sensible to do it in our initrd then?
[18:30] <sadmac> and it does get into things that 0.3.9/0.5 aren't good at (hence 1.0 being a pretty heavy redesign)
[18:31] <sadmac> yeah, do it there.
[18:33] <cubicool> Actually, I can't actually because the initrd just does a pivot_root or whatever. THis particular encfs isn't /...
[18:33] <cubicool> Hmmm.
[18:34] <cubicool> Maybe I'll try and take a look at the source.