Hello Carlos, On Tue, 2021-12-14 at 19:04 +0100, Carlos Barros wrote: > A server was setup with some disks configured in multipath. > The root filesystem is on LVM on internal disk, not configured for > multipath. > > Then build another lvm configuration on those devices > (/dev/mapper/...) > > Now, every time it starts, lvm takes the /dev/sd.. before multipath > sets /dev/mapper/... up.
This combination of the setup, where you have Multipath + LVM, is a known working config. There are some special tweaks needed though. I don't recollect the exact specifics but basically there might be 2 things. 1. You need to ensure that you run pvcreate on top of the multipathed devices and NOT on the bare SCSI devices. 2. THere's also a filter in /etc/lvm/ where you define the list of SCSI devices that should be blacklisted from LVM. > Also, the booting proccess delays for 2+ minutes, mostly because of > systemd-udev-settle.service: > root@panblando:~# systemd-analyze blame > 2min 22ms systemd-udev-settle.service > 1min 105ms NetworkManager-wait-online.service > 9.983s smartmontools.service > 4.415s dev-mapper-dl380g8\x2d\x2dvg\x2droot.device > > But this service is called from multipath: > [Unit] > Description=Device-Mapper Multipath Device Controller > Wants=systemd-udev-trigger.service systemd-udev- > settle.service > Before=iscsi.service iscsid.service lvm2-activation- > early.service > Before=local-fs-pre.target blk-availability.service > After=multipathd.socket systemd-udev-trigger.service systemd- > udev-settle.service > DefaultDependencies=no > Conflicts=shutdown.target > ConditionKernelCommandLine=!nompath > ConditionKernelCommandLine=!multipath=off > > According to systemd-udev-settle.service(8) it is not recommended, as > that service can fail (in fact, > in the server it fails as systemd says) > I don't recollect the specifics but iirc that service is required for a reason. Remember that, typically, multipath-tools is used in combination with SAN devices which are remote. > I think that the problem is related to multipath, because it did not > setup the devices before lvm, > and maybe the problem is inside the initrd. > Please explore the suggestions I mentioned above. I am fairly sure that it may just be a case of proper blacklisting. > Then I did install multipath-tools-boot but the problem is the same. > The only way is to avoid mounting the filesystems in the LVM (or > umounting them) vgchange -an VG > and do the multipath and mount it, all by hand > Yes. THis is expected behavior. mutliapth can only acquire the device when it is free. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
