Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Tested Stratis encrypted pool using Anaconda WebUI custom partitioning on Fedora 45 Workstation Live (20260928.n.0). Installation completed successfully. On boot, Plymouth correctly prompts for the pool password. After entering the password, the system enters emergency mode with: Warning: /dev/stratis/fedorapool/root does not exist Generating "/run/initramfs/rdsosreport.txt" Entering emergency mode. Exit the shell to continue. The pool appears to unlock (password prompt works), but the root filesystem is not found by dracut. This prevents boot on encrypted Stratis pools. Version-Release number of selected component (if applicable): Fedora-Workstation-Live-45-20260928.n.0.x86_64 Additional info: Pool UUID: 0fb7306e-a1d7-4f88-9aea-cc2e405462fb Attached: photos of Plymouth password prompt and emergency mode screen. Reproducible: Always Steps to Reproduce: 1. Install Fedora 45 Workstation Live with Anaconda WebUI custom partitioning. 2. Create a Stratis pool with encryption enabled and set a password. 3. Create root (/) and home (/home) filesystems inside the encrypted pool. 4. Complete installation and reboot. 5. Enter the pool password at the Plymouth prompt. Actual Results: System enters emergency mode with "Warning: /dev/stratis/fedorapool/root does not exist". The pool unlocks but the root filesystem is not found by dracut, preventing boot. Expected Results: System should unlock the encrypted Stratis pool and mount / and /home normally, allowing the system to boot. Additional Information: Pool UUID: 0fb7306e-a1d7-4f88-9aea-cc2e405462fb Installation media: Fedora-Workstation-Live-45-20260928.n.0.x86_64 Environment: KVM/QEMU VM, 4 vCPU, 8 GB RAM, 64 GB disk, BIOS firmware (with biosboot partition) Password prompt appears correctly at Plymouth, so the encryption unlock process works. The issue is in the dracut stage after unlock — /dev/stratis/fedorapool/root is not found. Photos of both the Plymouth password prompt and the emergency mode screen will be attached after submission.
Created attachment 2159070 [details] Plymouth prompt for Stratis pool password Photo of the password prompt at boot.
Created attachment 2159071 [details] Emergency mode after entering Stratis pool password
I was not able to reproduce this with the same image. @abdallahleandrodev do you still have the VM available? If yes, can you boot from LiveCD and get the installation logs (from terminal start the pool using "sudo stratis pool start --name fedorapool --capture-key", then "sudo mount /dev/stratis/fedorapool/root /mnt", logs from the installation will be in /mnt/var/logs/anaconda). If you also could check the grub commandline and screenshot it so we can check whether everything is correct there. Thank you.
Hi Vojtech, Thank you for looking into this. Unfortunately, I had already deleted the original test VM before I saw your request, so I cannot collect the logs from that specific environment. However, I recreated the entire scenario from scratch using the same image (Fedora-Workstation-Live-45-20260928.n.0.x86_64) and the same installation steps (Stratis encrypted pool via Anaconda WebUI custom partitioning). This time, the installation completed and the system booted normally — no emergency mode occurred. The bug did not reproduce on this second attempt. This suggests the issue may be intermittent or dependent on some specific condition at install/boot time. The anaconda logs are not available in the installed system (the installer cleans /var/log/anaconda/ after a successful installation). If you would like, I can boot from the Live CD again and capture the logs during a fresh installation attempt. Just let me know if there are any specific details you want me to check, or if you want me to try reproducing the issue multiple times. Thanks.
I have a VM with five disks, with one Stratis pool. Boot FAILES sometimes. Sometimes / mounts, but /neco and /next do not. Both mount manually in emergency mode. Other times, the pool fails to start and / is unavailable. --- I used rd.systemd.debug_shell=1 and Ctrl+Alt+F9 to collect logs. 'stratis pool list' fails because dbus is unavailable in emergency mode. --- observation about TWO situations: 1. root(like partition root fs /) is attached/mounted in emergency boot, where I could save all the logs. Later on when machine boots I can access these logs. journalctl - lines +- 14060 Dependency failed for neco.mount - /neco Dependency failed for next.mount - /next There were NOT mounted /next or /neco. I did manual mount cmd: mount /neco mount /next And it was successfully mounted! 2. the whole pool is 'broken'. See attached printscreen: error_in_pool.png with errors. No root filesystem --- attached files anaconda-ks.cfg - Kickstart file used to install the VM; describes five disks and the /, /neco, and /next mount points. blkid - UUIDs and filesystem types detected on the disks. fstab - Filesystems and their mount points during boot. journalctl - System boot log, including Stratis errors and the reason for entering emergency mode. lsblk - Tree of disks, partitions, Stratis layers, and mounted filesystems. stratis-pool-list - Attempted pool listing; it contains a traceback caused by missing D-Bus, not a pool list. systemctl-failed - List of systemd units that failed during boot. mount - What was mounted after the emergency mode appears. mount-after-manually-mount - additional partitions were mounted error_in_pool.png - No pool, no root fs. Errors in printscreen only. --- The VM is still available. Let me know if you need more debugging information or would like me to share somehow?
Created attachment 2161188 [details] startis logs for comment 5
Created attachment 2161189 [details] comment 5: No pool, no root fs. Errors in printscreen only.
it seems to be more startis bug
When in emergency mode and D-Bus unavailable, please use stratis-min command-line tool to send commands to stratisd daemon.
Petr, I believe this is a bug. I'm going to put up a fix that I believe should fix the problem you're seeing. Would you be able to test it just to ensure that it resolves the problem?
Petr, if you are interested in testig the fix you can get a Copr rpm at https://copr.fedorainfracloud.org/coprs/packit/stratis-storage-stratisd-master-copr_commit, specifically https://copr.fedorainfracloud.org/coprs/packit/stratis-storage-stratisd-master-copr_commit/build/11155218/ .
Hi, sure about testing. Unfortunately - the same issue happens with copr packages. rpm -qa | grep stratis stratisd-3.10.0~pre-202610151939gitd5856fce.fc45.x86_64 stratis-cli-3.9.1-1.fc45.noarch stratisd-dracut-3.10.0~pre-202610151939gitd5856fce.fc45.x86_64 log: https://psklenar.fedorapeople.org/bz2543511/
Petr, thanks. But it's clear that your test didn't use our new packages, because the error you are reporting no longer exists in those packages. I think that the step that is necessary is to include the updated package in the initramfs and that must have been omitted.
hm, initramfs has to be regenerated by user? , so I did: sudo dracut --force --regenerate-all and the files are same in initramfs and rpm: root@fedora:~# rpm -qf /usr/libexec/stratisd-min stratisd-3.10.0~pre-202610151939gitd5856fce.fc45.x86_64 root@fedora:~# sudo lsinitrd -f /usr/libexec/stratisd-min "$img" | sha256sum 0a6ede2735be3b9b6f2893f46d70a08051f808bc746be8132f66c2aa2382e569 - root@fedora:~# sha256sum /usr/libexec/stratisd-min 0a6ede2735be3b9b6f2893f46d70a08051f808bc746be8132f66c2aa2382e569 /usr/libexec/stratisd-min -------------------------- But the issue still occurs. The case where the root filesystem was mounted in emergency mode no longer happens. Now, the entire pool is broken. I did 20x reboot and Fedora seems to boot more successfully (66%) overall ~ like that your packages fixes the "root(like partition root fs /) is attached/mounted" logs after dracut regeneration: https://psklenar.fedorapeople.org/bz2543511/after-dracut-regenerate/
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. As Stratis is a listed feature of F45, I think we should at least have the discussion whether this needs to be more robust for release.
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.
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 . Accepted as a blocker as a violation of the Basic "Expected installed system boot behavior" criterion, with reference to the footnote "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)" and the Final criterion requiring all filesystem layouts the installer can configure to work.
I tried reproducing this today in a simple setup and couldn't. Just did a single disk VM install with ext4 /boot , biosboot, and an encrypted stratis pool with / and /home volumes. It booted 6/6 times successfully so far. Will fiddle more tomorrow.
Adam, I have a fix that I've tested queued up. https://github.com/stratis-storage/stratisd/pull/4110
(In reply to John Baublitz from comment #19) > Adam, I have a fix that I've tested queued up. > https://github.com/stratis-storage/stratisd/pull/4110 Apologies this is the wrong BZ, I'll go post this on the other BZ around encryption timeout. With regards to this bug, I have reproduced it and have a solution in the works but it only manifests when the pool is made up of multiple disks. In that case, there is a race condition between the attempt to set up the pool and udev registering all of the devices in the pool before the set up request. Sometimes this lines up and works and sometimes it does not. That is why it only appears some of the time. I think it's also worth noting that I experienced a little bit of flaky behavior in the encrypted case where the password was never prompted and the boot just hung. I believe that that is not due to us and may be similar to the original bug report. I also want to call out that for some reason that only happened on the first boot and never again after that.
If you're using 'udevadm settle' to wait for the devices, unfortunately it's racy and systemd refuses to fix it. Long story here: https://github.com/systemd/systemd/issues/40499