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