Bug 1813019 - UPI installation failed when using static Network config + DNS PTR not set.
Summary: UPI installation failed when using static Network config + DNS PTR not set.
Keywords:
Status: CLOSED DUPLICATE of bug 1804426
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RHCOS
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.5.0
Assignee: Ben Howard
QA Contact: Dusty Mabe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-12 18:11 UTC by Martin Ouimet
Modified: 2020-06-18 20:33 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-18 20:31:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Martin Ouimet 2020-03-12 18:11:08 UTC
Description of problem:


Version-Release number of selected component (if applicable):
4.2 and 4.3

How reproducible:

UPI installation of Openshift 4.2+
PXE boot configuration with static IP and static hostname

Example of PXE configuration

DEFAULT default
TIMEOUT 20
PROMPT 0

LABEL default
    KERNEL http://192.168.2.8/rhcos-4.3.0-x86_64-installer-kernel
    APPEND bootdev=ens4 ip=192.168.3.22::192.168.3.1:255.255.255.0:master2.acocp.rhcasalab.com:ens4:none nameserver=192.168.3.8 rd.neednet=1 initrd=coreos/rhcos-4.3.0-x86_64-installer-initramfs.img console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=vda coreos.inst.image_url=http://192.168.3.8/rhcos-4.3.0-x86_64-metal.raw.gz coreos.inst.ignition_url=http://192.168.3.8/master.ign



Steps to Reproduce:
1. Do not set PTR record in DNS
2. Configure static network in PXE including Hostname
3. Launch bootstrap and masters. 


Actual results:

First boot of CoreOS shows the hostname set correctly. 

After reboot of CoreOS, hostname is set to localhost.

Installation failed because all nodes has hostname localhost. 


Expected results:

Given the fact we set the hostname static through PXE, I would expect hostname to not be altered by DNS PTR check. 



Additional info:

I know good practices are to always have DNS PTR set up, but I got a customer having some constraint in a closed environment were setting PTR is an issue. 

I would like to understand why the reverse DNS check overrides the hostname originally set up by PXE. 

Thanks,

Comment 1 Micah Abbott 2020-03-12 19:24:39 UTC
@behoward this smells similar to BZ#1804426 or perhaps BZ#1763700.  Could you please triage at your convenience and provide guidance?

Comment 3 Dusty Mabe 2020-04-27 19:06:04 UTC
This does look like https://bugzilla.redhat.com/show_bug.cgi?id=1804426 to me.

Comment 4 Ben Howard 2020-05-04 14:48:42 UTC
Can you retry with 4.4? This bug should have been fixed.

Comment 8 Dusty Mabe 2020-06-17 16:21:54 UTC
I'll attempt to verify this one.

Comment 9 Dusty Mabe 2020-06-18 20:31:03 UTC
Ok I went through and executed some reproducers for this. I verified that I *could* reproduce the problem with 4.2 (43.81.202003191953.0) and that the problem is *fixed* in both 4.4 (44.81.202004260825-0) and 4.5 (45.81.202006180929-0).

I did this by running an install with the following command line arguments:

```
console=ttyS0 coreos.inst.install_dev=sda coreos.inst.ignition_url=http://192.168.122.1:8000/config.ign coreos.inst.image_url=http://192.168.122.1:8000/path/to/raw.gz ip=192.168.122.111::192.168.122.1:255.255.255.0:testhost::none:192.168.122.1
```

And verifying:

- 4.3 - the machine came up with the right hostname on first boot, but didn't have the correct hostname set after subsequent boots
- 4.4 - the machine came up with the right hostname on first boot and subsequent boots
- 4.5 - the machine came up with the right hostname on first boot and subsequent boots


The media I used:

- 4.3 rhcos-4.3.8-x86_64-metal.x86_64.raw.gz, rhcos-4.3.8-x86_64-installer.x86_64.iso
- 4.4 rhcos-4.4.3-x86_64-metal.x86_64.raw.gz, rhcos-4.4.3-x86_64-installer.x86_64.iso
- 4.5 rhcos-45.81.202006180929-0-metal.x86_64.raw.gz, rhcos-45.81.202006180929-0-installer.x86_64.iso

I'm going to officially call this a duplicate of 1804426 and close it out as such.

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


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