Looks like the VG setup didn't complete quickly enough.  The previous two runs (and all the other paladins) worked fine, so this sounds like a race condition in LVM.  I'll look into adding some retry logic.

This has sporadically hit a couple of other paladins:

https://luci-milo.appspot.com/buildbot/chromeos/veyron_jaq-paladin/2602
https://luci-milo.appspot.com/buildbot/chromeos/rainier-paladin/383
https://luci-milo.appspot.com/buildbot/chromeos/nyan-full-compile-paladin/11777

Looking to see if there's any commonality about when it happens.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/31cf629aad061dbe68a77ed49240c3353eba8d23

commit 31cf629aad061dbe68a77ed49240c3353eba8d23
Author: Benjamin Gordon <bmgordon@chromium.org>
Date: Wed Feb 07 02:19:03 2018

cros_build_lib: Wait for LV to appear before mounting

Sometimes after running lvchange, the device takes a few seconds to
appear.  Check for the device and retry a couple of times as needed to
wait for it.  This is similar to the logic that was previously added to
wait for vgchange.

BUG= chromium:809570 
TEST=cros tryjob edgar-paladin-tryjob

Change-Id: I77648232a7af36285253f5267ae2f90c4dfad063
Reviewed-on: https://chromium-review.googlesource.com/904731
Commit-Ready: Benjamin Gordon <bmgordon@chromium.org>
Tested-by: Benjamin Gordon <bmgordon@chromium.org>
Reviewed-by: Benjamin Gordon <bmgordon@chromium.org>

[modify] https://crrev.com/31cf629aad061dbe68a77ed49240c3353eba8d23/lib/cros_build_lib.py

Are recent failures of betty-arc64-paladin related to this? I filed Issue 809957.

Issue 809957 has been merged into this issue.

The underlying race was triggered on one build in the latest CQ run (https://luci-milo.appspot.com/buildbot/chromeos/link-paladin/30993).  The change in https://crrev.com/c/904731 handled it correctly, so I'm calling this fixed.