Bug 1019104

Summary: Interface renaming via ifname does not work for RHEL-6.5
Product: Red Hat Enterprise Linux 6 Reporter: Harald Hoyer <harald>
Component: dracutAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5CC: ashish_bunkar, bugproxy, dracut-maint-list, echo, eddie.wai, hannsj_uhl, harald, jburke, jstodola, mchan, salmy, tlavigne
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
This bug is just a regression, while developing fixes for the RHEL-6.5 erratum and does not have to have an errata doc.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 21:58:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 855142, 886608, 917159    
Attachments:
Description Flags
iSCSI boot kernel panic
none
dmesg
none
init.log with options passed
none
dmesg with rdudevinfo passed
none
init.log with rdudevinfo passed
none
Output of "udevadm test --action=add /sys/class/net/eth1" none

Description Harald Hoyer 2013-10-15 07:41:24 UTC
A bug in the interface renaming was introduced for dracut versions >= 004-327 and < 004-335.

This bug is not present in RHEL-6.4 dracut versions.

The udev rules /etc/udev/rules.d/50-ifname.rules had:

DRIVERS!="?*", GOTO="ifname_end"

which matched any empty string in the list of drivers for an interface.

Because there are empty strings, the correct rule should only match for positives.

DRIVERS=="?*", ....

Comment 1 Harald Hoyer 2013-10-15 07:41:55 UTC
*** Bug 1009718 has been marked as a duplicate of this bug. ***

Comment 2 Harald Hoyer 2013-10-15 07:41:59 UTC
*** Bug 1013158 has been marked as a duplicate of this bug. ***

Comment 3 Harald Hoyer 2013-10-15 07:42:07 UTC
*** Bug 1014123 has been marked as a duplicate of this bug. ***

Comment 4 Harald Hoyer 2013-10-15 07:42:12 UTC
*** Bug 1016827 has been marked as a duplicate of this bug. ***

Comment 5 IBM Bug Proxy 2013-10-15 07:46:17 UTC
Created attachment 812379 [details]
iSCSI boot kernel panic

Comment 6 IBM Bug Proxy 2013-10-15 07:46:25 UTC
Created attachment 812381 [details]
dmesg

Comment 7 IBM Bug Proxy 2013-10-15 07:46:35 UTC
Created attachment 812382 [details]
init.log with options passed

Comment 8 IBM Bug Proxy 2013-10-15 07:46:44 UTC
Created attachment 812383 [details]
dmesg with rdudevinfo passed

Comment 9 IBM Bug Proxy 2013-10-15 07:46:56 UTC
Created attachment 812384 [details]
init.log with rdudevinfo passed

Comment 10 IBM Bug Proxy 2013-10-15 07:47:06 UTC
Created attachment 812385 [details]
Output of "udevadm test --action=add /sys/class/net/eth1"

Comment 13 IBM Bug Proxy 2013-10-17 14:03:49 UTC
------- Comment From mvechava.com 2013-10-17 13:55 EDT-------
Did this fix happen to make it into snapshot 3 or will it be added in a later release?

Comment 16 Michael Chan 2013-10-23 18:21:09 UTC
We are testing to see if this fixes uEFI FCoE boot which doesn't work on RHEL6.5 on Broadcom NICs.

Comment 17 Eddie Wai 2013-10-24 23:17:55 UTC
We have verified that the original reported bug for iSCSI (Bug 1013158) has been fixed with RHEL6.5ss4.

However, during the course of testing, a new iSCSI+multipath installation regression bug has been uncovered which is unrelated to this biosdevname renaming problem.

A new BZ has been created for that:
https://bugzilla.redhat.com/show_bug.cgi?id=1023225

Comment 18 Jan Stodola 2013-10-25 07:48:10 UTC
Thank you for retesting.

Moving to VERIFIED based on comment 17.

Comment 19 IBM Bug Proxy 2013-10-25 16:21:33 UTC
------- Comment From mvechava.com 2013-10-25 16:16 EDT-------
Snapshot 4 fixes this problem for me, as well. This bug may be closed.

Comment 20 errata-xmlrpc 2013-11-21 21:58:55 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, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHSA-2013-1674.html