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 1968118 - Dell iDrac network interface (cdc_ether driver) has no ID_NET_NAME_FROM_DATABASE, causing the interface to show as enp... while installing the system
Summary: Dell iDrac network interface (cdc_ether driver) has no ID_NET_NAME_FROM_DATAB...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dracut
Version: 8.4
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Pavel Valena
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-05 14:19 UTC by Renaud Métrich
Modified: 2023-11-14 17:55 UTC (History)
23 users (show)

Fixed In Version: dracut-049-227.git20230725.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-14 15:47:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screenshot of the udev database when booting the 8.4 DVD (80.28 KB, image/png)
2021-06-05 14:21 UTC, Renaud Métrich 		no flags Details
udev database after installing (more recent kernel) (1.16 KB, text/plain)
2021-06-05 14:23 UTC, Renaud Métrich 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github dracutdevs dracut pull 1681 0 None closed udev-rules: make sure the hwdb with ifname renaming rules is around 2023-01-04 08:54:51 UTC
Github dracutdevs dracut pull 2443 0 None Draft feat(hwdb): install hwdb on demand when module is needed 2023-07-24 07:24:27 UTC
Red Hat Product Errata RHBA-2023:7087 0 None None None 2023-11-14 15:47:40 UTC

Description Renaud Métrich 2021-06-05 14:19:23 UTC 
Description of problem:

A customer installing RHEL8.3 DVD or RHEL8.4 DVD on a Dell PowerEdge R640 system sees the iDrac interface be presented as "enp0s20f0..." (by path) instead of "idrac", but only at installation time. Once the system is installed, the correct naming is seen, but the kernel being installed is a more recent one that the DVD one.

Checking the udev database early during installation, there is no ID_NET_NAME_FROM_DATABASE=idrac property, explaining the issue.

This was working fine with RHEL8.2 DVD.

This prevents the admin from installing system using a generic kickstart for Dell systems.


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

kernel-4.18.0-240.el8.x86_64 (RHEL8.3 DVD)
kernel-4.18.0-305.el8.x86_64 (RHEL8.4 DVD)

How reproducible:

