Hi  Beniamino,

Can you create a scratch build for 8.4.0.z which could be used for initial testing in openshift team?

*** Bug 2005498 has been marked as a duplicate of this bug. ***

I'm reopening the bug as we have tested with NetworkManager-1.30.0-12.el8_4 and the issue is not solved. It seems the bugfix covers only IPv4 stack, whether the reported issue is generic to all IP families. More specifically, the Assisted Installer team is hitting this issue in the reversed scenario comparing to what seems to be tested and fixed here.

+++ Base scenario

With a setup as below

* dual-stack machine
* DHCPv4 server significantly faster than DHCPv6

we get the following result

* IPv4 gets an IP via DHCP and IPv6 does not try anymore

+++ Modified scenario

If we artificially modify it as below

* dual-stack machine
* DHCPv4 server disabled

the machine gets an IPv6 via DHCP.

We have tested the scenario from the comment above using a new scratch build based on

* https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/994
* https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=40333371

I can confirm that delayed DHCPv6 does not cause connectivity issues anymore when used with `ip=dhcp,dhcp6`.

User story and acceptance criteria could be found at https://bugzilla.redhat.com/show_bug.cgi?id=1961666#c22

I have received the following feedback, meaning that this build is not fixing what we expected

>I tested with that new rhcos image and had the same result as before - SNO node got an ipv4 address first and then did not try to get an ipv6 address after. The rootfs url was only resolving via ipv6, so the SNO node continually failed to resolve it as it only had obtained an ipv4 address. I changed the rootfs url to resolve to an ipv4 address and the installation proceeded.

Hi Mat, do you have any chance to get debug logs (with rd.debug) for the failed installation with the scratch build, so that we can understand what went wrong?

Adding @ccrum as owner of the infra where tests happen. Can you by any chance answer the Beniamino's need?

(In reply to Beniamino Galvani from comment #24)
> Hi Mat, do you have any chance to get debug logs (with rd.debug) for the
> failed installation with the scratch build, so that we can understand what
> went wrong?

Hi Beniamino - I'm working on pulling that now. Will get back to you

The acceptance criteria described in comment 20 are about
"ip=dhcp,dhcp6", while in the attached logs I see that "ip=auto" is
used. "ip=auto" was not modified on purpose so that it can be used to
retain the old behavior (wait only IPv4).

I'm not sure this is related, but see also the following FCOS issue:

https://github.com/coreos/fedora-coreos-tracker/issues/1000

where the default was changed from ip=dhcp,dhcp6 to ip=auto to
explicitly keep the old behavior.

Just please note, the https://github.com/coreos/fedora-coreos-tracker/issues/1000 has been created on October 18th whether our previous discussions were happening before October 14th. I think in here we are just affected by the fact that in the meantime there may have been some discussions somewhere that we (as Assisted Installer team) weren't aware of.

Just to summarize, is it a valid saying that for "ip=dhcp,dhcp6" we should expect a timeout for both IPv4 and IPv6 ? If yes, then we can work in the installer to use "ip=dhcp,dhcp6" and not "ip=auto"

(In reply to Mat Kowalski from comment #31)
> Just to summarize, is it a valid saying that for "ip=dhcp,dhcp6" we should
> expect a timeout for both IPv4 and IPv6 ?

Yes, that's correct.

> If yes, then we can work in the installer to use "ip=dhcp,dhcp6" and not "ip=auto".

Mat, are you going to test the scratch build with "ip=dhcp,dhcp6"?

Hi Mat, any news about testing the scratch build?

Since there is no clear justification why this should be backported, I am closing this ticket. If a backport is required again in the future, please re-open this BZ with a clear justification or open a new BZ. Thank you.