Hi Steve, I'll give it a shot tonight with a non-zero "pass" entry for /tmp. However per your description I feel that the mountall behaviour is definitely wrong, and I'm not sure whether another bug report should be filed, or if this precise bugreport should be reaffected to "mountall", as this is the precise problem that this bug describes.
I have rethought about this, and as long as cryptsetup does its job (which is to create and format the temporary encrypted fs), the race condition cannot be considered a cryptsetup bug, the problem comes from the fact the things are'nt called in the right order or mountall doesn't wait for the things it triggers to be finished (filesystems to be ready) before going on. I had initially filed a separate bug report (#493480) about this, againts upstart, bug this bug report was marked as a dup of the present one, so that's why I'm here, but I never considered this race condition to be something that would to possible be solve in cryptetup itself and alone - which I state in my initial bugreport. I feel that, as the current bugreport has already some discussions and details about the issue, it would probably make more sense to reaffect this bugreport to mountall rather than have to create yet another one (that might end being marked again as a duplicate of this one). -- race condition between encrypted device creation and mountall probing with random-encrypted devices (swap, tmp) https://bugs.launchpad.net/bugs/475936 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
