Boot with crypt-gpg stuck at password prompt

[lapseofreason]

Describe the bug
I am using crypt-gpg to decrypt a luks partition that contains a volume group with the root partition. However, the boot is stuck at the command prompt, as entering the correct password just displays the password prompt again.

Distribution used
I am using Fedora 36.

Dracut version
dracut-057-3.fc36
dracut-056-1.fc36 (tested by downgrading & running dracut -f --kver ...)
linux-5.19.15-201.fc36.x86_64

Dracut config

add_dracutmodules+=" resume crypt-gpg "
filesystems+=" fat msdos vfat "
# https://bugzilla.redhat.com/show_bug.cgi?id=1754055
omit_dracutmodules+=" systemd systemd-initrd dracut-systemd ifcfg network "

Init system
systemd, but it is excluded in dracut (see config above) for crypt-gpg to work

To Reproduce

1. When the system boots up, a password prompt is presented: Password (XXX on /dev/sdYY for /dev/sdZZ)
2. After entering the (correct) password, the prompt appears again without any error message.
   1. This is subjective, but I think it appears too quicky to have tried to decrypt the partition.
3. After repeating for 3 times, the prompt disappears, but the boot does not continue.
   1. A couple of messages are displayed (No key available with this passphrase (multiple times)), but nothing that stood out to me as being specific enough for debugging.

Expected behavior
After entering the correct password, the partition is decrypted and boot continues normally.

Additional context
I just tried a fresh install of fedora server and ran into the same issues there:
dracut-056-1.fc36
linux-5.17.5-300.fc36.x86_64

[lapseofreason]

After trying out different things, I found out that the following change resolves the issue:

diff -c crypt-gpg-lib.sh.orig crypt-gpg-lib.sh.fixed 
*** crypt-gpg-lib.sh.orig	2022-10-16 15:18:28.978321618 +0200
--- crypt-gpg-lib.sh.fixed	2022-10-16 15:17:37.442958543 +0200
***************
*** 51,57 ****
      fi
  
      ask_for_password \
!         --cmd "GNUPGHOME=$gpghome gpg --card-status --no-tty > /dev/null 2>&1; gpg $opts --decrypt $mntp/$keypath" \
          --prompt "${inputPrompt:-Password ($keypath on $keydev for $device)}" \
          --tries 3 --tty-echo-off
  
--- 51,57 ----
      fi
  
      ask_for_password \
!         --cmd "gpg $opts --decrypt $mntp/$keypath" \
          --prompt "${inputPrompt:-Password ($keypath on $keydev for $device)}" \
          --tries 3 --tty-echo-off
  

I'd be happy to create a pull request, but I am not sure what gpg --card-status is supposed to accomplish and what I need to do to preserve that functionality. Can anyone help me out with that?

[LaszloGombos]

Likely a regression from #1544 ?
CC @LinkTed

[LinkTed]

@lapseofreason Hi, are you using a GPG smartcard?

It is interesting, I do not know why gpg --card-status could cause this. Even if the command fails, the return value is determined by the last command gpg $opts --decrypt $mntp/$keypath.

Could you could try this:

    ask_for_password \
        --cmd "[ \"${useSmartcard}\" = \"1\" ] && GNUPGHOME=$gpghome gpg --card-status --no-tty > /dev/null 2>&1; gpg $opts --decrypt $mntp/$keypath" \
        --prompt "${inputPrompt:-Password ($keypath on $keydev for $device)}" \
        --tries 3 --tty-echo-off

[lapseofreason]

@LinkTed Thank you very much for your reply!

No, I am not using a GPG smartcard. I use a gpg key file + passphrase that is entered by hand.

I tried the command that you proposed, regenerated the initrd and it worked.

Sorry, I made a mistake when saving the file, this is why I initially thought it worked.

In fact, I tried the command you proposed and it did not work: It asks for the passphrase 3 times and then it fails with claiming the passphrase is invalid. Exactly as it was with the current version provided by dracut.

[LinkTed]

@LaszloGombos I will try to make a bug fix for that. Could you also try if it works for you then? Because, I test with a gpg card.

[LinkTed]

@LaszloGombos I will try to make a bug fix for that. Could you also try if it works for you then? Because, I test with a gpg card.

Here is the commit: f65cffa

[lapseofreason]

@LinkTed Thank you very much for the patch!

I tested it with a key file without a gpg card and it works.

[LinkTed]

@lapseofreason Thanks for testing. I would do a PR then.