Resume mounts /dev/mapper/${dst}_unformatted, breaks GRUB and Apt

[TJ]

14.04 amd64, with LUKS encryption of /boot/ as well LVM VGs with key-files.

The system is configured with GRUB_ENABLE_CRYPTODISK and the /boot/ file-system partition LUKS encrpyted.

After boot it has:

/dev/sda5 > /dev/mapper/LUKS_VG > /dev/VG/
/dev/mapper/VG-rootfs > /
/dev/mapper/VG-usr_local > /usr/local/
/dev/sda3 > /dev/mapper/LUKS_boot > /boot/

A LUKS key-file is read from a location inside the /usr/local/ file-system and used to unlock /dev/sda3 for Linux. /dev/sda3 was separately unlocked by GRUB at boot-time.

After a suspend/resume cycle I noticed that 'mount' reports:

$ mount | grep LUKS
/dev/mapper/LUKS_boot_unformatted on /boot type ext3 (rw)

$ grep LUKS /proc/mounts
/dev/mapper/LUKS_boot_unformatted /boot ext3 rw,relatime,data=ordered 0 0

$ sudo dmsetup info LUKS_boot_unformatted
Device does not exist.
Command failed

$ sudo dmsetup info LUKS_boot
Name: LUKS_boot
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 1
Major, minor: 252, 27
Number of targets: 1
UUID: CRYPT-LUKS1-160fa39a12054ad5be449c2c943fb113-LUKS_boot_unformatted

This causes grub-probe to fail during package upgrades, which in turn breaks Apt:

var/log/apt/term.log:2598:/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/LUKS_boot_unformatted'.

It seems as is mountall is triggered and mounts the temporary name before "/lib/cryptsetup/cryptdisks.functions" finalize_device() renames to the permanent name. It isn't clear if this script is called upon resume as well as at boot-time but it is the only reference I can find to the temporary "_unformatted" device name usage.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1308254

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Steve Langasek (vorlon)]

If mountall is being triggered before the device is in its final location, then this indicates you are referencing the device by uuid in /etc/fstab instead of by its device mapper name. This is not supported; filesystem UUIDs are not unique with device mapper, due to features including multipath, snapshotting, and this device renaming issue you've run into here.

You should fix your fstab to exclusively use the devicemapper names for these devices.