Always on customer system
Comment 1 Renaud Métrich 2021-06-05 14:21:00 UTC 
Created attachment 1789073 [details]
Screenshot of the udev database when booting the 8.4 DVD
Comment 2 Renaud Métrich 2021-06-05 14:23:07 UTC 
Created attachment 1789074 [details]
udev database after installing (more recent kernel)
Comment 3 Renaud Métrich 2021-06-05 14:27:39 UTC 
Sorry, this is pure systemd, seems like.
Comment 5 David Tardon 2021-06-08 12:50:54 UTC 
(In reply to Renaud Métrich from comment #3)
> Sorry, this is pure systemd, seems like.

I doubt that. It is something with the installer environment. Either /usr/lib/udev/hwdb.d/20-net-ifname.hwdb is missing or systemd-hwdb-update.service has not been run before systemd-udevd.service is started (.hwdb files are not used by systemd-udevd directly. They must be compiled into binary format first--the file is /etc/udev/hwdb.bin). The former is the case in initrd, because no hwdb files are installed there, but the interface should still be correctly renamed after switch-root (that is what happens on the installed system too, after all).

Besides, there weren't any significant changes in udev between 8.2 and 8.3.
Comment 6 David Tardon 2021-06-08 12:55:07 UTC 
I checked with the 8.4 installation DVD and it seems this should work...

# systemd-hwdb query usb:v413CpA102
ID_VENDOR_FROM_DATABASE=Dell Computer Corp.
ID_MODEL_FROM_DATABASE=iDRAC Virtual NIC
ID_NET_NAME_FROM_DATABASE=idrac

Can we see boot logs?
Comment 8 Renaud Métrich 2021-06-25 07:20:18 UTC 
Moving to NetworkManager since issue is due to using it in the initramfs during installation.
Comment 9 Thomas Haller 2021-06-25 08:03:00 UTC 
please provide debug logs of NetworkManager (or better, the full boot).

I think you do that via `rd.debug` on the kernel command line.
Comment 10 Thomas Haller 2021-08-05 13:07:48 UTC 
Still waiting on more info. Let's move to rhel-8.6
Comment 14 Beniamino Galvani 2021-08-10 06:09:54 UTC 
In initrd there is a "Wired Connection" compatible only with device
eno1, because of command line argument "ksdevice=98:03:9b:98:41:36"
which gets translated into "BOOTIF=01-98-03-9b-98-41-36". So, only
eno1 gets activated; however also other devices (eno2, enp0s20f0u14u3)
are brought up.

We should probably introduce a configuration option to treat as
unmanaged all devices without a candidate connection, and enable that
option via a configuration snippet in initrd.
Comment 15 Thomas Haller 2021-08-10 06:15:21 UTC 
(In reply to Beniamino Galvani from comment #14)
>
> We should probably introduce a configuration option to treat as
> unmanaged all devices without a candidate connection, and enable that
> option via a configuration snippet in initrd.

bug 1650221
Comment 18 sushil kulkarni 2021-11-10 16:48:40 UTC 
Removing from the RPL based on lack of voting from all parties (CEE, Dev, QE). Please add it back if there is agreement to get it on the RPL.

Thanks!
Sushil
Comment 22 Lubomir Rintel 2022-01-05 11:09:34 UTC 
I'm now convinced this is not a NetworkManager problem.

Sure, it would be nice if NetworkManager wouldn't bring up devices it is not configuring, but that wouldn't happen here, because at the time the network is configured for kickstart to be fetched, NetworkManager can't tell that it shouldn't be bringing up the iDRAC interface up.

The interface renaming is supposed to (and in fact always happens) early in the iniramfs, prior to NetworkManager being started.

I've proposed a fix upstream and am going to be reassiging the bug to dracut developers to take a look:
https://github.com/dracutdevs/dracut/pull/1681

In case this needs a workaround, the customer can put something like this into their kickstart file (the pykickstart documentation suggests the %pre sections need to go at the end):

%pre
set -x
trig() { udevadm trigger --action=add --property-match=ID_NET_NAME_FROM_DATABASE=idrac $*; }
ip link set $(trig -v -n |xargs basename) down
trig --settle
%end
Comment 28 Andreas Luik 2022-08-04 14:30:48 UTC 
(In reply to Lubomir Rintel from comment #22)
As I'm facing the same problem on a Dell R640 (usig PXE Boot of 8.6), I tried the proposed work-around, but had to change it as follows:

%pre
set -x
trig() { udevadm trigger --action=add --property-match=ID_NET_NAME_FROM_DATABASE=idrac $*; }
for d in $(trig -v -n | xargs basename -a); do
    ip link set "$d" down
done
trig # using --settle hangs forever
%end
Comment 29 garry.dale 2022-11-17 22:26:20 UTC 
(In reply to Andreas Luik from comment #28)
> (In reply to Lubomir Rintel from comment #22)
> As I'm facing the same problem on a Dell R640 (usig PXE Boot of 8.6), I
> tried the proposed work-around, but had to change it as follows:
> 
> %pre
> set -x
> trig() { udevadm trigger --action=add
> --property-match=ID_NET_NAME_FROM_DATABASE=idrac $*; }
> for d in $(trig -v -n | xargs basename -a); do
>     ip link set "$d" down
> done
> trig # using --settle hangs forever
> %end

I also had similar issue on PowerEdge R650 with 8.5 kickstart. I used this workaround successfully.
Comment 34 Pavel Valena 2023-07-24 08:26:07 UTC 
Tested & posted the fix upstream; prepared PR downstream: https://github.com/redhat-plumbers/dracut-rhel8/pull/27
Comment 38 errata-xmlrpc 2023-11-14 15:47:29 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dracut bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:7087
Note You need to log in before you can comment on or make changes to this bug.