Comment 23 for bug 1780332

We still have some clouds getting deployed with xenial that rely on this,
however, the workaround works for our purposes.

The only downside is that the workaround will be triggered on Bionic as
well unless a version dependent call will be added to vaultlocker.

On Wed, Oct 10, 2018, 16:31 Dimitri John Ledkov, <email address hidden>
wrote:

> do we need and want to enable udev synchronisation in dmsetup package in
> xenial?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1780332
>
> Title:
> vaultlocker does not ensure that udev is triggered to create /dev/disk
> /by-uuid/<uuid-in-luks-header> symlink and fails
>
> Status in vaultlocker:
> Fix Released
> Status in cryptsetup package in Ubuntu:
> New
> Status in lvm2 package in Ubuntu:
> New
> Status in systemd package in Ubuntu:
> Incomplete
>
> Bug description:
> When an encrypted device is setup up a UUID (osd_fsid) is passed from
> the charm to be used in the cryptsetup command which accepts a UUID to
> place into the LUKS header (shown in cryptsetup luksDump <path-to-
> block-device>).
>
>
> https://github.com/openstack/charm-ceph-osd/blob/stable/18.05/lib/ceph/utils.py#L1788-L1804
> UUID comes from osd_fsid
>
>
> https://github.com/openstack-charmers/vaultlocker/blob/8c9cb85dc3ed5dbf18c66a810d189a5230d85c34/vaultlocker/shell.py#L69-L80
> # else statement is used here
> block_uuid = str(uuid.uuid4()) if not args.uuid else args.uuid
>
> dmcrypt.luks_format(key, block_device, block_uuid) # creates a LUKS
> header
> # ...
> dmcrypt.luks_open(key, block_uuid) # sets up a device with device
> mapper decrypting it via dmcrypt
>
> https://github.com/openstack-
>
> charmers/vaultlocker/blob/d813233179bdf2eec8ed101c702a8e552a966f44/vaultlocker/dmcrypt.py#L44-L56
>
> This UUID is visible in blkid output
>
> /dev/sdc: UUID="<luks-header-uuid>" TYPE="crypto_LUKS"
>
> and a udev rule exists to create a /dev/disk/by-uuid/<luks-header-
> uuid> symlink (which is normally used for filesystem -> block device
> resolution)
>
>
> https://git.launchpad.net/~usd-import-team/ubuntu/+source/lvm2/tree/udev/13-dm-disk.rules.in#n25
> ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
> SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
>
>
> Where vaultlocker fails is in luks_open command (right after
> luks_format)
>
> # cryptsetup --batch-mode --key-file - open UUID=<luks-header-uuid>
> crypt-<luks-header-uuid> --type luks
>
> because it tries to access /dev/disk/by-uuid/<luks-header-uuid> which
> does not exist.
>
> This happens since udev rules are not re-triggered to create this
> symlink after a LUKS device is created.
>
> Solution: call the command below after luks_format before luks_open
>
> udevadm settle --exit-if-exists=/dev/disk/by-uuid/<luks-header-uuid-
> equal-to-osd-fsid>
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/vaultlocker/+bug/1780332/+subscriptions
>
--
Best Regards,
Dmitrii Shcherbakov
Field Software Engineer