On Mon, 2015-09-28 at 01:15 +0300, Tero Marttila wrote: > > When multipath manages to take a lock on the device, > > udev will fail, and consequently ignore this entire event. > > Which in turn might cause the system to malfunction as it > > might have been a crucial event like 'remove' or 'link down'. > > AFAIK this would be relevant if multipathd is running, and a new SCSI > device is hotplugged...? Speculation, not testing, on my part. >
That's a good point. From what I recollect, multipathd is never started in the initrd. Yup... Only multipath binary resides in the initrd, which is responsible only to create the map for the boot LUN (in most usual cases). The DAEMON variable in multipath-tools-boot may be misleading, as it initialized "/sbin/multipath" and not "/sbin/multipathd" So, during boot, with just /sbin/multipath, if the SCSI device is acquired by udev, multipath should just plain fail. Where as Niels (OP) mentioned the issue was seen during early boot. @Niels: 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 ? -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."
signature.asc
Description: This is a digitally signed message part
