Description of problem: Clevis was unable to unlock a LUKS device on boot with dracut and tang. Turns out the curl call was failing because it was unable to resolve the address. Version-Release number of selected component (if applicable): - dracut-049-27.git20181204.fc31.1.x86_64 - clevis-dracut-11-8.fc31.x86_64 How reproducible: always, with clevis-dracut installed and an initramfs generated afterwards Steps to Reproduce: 1. install clevis-dracut and regenerate the initramfs with dracut -f 2. boot with rd.break=initqueue 3. in the dracut shell, get the network up by running /usr/lib/dracut/hooks/initqueue/settled/99-nm-run.sh 4. Try to have curl work with an address, instead of an IP: curl redhat.com Actual results: curl redhat.com curl: (6) Could not resolve host: redhat.com echo $? 0 Expected results: curl redhat.com <No output for redhat.com, but no errors either. Return code is zero.> echo $? 0 Additional info: Adding /usr/lib64/libnss_dns.so.2 to the initramfs makes the resolver work as expected in this situation.
Also affected by this. Anything we can do to speed things up or get the maintainers to take notice? I find it a bit disconcerting that major functionality (DNS broken in dracut) is not given a higher priority. Sure enough, there's a possible workaround but it's been more than three months since this was reported.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-44b4a2b087
(In reply to Harald Hoyer from comment #2) > https://bodhi.fedoraproject.org/updates/FEDORA-2020-44b4a2b087 Hi Harald, I tested the update in FEDORA-2020-44b4a2b087 and the issue persists. To recap, the issue is: 1) In F30, by including the "network" module, we would be using network-legacy, and this module does include libnss_dns.so.*, which makes it possible to resolve DNS inside the initramfs. 2) In F31 (and F32), by including the "network" module, we are not using network-legacy anymore, but instead, network-manager, and this module does not include the libnss_dns, which in turn makes it impossible to resolve DNS inside the initramfs. A quick grep shows that systemd-networkd also includes that library. I am wondering whether the network-manager module should include it as well. This is a regression in some clevis + tang scenarios.
dracut-050-26.git20200316.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-44b4a2b087
I've also tested with same results as Sergio (ie doesn't fix the DNS resolution issue in dracut). Sergio's workaround of including libnss_dns.so.* is working fine.
dracut-050-26.git20200316.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
Reopening, as the issue still persists.
Upstream issue reported here: https://github.com/dracutdevs/dracut/issues/772
@Harald: can you help with this? As you can see, the problem is *not* resolved.
(In reply to Sergio Correia from comment #8) > Upstream issue reported here: https://github.com/dracutdevs/dracut/issues/772 The issue mentioned above has been resolved (https://github.com/dracutdevs/dracut/pull/800/), so I expect this issue to be resolved with the next dracut release.
FEDORA-2020-03e14f6120 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-03e14f6120
FEDORA-2020-03e14f6120 has been pushed to the Fedora 31 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-03e14f6120` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-03e14f6120 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-03e14f6120 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days