Swâmi,
Just confirmed that using the test case in lucid, the /tmp directory
fails to be mounted. However, this is because mountall treats the /tmp
directory specially. Varying the /etc/fstab line in either of two ways
is enough to fix this:
- set the 'pass' option to non-zero
- mount it somewhere other than /tmp
After making either change, mountall successfully mounts the device for
me.
I've updated the test case using the first of these options.
** 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/crypttmp /dev/sdf12 /dev/urandom tmp
4. configure the tmp partition to be auto-enabled by adding this line to
/etc/fstab:
- /dev/mapper/crypttmp /tmp ext2 defaults 0
0
+ /dev/mapper/crypttmp /tmp ext2 defaults 0
2
5. reboot
6. verify that the tmp partition is not successfully mounted by running
'mount | grep /tmp'
- 8. upgrade to the karmic-proposed version of cryptsetup
- 9. re-enable the crypttmp line in /etc/fstab
- 10. reboot
- 11. verify that the tmp partition has been successfully mount, by checking
the output of 'mount | grep /tmp'
+ 7. upgrade to the karmic-proposed version of cryptsetup
+ 8. re-enable the crypttmp line in /etc/fstab
+ 9. reboot
+ 10. 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
