[10:49] <mpt> Is it possible to resize a LUKS device?
[10:50] <mpt> Is it possible to change the security key for an existing LUKS device?
[10:52] <cjwatson> resize> http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions 2.12 says roughly "yes but it's sufficiently easy to get wrong that you probably shouldn't"
[10:53] <cjwatson> change key> there is a luksChangeKey operation in cryptsetup which I infer is for this, although I don't know about any usage caveats
[10:54] <mpt> "Using something like gparted to resize an encrypted partition is slow, but typically works."
[10:54] <mpt> Reasonable to say that Ubiquity falls under the category of "something like gparted"?
[10:55] <mpt> Basically I'm wondering whether an encrypted device needs to have "New size:" greyed out in its "Change Partition" dialog
[10:55] <cjwatson> It is probably technically possible with the backend tools but I very much doubt that any of it is hooked up properly.
[10:55] <cjwatson> Well, grey it out if it doesn't work and not if it does :-)
[10:56] <cjwatson> I don't know that that needs to be decided in advance
[10:56] <cjwatson> (xnox is at debconf but may have thought about this more)
[10:56] <mpt> Well, in general, if the value of control A affects the sensitivity of control B, then control A should be above and/or to the left of B
[10:56] <mpt> So it would be a layout question
[10:57] <mpt> But "New size:" will be interesting in so many more cases than LUKS, I may just make an exception in this case.
[10:57] <cjwatson> It is already true that not everything is resizable
[10:58] <mpt> Okay, a dependent question
[10:58] <mpt> If a LUKS device *was* resizable, and you shrunk it, would it then be necessary to provide the same "overwrite the leftover space with random data slowly" option that we were talking about last week for whole disks?
[11:01] <cjwatson> Personally I don't think so because the point of that is to hide knowledge of what parts of the encrypted area you're using.  However, we might need it if you *expanded* the device
[11:01] <cjwatson> It's secure initialise, not secure erase
[11:03] <mpt> ah, I see
[11:41] <mpt> "For more security: [ ] Overwrite empty disk space" / "The installation may take much longer."
[13:23] <CIA-7> hw-detect: cjwatson * r1478 ubuntu/ (21 files in 3 dirs): merge from Debian 1.89
[13:49] <CIA-7> ubiquity: cjwatson * r5547 trunk/ (3 files in 2 dirs): Add some more debugging around hw-detect.
[13:53] <CIA-7> ubiquity: cjwatson * r5548 trunk/debian/changelog: releasing version 2.11.13
[18:58] <mterry> ev, do you know what the status of the map source used by libtimezonemap is?  Like, who has the original giant map used to generate the png shards?
[19:03] <stgraber> cjwatson: what are you trying to debug in hw-detect? I have it repeatedly blowing up on my pandaboard, so maybe I can help you ;)
[19:04] <stgraber> well, guessing it might be hw-detect. Last ubiquity entry in the log before the crash is hw-detect being spawned, then I get a backtrace with "oem-config/enable doesn't exist"
[19:18]  * stgraber updates ubiquity and retries
[20:11] <cjwatson> stgraber: may or may not be the same thing, although if you're seeing hw-detect exiting with code 10 then there's a decent chance; what I know so far is that the debconf protocol gets out of sync, so db_go gets the 30 return code from a db_input and then falls over
[21:14] <stgraber> cjwatson: well, it succeded :(
[21:14]  * stgraber checks the exact ubiquity delta
[21:17] <stgraber> maybe that change to hw-detect.patch did some magic, or I just got lucky... anyway, after at least 10 failed installs on that hardware, it finally installed fine using the ubiquity currently in quantal...
[22:08] <cjwatson> stgraber: I wouldn't say no to a debug log with an older version, if you can get one; I certainly didn't intend to fix anything with my recent changes
[22:08] <cjwatson> damn races anyway