Bug 1885101

Summary:	systemd %post tries to create /etc/resolv.conf, fails in container
Product:	[Fedora] Fedora	Reporter:	Martin Pitt <mpitt>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	fedoraproject, filbranden, flepied, lnykryn, msekleta, ssahani, s, systemd-maint, yuwatana, zbyszek, z
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:	---
Clone Of:		Environment:
Last Closed:	2020-12-10 01:15:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.