initrd is blocked because of conflict between multipathd.service and initrd-cleanup.service

[jiayi0118]

Describe the bug
initrd is blocked after Finished dracut pre-pivot and cleanup hook and initrd-cleanup.service is not activated.

Distribution used
openEuler

Dracut version
059

Init system
systemd

To Reproduce
Install multipath-tools in the system, and use dracut --no-hostonly to generate the initramfs. And there should be at least a multipath disk in the system.

Expected behavior
initrd-cleanup.service should be activated and dracut continues switching root

Additional context
In previous commit 02e646f, multipathd.socket is injected into initramfs when multipath module is added. And in the hook script multipathd-needshutdown.sh in cleanup, multipath -l -v1 is called. If there is a multipath block discovered, multipathd.service will be activated by multipathd.socket. However, multipathd.service is configured to be before and be conflict with initrd-cleanup.service, which results in initrd-cleanup.service can not be activated and initrd is blocked.

[LaszloGombos]

CC @cthbleachbit

Related - #2175

[cthbleachbit]

I was sure that systemd won't even try to activate the socket at boot at the time before I checked in #2010 but I'm not so sure now and I no longer have access to that physical machine that boots from a multipath device...

Let me repeat the experiment in a VM. If this breaks latest installations somehow in the worst case feel free to revert #2010.

[cthbleachbit]

Current observations:

• (New behavior?) "enabling" a service will automatically enables whatever it has specified in a Also= directive. This implies that multipath.socket gets enabled in the initrd.
• dracut sets up the correct mp block device and kills multipathd (effectively stopping the service) but does not stop the socket.
• dracut multipath clean up will call multipath binary which in turn queries multipathd on the socket path, causing systemd to bring up multipathd.service again post-mortem. At this point initrd-cleanup gets blocked.

I can think of two way out:

• Right now I'm no longer seeing systemd whining about missing auxillary units during initrd build - so I assume we can safely skip multipathd.socket for installation. Revert 90multipath: install multipathd.socket #2010 would do.
• Or, explicitly disable multipathd.socket after enabling multipathd.service.

For OP if you need a workaround right now:

• At bootloader specify rd.break=cmdline. This drops you in the emergency shell.
• Check whether multipathd.socket is enabled and running - if it is running, stop the socket.
• Exit the shell and it should boot up fine.

[jiayi0118]

I can think of two way out:

• Right now I'm no longer seeing systemd whining about missing auxillary units during initrd build - so I assume we can safely skip multipathd.socket for installation. Revert 90multipath: install multipathd.socket #2010 would do.
• Or, explicitly disable multipathd.socket after enabling multipathd.service.

Both ways can deal with this problem.