Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Fedora 45 Workstation installed with the root filesystem on an encrypted Stratis pool automatically enters emergency mode if the LUKS/Stratis passphrase prompt is left unanswered. Version-Release number of selected component: stratisd-3.9.3-1.fc45; stratisd-dracut-3.9.3-1.fc45 How reproducible: Reproduced on multiple VMs with Stratis pools backed by one or more partitions. Steps to Reproduce: 1. Install Fedora 45 Workstation with / on an encrypted Stratis pool. 2. Boot the installed system until the LUKS/Stratis passphrase prompt appears. 3. Do not enter anything and wait for several minutes. Actual Results: After about two minutes, the system automatically drops into emergency mode. Expected Results: With no passphrase input, I expected the unlock prompt to keep waiting or the boot to fail consistently. Additional info: Installer ISO: Fedora-Workstation-Live-45-20261012.n.0.x86_64.iso Architecture: x86_64 Key versions: systemd 262-3.fc45, dracut 111-4.fc45, cryptsetup-libs 2.8.8-1.fc45 Disk layout: /dev/vda ├─/dev/vda1 BIOS boot partition ├─/dev/vda2 /boot └─/dev/vda3 LUKS-encrypted Stratis pool (remaining disk space) └─pool0 └─root / (only Stratis filesystem; /dev/stratis/pool0/root) Attachments include an approximately eight-minute screen recording of installation, reboot, and waiting at the passphrase prompt, plus the journalctl boot excerpt and initramfs rdsosreport.
Created attachment 2161129 [details] Installation, reboot, and waiting at the passphrase prompt (screen recording).
Created attachment 2161130 [details] journalctl boot log excerpt from the affected VM.
Created attachment 2161131 [details] Initramfs rdsosreport from the affected VM.
found a similar report: https://bugzilla.redhat.com/show_bug.cgi?id=2543511
Is this specific to Stratis? I'm not actually sure if the behavior in this case is defined/documented regardless of the filesystem...
Hi Petr, This is not related to the bugzilla you linked. This is caused by the dracut timeout. If boot does not finish with a given number of minutes, dracut will drop to the emergency shell by default. This behavior can be changed as follows. rd.timeout=<seconds> specify how long dracut should wait for devices to appear. The default is 0, which means forever. Note that this timeout should be longer than rd.retry to allow for proper configuration. from the source: https://man7.org/linux/man-pages/man7/dracut.cmdline.7.html Unless you're asking for us to configure this value to something other than the default in the case of Stratis, I think we should close this.
Hi, This issue appears to be specific to Stratis. On a separate VM without Stratis using the default encrypted disk layout, no timeout occurs and it waits for password forever. I haven't modified any rd.* kernel parameters on the VM with stratis; all at defaults.
Again, this is not specifically related to Stratis. I'm not saying you have changed the default, but other setups have the ability to change the default for their storage stacks on install. It sounds like you are asking for us to also change the default of this parameter: rd.luks.timeout I can ask about this automating this for new installs. In the meantime you can add rd.luks.timeout=0 to the kernel command line if you would like to change this behavior.
John, I don't think the installer writes rd.luks.timeout parameters in any situation, regardless what storage mechanism is in use. The string 'rd.luks' does not appear in the anaconda codebase.
(In reply to Adam Williamson (Fedora) from comment #9) > John, I don't think the installer writes rd.luks.timeout parameters in any > situation, regardless what storage mechanism is in use. The string 'rd.luks' > does not appear in the anaconda codebase. blivet is the part of the installer that is dedicated to storage, and it would naturally manage luks parameters. The string "rd.luks.uuid" does appear in the blivet code base, and if the installer team were to add control of the luks timeout to installation options, I guess it would be done in blivet.
Petr, I concur with John that this behavior that you have reported is not related to Stratis. I believe that this bz should be reassigned to the installer team as an RFE.
Adam, I've done a little more research on the parameters. rd.timeout=<seconds> specify how long dracut should wait for devices to appear. The default is 0, which means forever. Note that this timeout should be longer than rd.retry to allow for proper configuration. The default timeout is 0 (forever for this). This does not appear to be the culprit. rd.luks.timeout=<seconds> specify how long dracut should wait when waiting for the user to enter the password. This avoid blocking the boot if no password is entered. It does not apply to luks key. The default is 0, which means forever. The default is also 0 here (forever). rd.retry=<seconds> specify how long dracut should retry the initqueue to configure devices. The default is 180 seconds. After 2/3 of the time, degraded raids are force started. If you have hardware, which takes a very long time to announce its drives, you might want to extend this value. Requires the dracut initqueue module. This is the most likely culprit. It is a little over 2 minutes (consistent with the user's report) and also matches up with my timeout experiences testing root functionality in Stratis. If enough time passes, the initrd drops to the emergency shell with messages about the initqueue timeout. It's possible that the installer is not currently configuring this behavior, that was mostly a guess. After checking my fedora kernel command line, I don't see that configured for an XFS/cryptsetup configuration. However the installer is one way (possibly the only way based on what I see) that we can configure this behavior according to the dracut documentation even if it not currently set up that way. Furthermore, this is obviously the default behavior as documented by dracut so waiting forever must be a side effect of something that is overriding the default time or blocking the default behavior. One particular difference I noticed in how cryptsetup configures their password prompts and the way we do is we use systemd-ask-passphrase while cryptsetup uses plymouth. This may be the reason cryptsetup waits forever and we do not; systemd-ask-passphrase may be interruptable. I'd have to ask the systemd/plymouth teams about whether this is expected behavior.
Proposing as a Final blocker as a conditional violation of the "Expected installed system boot behavior" criterion - https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior - with reference to the "Encrypted partitions" footnote; you can argue that there's no time limit in "the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)", so the expectation is that you can wait more than three minutes before entering the passphrase.
Note I'm not necessarily expecting to really block the release on these; we may reject them or waive them as raised too late / not practically fixable in time. But as Stratis is an advertised feature of F45, I figured they should at least be flagged up to a wider audience for discussion.
I don't think it makes any sense to propose this as a blocker based on those criteria. Here's what it says precisely: """ In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s). """ This bugzilla is associated with an action where the user waits until the chance to enter the passphrase has gone. The passphrase is prompted for, and the second part is not even checked because the correct passphrase is not provided in the allotted time.
I disagree, I think it's a conditional violation of the criterion, in the case where the user happens to look away or be busy with something else for three minutes. Three minutes is not very long. If the user does that, then they can no longer boot.
Maybe one could plausibly argue that it's the subsequent clause that is being violated. "In all of the above cases, the boot should proceed without any unexpected user intervention being required." Presumably one could claim that expecting the user to be present during that timeout window constitutes "unexpected user intervention being required". Perhaps there is a valid case to be made there.
Discussed at F45 Go/No-Go meeting #2, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-22/f45-final-go-no-go-meeting.2026-10-22-17.00.html . This was rejected on the basis that it *is* a conditional violation of the criteria, but not a serious enough one that we thought it merited blocker status. As we've slipped the release for other reasons, I'm proposing it as an FE; it does seem like it'd be good to fix this for release if we can, it can't be entirely addressed with a post-release update as people may encounter it before updating.
Adam, I have a fix that I've tested queued up. https://github.com/stratis-storage/stratisd/pull/4110
Proposed patch release package is available at: https://copr.fedorainfracloud.org/coprs/packit/stratis-storage-stratisd-4112-copr_pull/ . Petr Sklenar, are you interested in testing?
yes, I am on that: === fedora@fedora:~$ rpm -qa | grep stratis stratis-cli-3.9.1-1.fc45.noarch stratisd-3.9.4~pre-202610231328git38af8d34.fc45.x86_64 stratisd-dracut-3.9.4~pre-202610231328git38af8d34.fc45.x86_64 fedora@fedora:~$ sudo dracut --force --regenerate-all === copr build fixes this issue and it seems to be waiting forever (~15minutes) thanks!
AGREED AcceptedFinalFreezeException Discussed at the 2026-10-26 (blocker / freeze exception) review meeting: This is accepted as an annoying bug that's visible immediately after install, so it can't be entirely fixed with an update (and even after updating, the bug would persist until the initramfs is rebuilt). https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-10-26/f45-blocker-review.2026-10-26-16.00.log.txt
This is tested and the commit is available and it is an accepted freeze exception and it has been released. I'm going to move it into Verified.
By which I meant Modified. Petr can you pick up QA, please?
Oh, we've already pulled the fix into all the stratisd builds for the RCs. I just missed linking the update to the bug.
FEDORA-2026-b0633eb30c (stratisd-3.9.3-3.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-b0633eb30c
To be clear, that means it should be fixed in RC3 and RC4, please verify this.
reproducer : comment 0 Fedora-Workstation-Live-45-1.4 ~ stratisd-3.9.3-3.fc45
:heart:
Huge thanks to the Stratis developers for such a quick turnaround on fixes. also (bz#2543511) FYI : Fedora Linux 45 RC-1.4 was just said as a GO with target date of November 3, 2026.
FEDORA-2026-b0633eb30c (stratisd-3.9.3-3.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.