Bug 2295215

Hmm, there may not be yet, I just looked at https://github.com/dracut-ng/dracut-ng/commits/main/modules.d/90systemd-cryptsetup and saw nothing in particular that stands out...

recent crypt changes - https://github.com/dracut-ng/dracut-ng/pulls?q=is%3Apr+is%3Aclosed+crypt

I would start by adding https://github.com/dracut-ng/dracut-ng/pull/373. 

If that does not work, perhaps revert https://github.com/dracut-ng/dracut-ng/pull/320

https://github.com/dracut-ng/dracut-ng/issues/333 has some good discussion with additional ideas - e.g. setting rd.auto=0

I just noticed that https://src.fedoraproject.org/rpms/dracut/blob/rawhide/f/0006-fix-crypt-decryption-when-rd.luks.name-is-set.patch is already applied.

hmm, we may want to add rd.auto to rescue mode, but...I'm not sure if rescue mode happens to be *relying* on it to construct things in some other cases...

https://github.com/dracut-ng/dracut-ng/pull/237 could also has some surprising side-effect that can be mitigated on kernel command line.

I'm so sorry I skipped asking for openQA this time. (Will remember to do it next time.)

Should I backport anything in the meantime? Or simply revert?

> With dracut 102, this has changed. You now see the "regular" encryption passphrase prompt during dracut phase

Could you perhaps add a kernel command line option to disable encryption passphrase prompt - e.g. systemd.mask=systemd-ask-password-console.service

Looking at the code, I think this specific issue _is_ caused by the inclusion of PR 373.

Can you check if adding `rd.auto=0` to the kernel command line mitigates the issue?

Ad Comment 8; Sorry, I meant to write PR 320.

I will revert PR 320 for now, as it looks quite unreasonable to me anyway:

https://github.com/dracut-ng/dracut-ng/issues/492

I am not yet convinced that PR 320 is responsible for this change in behavior. 

Can you please land https://github.com/redhat-plumbers/dracut-fedora/pull/33 and confirm that this one single PR revert would restore the earlier functionality fully before we engage in the upstream discussion ? Thank you !

FTR, Laszlo, Fedora is not a testing ground. If you're not able to test whether you're doing breaking changes, you have a blind-spot in the test suite (and those kind of changes should come with some test anyway). I am reverting it because I think it shouldn't be merged in the first place (and I'm keeping the patch).

Okey, noted.

(In reply to Pavel Valena from comment #11)
> FTR, Laszlo, Fedora is not a testing ground. If you're not able to test
> whether you're doing breaking changes, you have a blind-spot in the test
> suite (and those kind of changes should come with some test anyway). I am
> reverting it because I think it shouldn't be merged in the first place (and
> I'm keeping the patch).

For the record, Fedora Rawhide is used as such by *many* upstreams, notably GCC, LLVM, and historically even Dracut. While it's true we want to have as much coverage as possible within Dracut itself, we are not necessarily going to have everything that our downstream users have. And this is simply one of those cases. Obviously, I don't want to solely rely on Fedora Rawhide for that sort of thing, but a productive opportunity would be to help us extend our test suite to cover this gap rather than yelling at us.

But I will also point out as both a member of upstream and a Fedora contributor, the Fedora dracut package using source-git has made things difficult. We are kind of stuck between a rock and a hard place to do anything, since your source-git repo is basically locked to Red Hatters. We have been paralyzed for trying to deliver backport fixes because of this too. There's at least one other bug that has been stuck for weeks because none of us can do anything due to the source-git setup. I will reiterate my request that dracut in Fedora please not use source-git so that normal Fedora packager workflows can function properly.

(In reply to Neal Gompa from comment #13)

> For the record, Fedora Rawhide is used as such by *many* upstreams, notably
> GCC, LLVM, and historically even Dracut. While it's true we want to have as
> much coverage as possible within Dracut itself, we are not necessarily going
> to have everything that our downstream users have. And this is simply one of
> those cases. Obviously, I don't want to solely rely on Fedora Rawhide for
> that sort of thing, but a productive opportunity would be to help us extend
> our test suite to cover this gap rather than yelling at us.

Sure, I do see it an opportunity; I hope to get around to extending test the suite. But at the moment I have other important work I'm afraid. Sorry to get you the impression of yelling, I was just trying to point out that I prefer stability - e.g. ppl being able to boot without issues. Anyway at the same time, I always welcome new features. I just do not think fitting the upstream by tweaking defauls hidden in some module just to satisfy one distribution probably wasn't the right choice. And I also think I'm not the only one.

> But I will also point out as both a member of upstream and a Fedora
> contributor, the Fedora dracut package using source-git has made things
> difficult. We are kind of stuck between a rock and a hard place to do

If you rather find creating a PR on github bothersome, feel free to create a PR in pagure. The `source-git` sync works both ways. I just find rebases and cherry-picking easier than handling patches by hand. Also it runs the upstream test suite :).

> anything, since your source-git repo is basically locked to Red Hatters. We

Locked? Probably same as the dist-git, right? But feel free to push commits to dist-git per my previous comment if you find something of urgency to fix - nothing has changed there.

> have been paralyzed for trying to deliver backport fixes because of this
> too. There's at least one other bug that has been stuck for weeks because
> none of us can do anything due to the source-git setup. I will reiterate my
> request that dracut in Fedora please not use source-git so that normal
> Fedora packager workflows can function properly.

I have seen no PR anywhere; may I ask what fix you want delivered? I don't think the source-git interferes with the workflows in any way - do you have some hard argument for that or is that just based on your preference/opinion?

FEDORA-2024-0495a4da6c (dracut-102-2.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0495a4da6c

FEDORA-2024-0495a4da6c (dracut-102-2.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-18215bc41f (dracut-102-2.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-18215bc41f

FEDORA-2024-18215bc41f has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-18215bc41f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-18215bc41f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-18215bc41f (dracut-102-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.