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