This bug was initially created as a copy of Bug #1845885 Description of problem: When installing OCP in a BM environment if there is a *minutes* delay while the nodes are getting their hostnames by dhcp the crio daemon and kubelet will start with the system having localhost.localdomain and the pods won't be able to retrieve their images from the registry Version-Release number of selected component (if applicable): 4.4.6 How reproducible: Install OCP 4.4.6 with a dhcp server that takes some time to send the answers to the DHCP requests of the nodes, the nodes will boot RHCOS and get localhost.localdomain, during that time crio and the kubelet will start with the wrong hostname data. Steps to Reproduce: 1.Run the OCP installation with a dhcp server giving the network data 2.Have a delayed dhcp server to send the hostnames 3.Have the nodes with localhost.localdomain hostnames while crio and kubelet are starting Actual results: The nodes are booting and after a while they will get the proper hostnames but the first pods will stay in a "ContainerCreating" status because they won't be able to pull the images from the registry. Expected results: Nothing of that happens, even if the DHCP answer is long enough, the crio and kubelet daemons should wait to start until the hostname information is the right one (different form localhost.localdomain). Additional info: Telco setups and disconnected environments could face this situation with long delays since the nodes are requesting dhcp data and they are setting the proper hostnames. A workaround that worked for us was to login in each node and run the following commands: sudo systemctl daemon-reload sudo systemctl restart nodeip-configuration.service sudo systemcrl restart crio sudo systemctl restart kubelet.service
Cloned for cherry-picking.
*** Bug 1846286 has been marked as a duplicate of this bug. ***
Closed in favor of 1855877 which contains the fix for this (amoung other bugs) related to hostnames. *** This bug has been marked as a duplicate of bug 1855877 ***