True, a mkfs is generally going to take longer than an mkswap and is more likely to hit the race. Thanks, updating the testcase.
** Description changed: Binary package hint: mountall I am using Ubuntu 9.10 with the latest packages applied (apt-get uprade) Version of mountall: 1.0 Expected results: /dev/mapper/tmp should be mounted on /tmp Unexpected results: /dev/mapper/tmp is not mounted on /tmp In my /etc/crypttab I have: tmp /dev/sda2 /dev/urandom tmp swap /dev/sda3 /dev/urandom swap In my /etc/fstab I have (among other lines), this: /dev/mapper/tmp /tmp ext2 relatime 0 2 Most of the time the system boots OK, but /tmp never gets mounted. This appears to be an issue with mountall because if I run mountall from the command line, then /tmp does get mounted. When the /dev/mapper/tmp device is created (part of the cryptsetup process), the mkfs -t ext2 command is run on /dev/mapper/tmp. It appears mountall is not waiting for this to complete. Should there be a timeout for a dynamically created tmp to be available before it is mounted? TEST CASE: 1. select a spare partition on your disk, referred to below as /dev/sdf12 2. install the cryptsetup package from karmic. 3. configure it for use with cryptsetup as a device with a random key by adding this line to /etc/crypttab: - /dev/mapper/cryptswap /dev/sdf12 /dev/urandom swap + /dev/mapper/crypttmp /dev/sdf12 /dev/urandom tmp 4. configure the swap partition to be auto-enabled by adding this line to /etc/fstab: - /dev/mapper/cryptswap none swap sw 0 0 + /dev/mapper/crypttmp /tmp ext2 defaults 0 0 5. reboot - 6. verify that the swap partition is not successfully enabled (either by confirming that the system fails to boot fully, or by checking the output of 'swapon -s') - 7. if necessary to boot the system, reboot to single-user mode, mount -orw,remount /, and comment out the cryptswap line from /etc/fstab + 6. verify that the tmp partition is not successfully mounted (the system should fail to boot fully) + 7. if necessary to boot the system, reboot to single-user mode, mount -orw,remount /, and comment out the crypttmp line from /etc/fstab 8. upgrade to the karmic-proposed version of cryptsetup - 9. re-enable the cryptswap line in /etc/fstab + 9. re-enable the crypttmp line in /etc/fstab 10. reboot - 11. verify that the swap partition has been successfully enabled, by checking the output of 'swapon -s' + 11. verify that the tmp partition has been successfully mount, by checking the output of 'mount | grep /tmp' REGRESSION POTENTIAL: In order to prevent mountall from seeing the block device before it's been formatted / mkswap'ed for use, cryptsetup must create the device under a different name initially, format, and then rename to the public device name. For sanity's sake, the proposed patch does this for /all/ cryptsetup devices, not just those configured for tmp or swap; and there is a small but finite risk that someone will already have a /dev/mapper/${name}_unformatted node on their system that conflicts with one of these devices, causing this device to fail to be set up at boot time due to the name collision. The '${name}_unformatted' temp name was chosen to minimize this risk; I believe the risk is acceptably low for an SRU. -- 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