RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1947832 - initrd: IPv6 from RADVD is prioritized over IPv4 from DHCP causing fail to download installation image
Summary: initrd: IPv6 from RADVD is prioritized over IPv4 from DHCP causing fail to do...
Keywords:
Status: CLOSED DUPLICATE of bug 1961666
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: beta
: ---
Assignee: NetworkManager Development Team
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1814038 1954580
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-09 11:13 UTC by Jiri Konecny
Modified: 2021-06-29 13:52 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-29 13:52:23 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)
journal.log (2.45 MB, text/plain)
2021-04-09 11:27 UTC, Jiri Konecny 		no flags Details
View All

Description Jiri Konecny 2021-04-09 11:13:20 UTC 
Description of problem:

We have multiple subnets with one DHCPD server. This DHCP server correctly assigning IP addresses to installed systems or older installations without NM in the initrd, however, when NM is in the initrd the installation boot will fail most of the time when trying to download stage2 image.

From logs the problem seems to be that IPv6 address is assigned by RADVD and after that will happen installation will start to download stage2 image which is however, accessible only from the IPv4 address. Unfortunately, when IPv6 is assigned, DHCP client for IPv4 is cancelled. The IPv4 address is sometimes received later after a few stage2 images download failures, sometimes never in that case the installation will fail.


Version-Release number of selected component (if applicable):
NetworkManager-1.32.0.0-1

How reproducible:
Depends on RHEL/Fedora version. For RHEL 8.5 I'm able to boot most of the time but the download will fail a lot of time and slowing installation a lot.

Steps to Reproduce:
1. Boot the installation with DHCP server (ideally on other subnet with DHCP-relay)
2. Use inst.stage2= kernel boot argument to download image from the IPv4 address on the second server.

Actual results:
Installation will fails to download stage2 image completely or a lot of times.

Expected results:
Installation boot should correctly obtain IPv4 address.

Additional info:
This is for some reason not happening on VLAN where the DHCPD server is present but only in the other subnet (could be other router configuration?). 

Workaround for this is to pass 'ipv6.disable=1' on the kernel boot cmdline.

We switched our DHCP server from RHEL-5 to RHEL-8 so it could be that something changed on the default configuration of DHCP server. It did not happened before. However, as said before installed systems/Live DVD/ older initrd without NM are getting the address correctly.

This is happening a lot more on Rawhide and newer Fedora. I'm also able to reproduce this even better on RHEL-8.3.

Please feel free to ping me on IRC to debug this together.
Comment 1 Jiri Konecny 2021-04-09 11:27:38 UTC 
Created attachment 1770571 [details]
journal.log

NM is set to TRACE log level here.
Comment 2 Jiri Konecny 2021-04-12 10:09:12 UTC 
I've changed the workaround from 'ipv6.disable=1' to 'ip=dhcp' works as expected and seems like a cleaner solution.
Comment 6 Thomas Haller 2021-04-14 17:10:30 UTC 
Copied from comment 3 as public comment:


there are several problems here.



The first is that currently NetworkManager is run by the dracut init queue and it quits when it's done configuring the interface.
In this bug report, NetworkManager tries to activate a profile with
 
  ipv4.method=auto
  ipv4.may-fail=yes
  ipv6.method=auto
  ipv6.may-fail=yes

which means, it will be done once any of the address families is completed. At that point, NM is done and no longer around to get IPv4 addresses via DHCP.


In the future that shall improve, because then NetworkManager will run as a systemd service (https://github.com/dracutdevs/dracut/pull/1281). That will improve, because NetworkManger will keep running and eventually configure DHCP. However, also in this mode it will signal "network-online.target" (via "NetworkManager-wait-online.service") before DHCPv4 is configured, so while IPv4 might happen work after a while, that is still not required.


This is still hard to fix, because the reporter might expect that "it just works". But that means to always wait for IPv4 to timeout, in cases where the configuration does not explicitly request IPv4. That seems wrong. If you require IPv4 (and you have IPv6 routers in your network), then you need to tell NetworkManager that IPv4 is required. You can already do that by configuring ip=dhcp. The old dracut module behaved differently here, because it would simply set accept_ra=1 sysctl and run dhclient (this would wait for timeout, which seems undesirable).


We also want to improve NetworkManager's API so that you can request what is required more granularity. For example, currently you would need to say "ipv4.may-fail=no" to ensure that IPv4 is ready (when also an IPv6 router is on the network). But that means, it will fail if DHCP is not working. What one might want, is opportunistic DHCP, so that you say "ipv4.dhcp=opportunistic && ipv4.dhcp-timeout=20". The closest you can do currently is "ipv4.may-fail=yes && ipv4.dhcp-timeout=infinity" (in which case NetworkManager will happily accept no DHCP, but after a hard-coded timeout -- which might be too long and not configurable). So, there is room for improvement in NetworkManager. But even with those improvements, these behaviors need to be controlled in initrd by configuring the right book parameters. By default I still don't think that NetworkManager should wait that both IPv4 and IPv6 is configured, because that means to wait for a timeout.



Short answer:

- In the future that should improve here by running NetworkManager as systemd service

- if you require IPv4 and your network provides an IPv6 setup, you still will need to configure that (via the kernel boot options).
Comment 8 Till Maas 2021-04-14 18:43:47 UTC 
(In reply to Thomas Haller from comment #6)

> - In the future that should improve here by running NetworkManager as
> systemd service

so can we close this as a duplicate of the bug tracking this (assuming there is one)?
Comment 9 Thomas Haller 2021-04-15 08:18:42 UTC 
> so can we close this as a duplicate of the bug tracking this (assuming there is one)?

There is bug 1814038, which is about running NetworkManager as systemd service in initrd.

Possibly that solves the most important aspects of this bug too (but not all), so once that bug is fixed, we would also consider this one fixed.

Still, the bug about making a major rework (bug 1814038) has several effects and benefits.
This specific bug here might be fixed too, but it more specific and not a duplicate.

I "Depend" this bug on the other one.
Comment 10 Dusty Mabe 2021-05-14 17:20:31 UTC 
some conversation upstream about a potential option without requiring NM to run as a systemd service: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/729
Comment 11 Beniamino Galvani 2021-06-29 13:52:23 UTC 

*** This bug has been marked as a duplicate of bug 1961666 ***
Note You need to log in before you can comment on or make changes to this bug.