Same problem with F30 on both client and server.  There are no useful diagnostics.

The problem here as correctly identified by Sergio Correia is that
a workaround added to clevis for bug 1628258 has broken clevis-dracut
in this rather fundamental way.

I rebuilt clevis without various patches and tools, and made it work:
https://koji.fedoraproject.org/koji/taskinfo?taskID=38048355

The patch in question seems to be:
https://src.fedoraproject.org/rpms/clevis/blob/f30/f/0001-Drop-rd.neednet-1-for-the-time-being-so-tpm2-unlock-.patch
but actually I had to drop several more patches and tools before I
managed to get a working build.

(In reply to Richard W.M. Jones from comment #2)
> The problem here as correctly identified by Sergio Correia is that
> a workaround added to clevis for bug 1628258 has broken clevis-dracut
> in this rather fundamental way.

I'm currently pulling my hair out as I'm trying to get clevis(+tang) working on Fedora 31 to unlock my root fs and it just does not work (network card is not enabled in initramfs - hence no IP, yada yada).

Richard: Are you saying that clevis+tang is currently just broken and can not work?

I tried "dracut -f --add=network" and adding "rd.neednet=1" on grub command line but to no avail. Any known workarounds? Some other "secret sauce" in your koji build? Do you think I am seeing a different bug?

(In reply to Felix Schwarz from comment #6)
> (In reply to Richard W.M. Jones from comment #2)
> > The problem here as correctly identified by Sergio Correia is that
> > a workaround added to clevis for bug 1628258 has broken clevis-dracut
> > in this rather fundamental way.
> 
> I'm currently pulling my hair out as I'm trying to get clevis(+tang) working
> on Fedora 31 to unlock my root fs and it just does not work (network card is
> not enabled in initramfs - hence no IP, yada yada).
> 
> Richard: Are you saying that clevis+tang is currently just broken and can
> not work?
> 
> I tried "dracut -f --add=network" and adding "rd.neednet=1" on grub command
> line but to no avail. Any known workarounds? Some other "secret sauce" in
> your koji build? Do you think I am seeing a different bug?

Felix, could you please try this scratch Koji build and see if it helps? https://koji.fedoraproject.org/koji/taskinfo?taskID=38808530
It's built with PR#6 from https://src.fedoraproject.org/rpms/clevis/pull-request/6

Please, also rebuild your initramfs afterwards and undo the grub changes, for the test.

(In reply to Sergio Correia from comment #7)
> Felix, could you please try this scratch Koji build and see if it helps?

Thank you very much for your quick reply. I created a new F31 VM and installed the clevis RPMs from your koji build.

  clevis luks bind -d /dev/vda2 -s 1 tang '{"url":"…"}'

Unfortunately it works only partially:

 - The VM activates the network interface and gets a new IP via DHCP (at least in the default install, did not bother to setup systemd-networkd in the VM at first). Also I think the VM makes a successful request to my tang server:

     tangd[29971]: 192.168.122.235 POST /rec/sBFzW0CiL0E8nEjDQxu7HIdeeQM => 200 (src/tangd.c:165)

 - *Afterwards* the password dialog comes up (maybe it could not process the tang response?). I can enter characters there (at least I see the "*" after typing) BUT when I press enter the password dialog does not change (as if "enter" was not processed). So unfortunately I can not boot the VM.

 - I resetted the VM and stopped the tang server. Next boot I can enter the password (including proper reaction for "enter") BUT boot only progresses until systemd says "reached target basic system" :-(
   On the screen I see many lines with the same error message:

    /lib/dracut/hooks/initqueue/settled/99-nm-run.sh: line 13: basename: command not fouund

In the end with your RPMs my VM is unable to boot at all so this is definitively worse (but the reason I used a fresh install :-) though there are some promising signs.

I guess detailed patch discussion like this might derail this ticket. Should I use another ticket tracker? (github? pagure?)

(In reply to Felix Schwarz from comment #8)
[...]
> I guess detailed patch discussion like this might derail this ticket. Should
> I use another ticket tracker? (github? pagure?)

Thanks for testing, and yeah I think it's better to move the discussion to https://bugzilla.redhat.com/show_bug.cgi?id=1702524. I have replied there.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.