[Bug 475936] Re: race condition between encrypted device creation and mountall probing with random-encrypted devices (swap, tmp)

[Dejan]

Hi,

I think this bug has not been fixed. I have the same problem as kapetr.
Encrypted swap is not mounted, but manual swapon activates swap.

kapetr, did you opened new bug? Which number is it?

Thanks

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/475936

Title:
  race condition between encrypted device creation and mountall probing
  with random-encrypted devices (swap, tmp)

Status in “cryptsetup” package in Ubuntu:
  Fix Released
Status in “cryptsetup” source package in Lucid:
  Fix Released
Status in “cryptsetup” source package in Karmic:
  Fix Released

Bug description:
  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       2
  5. ensure the device contains no other filesystem signatures by blanking it with 'dd if=/dev/zero of=/dev/sdf12 bs=$((1024*1024))'
  5. reboot
  6. verify that the tmp partition is not successfully mounted: mountall should refuse to continue booting the system because the device is unavailable.
  7. boot into the rescue shell to comment out the tmp line from /etc/fstab, then reboot
  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'

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/475936/+subscriptions