On Fri, 2020-09-11 at 08:45 +0200, bugs wrote: > Dear maintainer > > > > After several bare-metal re-installations i found a simple > workaround > > which seems to work, at least for me. > > > > I changed the multipathd.service script in systemd as follows: > > > > 3c3 > > < Wants=systemd-udev-trigger.service systemd-udev-settle.service > > --- > > > Wants=local-fs-pre.target multipathd.socket blk- > availability.service > > > > > > May be, there is a conflict or timeout in the udev service? > > > > After this change, the system boots as expected, including all > required > > services.
It shouldn't really have a dependency on that service. I think that service is more related to LVM volumes. Keep in mind that LUN discovery is a time consuming process. And if, like in your case, have a large number of LUNs, the discovery of those LUNs will be time consuming. But irrespective, you shouldn't have any ill effect on your boot. I'm not sure where lies the problem. It could be somewhere in udev taking a lot of time processing its rules. It could also be a problem with multipathd itself. If there were logs, it may be worth looking at. OTOH, I have no access to large SAN arrays, anymore. So I can't really help here. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
