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, <launch...@surgut.co.uk> 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 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
