Bug 1885101 - systemd %post tries to create /etc/resolv.conf, fails in container
Summary: systemd %post tries to create /etc/resolv.conf, fails in container
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-05 04:43 UTC by Martin Pitt
Modified: 2020-12-10 01:15 UTC (History)
11 users (show)

Fixed In Version: systemd-247~rc2-1.fc34 systemd-246.7-2.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-10 01:15:19 UTC
Type: Bug


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.