Description of problem:

If a hard requirement of initrd.target fails, systemd just keeps looping in the initrd instead of going to the emergency console.

Version-Release number of selected component (if applicable):

systemd-239-12.git8bca462.fc29.x86_64
Note that this doesn't reproduce on f30 (systemd-241-4.gitcbf14c9.fc30.x86_64).

How reproducible:

Always

Steps to Reproduce:
1. Create a new e.g. "80foobar" dracut module with:

# foobar.service
[Unit]
Description=Foobar
DefaultDependencies=false
Before=initrd.target
ConditionKernelCommandLine=foobar.fail=1

[Service]
Type=oneshot
ExecStart=/usr/bin/false

# module-setup.sh
#!/bin/bash

install() {
        inst_multiple true false

        inst_simple "$moddir/foobar.service" \
                "$systemdsystemunitdir/foobar.service"
        mkdir -p "$initdir/$systemdsystemunitdir/initrd.target.requires"
        ln -s "../foobar.service" "$initdir/$systemdsystemunitdir/initrd.target.requires/foobar.service"
}

2. dracut -f -a foobar

3. Boot system with foobar.fail=1

Actual results:

The foobar.service fails, but systemd keeps switching between starting emergency.target and initrd-cleanup.service and never actually brings up the emergency prompt.

Expected results:

systemd goes to emergency.target and stays there.

Additional info:

Interestingly, adding `systemd.log_level=debug systemd.log_target=console` will eventually stop the loop, so I suspect it's sensitive to timing/ordering of jobs.

From analyzing those logs in the loops before it stops, ISTM like the issue is that `emergency.target` is being overriden by the `systemctl isolate initrd-switch-root.target` call from `initrd-cleanup.service`:

```
[FAILED] Failed to start Foobar.
See 'systemctl status foobar.service' for details.
initrd.target: Job initrd.target/start finished, result=dependency
[DEPEND] Dependency failed for Initrd Default Target.
initrd.target: Job initrd.target/start failed with result 'dependency'.
initrd.target: Triggering OnFailure= dependencies.
emergency.target: Trying to enqueue job emergency.target/start/replace-irreversibly
emergency.target: Installed new job emergency.target/start as 50
emergency.service: Installed new job emergency.service/start as 51
emergency.target: Enqueued job emergency.target/start as 50
foobar.service: Unit entered failed state.
...
emergency.service: Passing 0 fds to service
emergency.service: About to execute: /bin/dracut-emergency
emergency.service: Forked /bin/dracut-emergency as 225
emergency.service: Changed dead -> running
emergency.service: Job emergency.service/start finished, result=done
[  OK  ] Started Emergency Shell.
emergency.target changed dead -> active
emergency.target: Job emergency.target/start finished, result=done
...
emergency.service: Changed dead -> running
...
emergency.target changed dead -> active
```

But then a bit after:

```
initrd-cleanup.service: ConditionPathExists=/etc/initrd-release succeeded.
initrd-cleanup.service: Passing 0 fds to service
initrd-cleanup.service: About to execute: /usr/bin/systemctl --no-block isolate initrd-switch-root.target
initrd-cleanup.service: Forked /usr/bin/systemctl as 288
initrd-cleanup.service: Changed dead -> start
         Starting Cleaning Up and Shutting Down Daemons...
initrd-cleanup.service: Executing: /usr/bin/systemctl --no-block isolate initrd-switch-root.target
initrd-switch-root.target: Trying to enqueue job initrd-switch-root.target/start/isolate
initrd-switch-root.target: Installed new job initrd-switch-root.target/start as 91
emergency.service: Installed new job emergency.service/stop as 123
emergency.target: Installed new job emergency.target/stop as 124
...
emergency.target changed active -> dead
emergency.target: Job emergency.target/stop finished, result=done
[  OK  ] Stopped target Emergency Mode.
```

Note: we've been working around this for now by adding `OnFailure=emergency.target` & `OnFailureJobMode=isolate` to our units. I suspect switching `initrd.target` to `OnFailureJobMode=isolate` as well would achieve the same thing, though I haven't tested it.