|Summary:||systemd %post tries to create /etc/resolv.conf, fails in container|
|Product:||[Fedora] Fedora||Reporter:||Martin Pitt <mpitt>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||33||CC:||fedoraproject, filbranden, flepied, lnykryn, msekleta, ssahani, s, systemd-maint, yuwatana, zbyszek, z|
|Fixed In Version:||systemd-247~rc2-1.fc34 systemd-246.7-2.fc33||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2020-12-10 01:15:19 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Martin Pitt 2020-10-05 04:43:50 UTC
Description of problem: systemd %post tries to overwrite an existing and working /etc/resolv.conf in a container with a symlink to resolved's file. "Fortunately" this fails: Running scriptlet: systemd-246.6-3.fc34.x86_64 25/27 ln: failed to create symbolic link '/etc/resolv.conf': Device or resource busy warning: %post(systemd-246.6-3.fc34.x86_64) scriptlet failed, exit status 1 The %post script shouldn't fail, but it helps in this case as actually doing that would break DNS in the container. The script merely checks systemctl -q is-enabled systemd-resolved.service which is true in a podman/docker application container (not full system container with pid 1 == systemd), but it will not actually run. Instead, I suggest to check if ../run/systemd/resolve/stub-resolv.conf actually exists before linking to it (otherwise it's *definitively* going to break networking). I'm not sure how reliable this EBUSY is, but let's rather not bet that it will always protect us. Version-Release number of selected component (if applicable): systemd-246.6-3.fc34.x86_64 How reproducible: Always Steps to Reproduce: 1. podman run -it --rm fedora:rawhide dnf install -y systemd Actual results: systemd %post fails Expected results: systemd installs cleanly Additional info:
Comment 1 Zbigniew Jędrzejewski-Szmek 2020-10-05 06:04:33 UTC
resolved might not be running when the scriplet is executed, so we can't rely on the presence of anything in /run. But maybe we should check if the file is not a mountpoint too.
Comment 2 Zbigniew Jędrzejewski-Szmek 2020-11-17 15:53:23 UTC
Fixed in rawhide so far.
Comment 3 Fedora Update System 2020-12-08 19:43:49 UTC
FEDORA-2020-3616681a70 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70
Comment 4 Fedora Update System 2020-12-09 02:21:01 UTC
FEDORA-2020-3616681a70 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3616681a70` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 5 Fedora Update System 2020-12-10 01:15:19 UTC
FEDORA-2020-3616681a70 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.