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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
