Description of problem: During the kickstart of the cloud image, NetworkManager writes an /etc/resolv.conf that contains nameserver 192.168.122.1. This causes boot delays with cloud-init since it does some early boot DNS redirection tests before talking to the cloud's metadata service. On some clouds/architectures, this delay is 15 seconds or more. To fix this, the /etc/resolv.conf needs to be truncated so it can be replaced properly by NetworkManager and cloud-init on the first boot. Additional info: This was fixed by Major Hayden in Rawhide in https://pagure.io/fedora-kickstarts/pull-request/846.
Proposed as a Blocker for 35-final by Fedora user ngompa using the blocker tracking app because: This can cause cloud images to fail to successfully configure and boot in some clouds. This is also kind of retroactively being filed because I cherry-picked it already without realizing I needed to do this: https://pagure.io/fedora-kickstarts/c/32b03e0440a8717277ebfbb51606bd92f328b54c?branch=f35
+3 in https://pagure.io/fedora-qa/blocker-review/issue/552 , marking accepted. Do we actually need to do anything here now, or can we just close it?
I assume at this point we've got a Cloud image build that Major can test with to verify the fix before closing it.
I'll check the latest images from koji at Vexxhost.
x86 looks good. The pre-metadata part of cloud-init was taking 10-15 seconds before and it's now 1 second. The whole cloud-init run was 30-45 seconds and is now 18 seconds. Checking aarch64 now.
aarch64 is down to 1 second for the pre-metadata part and the whole run is under 45 seconds. I'm pretty comfortable saying we've fixed this one.
Excellent, closing it now!