Comment 17 for bug 1481536
Revision history for this message
| Steve Langasek (vorlon) wrote Re: [Bug 1481536] Re: "cryptsetup: unknown fstype, bad password or options?" error unlocking / decrypting LUKS volume at boot | #17 |
On Fri, Dec 04, 2015 at 03:51:50AM -0000, Richard Hansen wrote:
> I uploaded Steve's patch to my PPA:
> https:/
> I haven't tested it yet. The patch looks good to me, except I wonder
> whether the call to udev_settle() between the two blkids should be moved
> up to just after $cryptopen (see attached patch). Thoughts?
Since there was not already a udev_settle call there, I assumed (but did not
verify) that cryptsetup operates synchronously, and only returns once the
device mapping has been set up. We should only add one there if someone
confirms that cryptsetup *doesn't* block until the device is created.
I believe the second udev_settle call that you removed is absolutely
required /at that point/. Even if cryptsetup synchronously ensures the
container device mapping has been set up, I don't think it ensures that the
events for the child device have been handled yet - or even added to the
event queue - so udev_settle could still return before vgchange -a has been
run.
But talking through this, I realize this also means that we still need to
call vgchange ourselves, because otherwise there's still a race condition
here even with udev_settle being called a little bit later.
I'll prepare an updated patch, and test it.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://
<email address hidden> <email address hidden>