Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2022816 - Symbolic link for /etc/resolv.conf is not created during kickstart Fedora 35
Summary: Symbolic link for /etc/resolv.conf is not created during kickstart Fedora 35
Keywords:
Status: CLOSED DUPLICATE of bug 2032085
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 35
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-12 16:54 UTC by Edgar Hoch
Modified: 2022-08-24 08:12 UTC (History)
16 users (show)

Fixed In Version: systemd-249.9-1.fc35 systemd-249.12-3.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-24 08:12:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 2032085 1 unspecified CLOSED Some variants are missing /etc/resolv.conf symlink (use systemd-resolved) 2022-12-28 08:47:36 UTC

Description Edgar Hoch 2021-11-12 16:54:52 UTC
Description of problem:
On Fedora 34, /etc/resolv.conf was a symbolic link after kickstart installation.
On Fedora 35, /etc/resolv.conf is a file created by NetworkManager.

On Fedora 34, systemd postinstall script creates the symbolic link of /etc/resolv.conf.

On Fedora 35, there is a new package systemd-resolved which contains the part of the postinstall script from systemd on Fedora 34 that creates the symbolic link of /etc/resolv.conf.

But the link is not created. It seams to me that a precondition is not true.

################################################################
if test -d /run/systemd/system/ &&
   systemctl -q is-enabled systemd-resolved.service &>/dev/null &&
   ! mountpoint /etc/resolv.conf &>/dev/null &&
   ! systemd-analyze cat-config systemd/resolved.conf 2>/dev/null | \
        grep -qE '^DNSStubListener\s*=\s*([nN][oO]?|[fF]|[fF][aA][lL][sS][eE]|0|[oO][fF][fF])$'; then
  ln -fsv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
fi
################################################################

On Fedora 34 I see in /var/log/anaconda/journal.log that service systemd-resolved was started and is running (I also did "ps -ef" in my kickstart %post section).

On Fedora 35, I found no running systemd-resolved during kickstart installation.

May it be that because of the split of package systemd in to systemd and systemd-resolved the order of installation is important? Script postinstall of systemd runs "systemctl preset-all". Script postinstall of systemd-resolved checks if service systemd-resolved is enabled. In the logs in /var/log/anaconda/journal.log I see that scriptlet of systemd-resolved is running before scriptlet of systemd.

May it be that service systemd-resolved is not enabled at the time when the scriptlet is running and so /etc/resolv.conf is not created as a symbolic link?

Because /etc/resolv.conf is not a symbolic link, NetworkManager creates the file as normal file and fills it with "search" and "nameserver" entries.


################################################################
Nov 07 13:44:21 anaconda[1964]: anaconda: modules.payloads.payload.dnf.transaction_progress: Installed: systemd-resolved-249.6-2.fc35.x86_64 1636036514 59e7de1798b271c53e617ff879204f27407ff97d5dd982d417bb8ef7479c6b3a
Nov 07 13:44:21 anaconda[1964]: anaconda: modules.payloads.payload.dnf.transaction_progress: Configuring (running scriptlet for): systemd-resolved-249.6-2.fc35.x86_64 1636036514 59e7de1798b271c53e617ff879204f27407ff97d5dd982d417bb8ef7479c6b3a
Nov 07 13:44:21 anaconda[1964]: anaconda: modules.payloads.payload.dnf.transaction_progress: Installed: systemd-249.6-2.fc35.x86_64 1636036514 c653f16fec9c819884ef931927da2a7ef3018c6e288eb40a3f9e93eaf536bdc5
Nov 07 13:44:23 anaconda[2627]: dnf: warning: group systemd-journal does not exist - using root
Nov 07 13:44:23 anaconda[1964]: anaconda: modules.payloads.payload.dnf.transaction_progress: Configuring (running scriptlet for): systemd-249.6-2.fc35.x86_64 1636036514 c653f16fec9c819884ef931927da2a7ef3018c6e288eb40a3f9e93eaf536bdc5
Nov 07 13:44:23  anaconda[2627]: dnf: Creating group input with gid 104.
                                                                  Creating group kvm with gid 36.
                                                                  Creating group render with gid 105.
                                                                  Creating group sgx with gid 106.
                                                                  Creating group systemd-journal with gid 190.
                                                                  Creating group systemd-network with gid 192.
                                                                  Creating user systemd-network (systemd Network Management) with uid 192 and gid 192.
                                                                  Creating group systemd-oom with gid 999.
                                                                  Creating user systemd-oom (systemd Userspace OOM Killer) with uid 999 and gid 999.
                                                                  Creating group systemd-resolve with gid 193.
                                                                  Creating user systemd-resolve (systemd Resolver) with uid 193 and gid 193.
                                                                  Creating group systemd-timesync with gid 998.
                                                                  Creating user systemd-timesync (systemd Time Synchronization) with uid 998 and gid 998.
                                                                  Creating group systemd-coredump with gid 997.
                                                                  Creating user systemd-coredump (systemd Core Dumper) with uid 997 and gid 997.
################################################################


Version-Release number of selected component (if applicable):
Fedora 35 Kickstart
systemd-resolved-249.6-2.fc35.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 35 using kickstart.


Actual results:
/etc/resolv.conf is a normal file.

Expected results:
/etc/resolv.conf should be a symbolic link to the stub.


Additional info:
Bugzilla offers no component "systemd-resolved", so I choosed "systemd".

Comment 1 grumpey0 2021-11-14 18:06:01 UTC
Same thing after installing with Fedora-Everything-netinst-x86_64-35-1.2.iso
resolv.conf is not a sim link 

systemd version = 249.6-2.fc35
systemd-resolved is installed. 

Doing:
sudo dnf reinstall systemd-resolved ends up with an error: 

Running scriptlet: systemd-resolved-249.6-2.fc35.x86_64                                                          
Failed to connect to bus: Invalid argument

Failed to connect to bus: Invalid argument


Is this related to: https://bugzilla.redhat.com/show_bug.cgi?id=2020415

Comment 2 Zbigniew Jędrzejewski-Szmek 2021-12-18 16:08:10 UTC
This is the same as #2032085. I'll push the fix to rawhide for now, and it'll need to be backported to F35 too.

Comment 3 Fedora Update System 2022-01-12 08:20:32 UTC
FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

Comment 4 Fedora Update System 2022-01-12 22:17:35 UTC
FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

Comment 5 Fedora Update System 2022-01-13 01:10:38 UTC
FEDORA-2022-f38f479b8f has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-f38f479b8f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2022-01-15 01:21:15 UTC
FEDORA-2022-f38f479b8f has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Kevin Fenzi 2022-04-13 18:36:33 UTC
Just hit this again on a f35 install + updates. ;(

Comment 8 Frederique 2022-04-27 19:32:25 UTC
Just tried to install Fedora Workstation via Fedora-Server-dvd-x86_64-35-1.2.iso. The installation stops with an error that says that the file resolv.conf doesn't exist. @updates

Comment 9 Kevin Fenzi 2022-04-28 20:31:07 UTC
Note that the updates 'user' is just used for posting update information. Mail sent to it goes to /dev/null (ie, no where). 
Clearning needinfo on it.

Comment 10 Fedora Update System 2022-04-29 15:02:08 UTC
FEDORA-2022-01079468a3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-01079468a3

Comment 11 Fedora Update System 2022-04-30 18:21:16 UTC
FEDORA-2022-01079468a3 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-01079468a3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-01079468a3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2022-05-22 01:23:04 UTC
FEDORA-2022-01079468a3 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 David Tardon 2022-08-24 08:12:34 UTC

*** This bug has been marked as a duplicate of bug 2032085 ***


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