Marking as invalid for systemd since the bug is stale and it remains
unclear if there is a bug in systemd.
** Changed in: systemd (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to s
Could somebody please test this _without_ work arounds on Bionic and
later?
--
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
** Tags added: fr-630
--
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/ syml
xnox,
Hmm, based on my previous notes in #18 it is not clear whether that's
the case.
We would have to test with vaultlocker patched to have the workaround
removed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in
Ping, does vaultlocker work, _without_ work arounds, race free on bionic
and up?
** Changed in: cryptsetup (Ubuntu)
Status: New => Incomplete
** Changed in: lvm2 (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seede
Also reading above comments, did we verify that Bionic is correctly
synchronized, and needs no workaround? It would be nice to reliably
confirm that these things operate race-free in bionic and up, and then
mark this bug to affect only xenial and below.
--
You received this bug notification becau
@xnox
as dmitriis state's we've worked around this issue in vaultlocker;
however I do think that fixing this more generally would be a nice
broader ecosystem step - fixing and underlying race rather than papering
over it in tooling high up the stack is always more preferable.
--
You received thi
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
do we need and want to enable udev synchronisation in dmsetup package in
xenial?
--
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
95-dm-notify.rules in dmsetup is only shipped in bionic and up. So I
suspect that xenial, does not have udev synchronisation in dmsetup
package.
xenial:
https://packages.ubuntu.com/search?suite=xenial&arch=any&searchon=contents&keywords=95
-dm-notify.rules
bionic:
https://packages.ubuntu.com/sear
asi,
Thanks for the guidance.
Attached some outputs.
> Look for "dmsetup udevcomplete" call in udev rules.
ubuntu@maas-vhost6:/lib/udev/rules.d$ grep -RiP udevcomplete
55-dm.rules:ENV{DM_COOKIE}=="?*", RUN+="/sbin/dmsetup udevcomplete
$env{DM_COOKIE}"
> Sometimes it is hidden by the fact tha
Look for "dmsetup udevcomplete" call in udev rules. This is the sync point when
libdevmapper continues. This must be the last call in udev chain rules related
to device-mapper devices.
(Run cryptsetup with --debug and you will see that sync point.)
Sometimes it is hidden by the fact that libdeva
asi,
I would rule out the lack of rules because on both xenial and bionic we
have LVM udev rules with the following line that is supposed to create a
LUKS UUID-based symlink:`
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
htt
If you have properly installed device-mapper udev rules, cryptsetup is
internally synchronized to all symlinks and nodes creation (it should
never return only when udev is finished, that's why libdevmapper
internally uses semaphores and cookies per device).
Calling udev settle is just workaround f
As a hint on reproducing it, it may be a problem on xenial only (which
we used for that deployment) for clean devices.
On a bionic VM it seems like the symlink is created but it's not clear
if luksFormat returns before that symlink gets created or after - this
is the important part because the aut
tl;dr you don't need vaultlocker to reproduce this issue :-)
** Changed in: cryptsetup (Ubuntu)
Status: Incomplete => New
--
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/bu
Dimitri
vaultlocker is a helper tool for managing dmcrypt/LUKS keys in Vault.
vaultlocker provides commands to format a block devices using an
encryption key, and to unlock a block device previously encrypted by
vaultlocker (along with some systemd unit configurations to perform this
action on re
** Tags added: id-5b9a8473a5864f4a45e1c7b6
--
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/
I'm not sure what vaultlocker is.
trigger might be appropriate together with a '--settle' flag, if/where
available.
instead of manually opening things, i'd expect crypttab to be adjusted
with `systemctl daemon-reload` re-run to regenerated systemd-cryptsetup@
units and "open" the encrytped device
19 matches
Mail list logo
