I've been reading a bit and I understand that the problem is that: a) at a given time during boot, the tmp encrypted partition gets "decrypted" by whatever process that handles /etc/crypttab. b) then, given the "tmp" option is specified in /etc/crypttab, mkfs.ext2 is executed on the given decrypted partition c) however, at "about the same time" udev detects the new decrypted partition, so ultimately mountall will see and mount it d) If at that time mkfs.ext2 has not finished yet, mountall cannot obviously mount the partition. Am I right? I mean, is this the race condition you mean?
In such case, an easy fix could be to pass the -U option to mkfs.ext2 when creating the new filesystem on the /tmp partition, and specifying in /etc/fstab a mount by UUID instead of a partition like /dev/mapper/crypttmp... Than way mountall should not attempt to mount the partition until filesystem is effectively created. Again: am I right? If so, is there any way to do that? In /etc/crypttab I can only set the filesystem type (with tmp=fs) according to man page... A workaround would be to create a fake filesystem name and custom mkfs.myfakefs to do the right thing, but that would be a very ugly hack, and I am not completely sure it would work... Or is there any easier fix? Is the workaround in comment #2 (change init scripts dependencies) a better alternative? I do think it is, but I wonder if new problems might appear... I could even mount /tmp on login via libpam_mount, but I also wonder is there is any problem with that... Thanks in advance, Vreixo -- 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
