Description of problem: On my fedora-28 x86_64 workstation, I'm experiencing a random failure to "switch-root" as appropriate. After the luks password is given, the boot hold and timeout. This seems related to having a network link or not. Version-Release number of selected component (if applicable): dracut-048-14.git20180726.fc28 dracut-network-048-14.git20180726.fc28 dracut-config-rescue-048-14.git20180726.fc28 How reproducible: randomly (seems related to no ethernet network link) Steps to Reproduce: 1. Remove the ethernet wire 2. boot a fedora workstation with luks 3. Actual results: Boot is sometime hold and fall into the rescue shell Expected results: It should boot Additional info: I'm not using any remote network resources (no disk in fstab or else), so I don't know what's holding the boot. At least it seems that the network-online timeout is higher than the switch root timeout.. Also note that I cannot remove the dracut-network module here as It's a dependency of kexec-tools which is needed for various gnome workstation components. This might be a separate issue.
Seems like I have clevis installed on my laptop (but not configured). Does clevis assume the device must be network connected or is it possible to assume keyboard interaction as a fallback when there is no network ?
(In reply to Nicolas Chauvet (kwizart) from comment #1) > Seems like I have clevis installed on my laptop (but not configured). > Does clevis assume the device must be network connected or is it possible to > assume keyboard interaction as a fallback when there is no network ? When the clevis dracut module is installed, it adds a rd.neednet=1 to the cmdline even when it's not used. I wonder if this is the same than bug 1612131 and upstream dracut bug https://github.com/dracutdevs/dracut/issues/407. Could you please do the following to test if that's the case, remove the clevis-dracut package, re-generate your initramfs and add rd.neednet=1 to your kernel command line parameters. And then check if dracut hangs on boot and drops into the rescue shell.
So we've worked around this in the IoT edition with the following: /etc/dracut.conf.d/iot-clevis.conf omit_dracutmodules+="network ifcfg"
(In reply to Javier Martinez Canillas from comment #2) > When the clevis dracut module is installed, it adds a rd.neednet=1 to the > cmdline even when it's not used. I wonder if this is the same than bug > 1612131 and upstream dracut bug > https://github.com/dracutdevs/dracut/issues/407. It seems the kernel default is rd.neednet=1. This holds boot until there is a network link. I explicitly need to set it to 0 to continue boot.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still not suitably resolved
The workaround added for this bug seems to break clevis-dracut entirely. See https://bugzilla.redhat.com/show_bug.cgi?id=1687753#c2
(In reply to Richard W.M. Jones from comment #7) > The workaround added for this bug seems to break clevis-dracut entirely. > See https://bugzilla.redhat.com/show_bug.cgi?id=1687753#c2 In what use case? For Tang unlock, TPM2 or some other one. There is work on a proper fix in progress.
For Tang.
I was able to work around this by re-adding "rd.neednet=1" to GRUB_CMDLINE_LINUX in /etc/default/grub, creating /etc/dracut.conf.d/clevis.conf with the contents of 'add_dracutmodules+="network ifcfg"' then re-generating initrd and /boot/grub2/grub.cfg. I find that it takes a long time to boot compared to a similarly configured CentOS 7 system.
(In reply to Peter Robinson from comment #8) > There is work on a proper fix in progress. Is there some public issue where I can track that work? I think I'm affected by this bug and I'd like to try out potential fixes as soon as possible.
FEDORA-2020-b35219394f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f
FEDORA-2020-d42f4e90f9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9
FEDORA-2020-d42f4e90f9 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d42f4e90f9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-b35219394f has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b35219394f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-d42f4e90f9 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-b35219394f has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.