Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
While investigating BZ1545842 we found that a nameserver of 192.168.122.1 is being shipped in the guest images. We noticed that with a recent change in to ifup-post[0] in 7.5 the provided nameserver is being kept after we configure the host. This can lead to weird delays if the provided nameserver is not valid. This is a different interaction then what was in 7.4. Either way we probably shouldn't be shipping a resolv.conf with nameservers in the guest image.
[0] https://github.com/fedora-sysv/initscripts/commit/4da9dbaffba4af74eb632d1a5d10e5c366475516#diff-0d62530925abcdd252ce22c42fdeff8c
Version-Release number of selected component (if applicable):
rhel-guest-image-7.5-106.x86_64.qcow2
How reproducible:
Steps to Reproduce:
1. download rhel-guest-image-7.5-106.x86_64.qcow2
2. inspect existing of /etc/resolv.conf with nameserver 192.168.122.1 defined
3.
Actual results:
Expected results:
Additional info:
Alex, 192.168.122.1 is the dns provided by libvirt, used during the image compose. Almost every existing cloud image contains an /etc/resolv.conv with that nameserver, including CentOS images for example.
I would suggest to revert the change in https://github.com/fedora-sysv/initscripts because I think almost everybody relies on the file being written by NetworkManager / ifup when the DHCP replies to network activation.
Moving to networking sst.
We've updated the openstack image build process to remove these lines in the mean time. I do think we shouldn't be shipping any content in /etc/resolv.conf as it's something that should be specific to the deployed environment. I'd assume this would fall under similar categories as /etc/machine-id or other things that can be cleaned out by running virt-sysprep on the image. One solution is to revert the initscript change, but I think the correct solution would be to ensure we properly clean images after building them.