| 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. | 05:16 |
| 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) | 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 | Sorry to keep asking, but my project is pretty much dead until I figure this out. :/ | 17:29 |
| cubicool | I guess I could try the lists. | 17:30 |
| sadmac | cubicool: I think if you add console output to the job it should do it | 18:24 |
| sadmac | that's one line | 18:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| sadmac | yeah, do it there. | 18:31 |
| 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:33 |
| cubicool | Maybe I'll try and take a look at the source. | 18:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!