[05:16] add an 'initctl -emit rootfs_decrypt' or something to the end of the stanza that requires input triggering the next steps. [05:16] which is to say probably. [14:57] 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] 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] Sorry to keep asking, but my project is pretty much dead until I figure this out. :/ [17:30] I guess I could try the lists. [18:24] cubicool: I think if you add console output to the job it should do it [18:24] that's one line [18:25] "console output" [18:25] no quotes [18:25] Well, it certainly prints my output and wants to read input, but the rest of the init continues unhindered. [18:25] And in my case, the rest of the startup will require a drive being unecrypted via a password. [18:26] (That is to say, my job already has that line. :)) [18:26] cubicool: ah, I see... [18:26] 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] 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] 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] cubicool: depends on what you want to do. drive decryption is typically an initrd issue for us [18:27] 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] Really? That's not a bad idea with a sufficiently smart initrd. [18:28] cubicool: fedora's encrypted root implementation does it in initrd [18:28] Iinteresting. [18:28] since, well, root is encrypted [18:28] In my case now it's not actually /, but a special /data mount. [18:29] But it needs to be up quick before their proprietary stuff starts up [18:29] you need to tell their proprietary stuff not to start until /data is ready. what does it start on now? [18:29] It's hard to say. They can't give us a lot of information. [18:30] that's kind of a problem [18:30] 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] that could require adjusting a lot of the surrounding upstart config [18:30] So probably more sensible to do it in our initrd then? [18:30] 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] yeah, do it there. [18:33] Actually, I can't actually because the initrd just does a pivot_root or whatever. THis particular encfs isn't /... [18:33] Hmmm. [18:34] Maybe I'll try and take a look at the source.