Trying the systemd 248.8-1.fc34 from koji....the reboot enters the computer into the emergency mode but hitting ctrl-D results in normal boot. sddm comes up very quickly after ctrl-D so it must be failing somewhere before that. FYI.
Do you have logs or other boot messages?
I did not see anything obvious....I can try again to see. What do you need?
For start, 'journalctl -b' from a boot which entered emergency mode.
Created attachment 1832404 [details] journalctl -b
Created attachment 1832405 [details] boot.log
The boot.log from two different systemd (regular and emergency) did not show any difference.
Hmm, maybe it's https://github.com/systemd/systemd-stable/commit/1f77dbfaae. I'll look at this tomorrow.
[ OK ] Created slice Slice /system/configure-printer. [FAILED] Failed to start Dispatch P…ts to Console Directory Watch. See 'systemctl status systemd-ask-password-console.path' for details. [ OK ] Reached target Printer Support. [FAILED] Failed to start Special ha… of early boot iSCSI sessions. See 'systemctl status iscsi-onboot.service' for details. [FAILED] Failed to start OSTree Remount OS/ Bind Mounts. See 'systemctl status ostree-remount.service' for details. So yeah, that commit seems to be the culprit. I thought the problem is because of one of the two first units, but actually it's the third of those: ostree-remount.service has OnFailure=emergency.target, so even though the unit would be silently skipped normally because of the missing start conditions, we now enter emergency.target when it fails to start because of start limiting. I'm not sure why we don't see the issue in the upstream. I installed a fresh F34 machine to test this, and it doesn't reproduce. Anyway, I'll revert the patch in the v248-stable branch. The update has already been obsoleted, so I'll close this.
*** Bug 2013559 has been marked as a duplicate of this bug. ***
Updated to systemd-248.9-1.fc34.x86_64, seems OK, thanks!
I backported the fix for Rawhide too, since it was also affected.