Bug#799781: device lock race condition between udev and multipathd may cause systemd to abort system boot

Ritesh Raj Sarraf rrs at researchut.com
Mon Oct 5 10:53:18 UTC 2015

On Mon, 2015-10-05 at 08:56 +0000, Baumgartner Niels, Bedag wrote:
> Hi Ritesh
> Sorry for the late response.
> > The fix, that you mentioned for the Shared Lock, does not seem to
> be committed upstream. Neither master, nor Hannes's suse-fixes
> branch.
> > [..]
> > So I guess the question here is, does and if the shared lock have a
> side effect ?
> Maybe we could contact one of the upstream devs and ask them if the
> patch was ever submitted and if so, why it was rejected.
> Also I do not insist on including this patch.  It seems to be one of
> (at least) two solutions for fixing the boot problem, however it
> might prevent further issues.
> The fact remains, that the current package in stable is broken.

The rule for stable updates is to have the same fix present upstream,
and then in the Unstable repo. Neither of which is true in this case.

> > And what Physical Volume does your rootfs reside on ?
> > Is it on the FC SAN or local disk ?
> The PV containing my rootfs LV is on the SAN.

VGs in this case are:

vg_system => 20 GiB
vg_services => 1.0 TiB

Is that correct ?

And from the logs, it looks like these Physical Volumes were created on
top of the SCSI devices ?

> > You mentioned that you are stalled on the Single User Mode prompt.
> Is that correct ? I'm assuming that at that time, your rootfs is not
> mounted ?
> Funny enough in my case, afaik, the / partition was mounted, since
> one path activated in time and the volume group was found.
> The timeout on another path, which resulted in systemd killing udev
> workers, which in turn resulted in failed dependencies, caused system
> to abort the boot procedure.
> But that might just have been coincidence. Sometimes all paths
> initialized successfully and the system started fine, maybe other
> times all of them failed.
> See the attached log (this was with the packages from stable).
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20151005/f69a0aa5/attachment.sig>

More information about the pkg-lvm-maintainers mailing list