Bug 816389 - ifcfg-ib / if-up breaks with valid ifcfg-ib0
ifcfg-ib / if-up breaks with valid ifcfg-ib0
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rdma (Show other bugs)
18
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
AcceptedNTH
:
Depends On:
Blocks: F18-accepted/F18FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-04-25 19:45 EDT by joshua
Modified: 2013-11-13 10:24 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 00:30:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description joshua 2012-04-25 19:45:07 EDT
Description of problem:

The file /etc/sysconfig/network-scripts/ifcfg-ib0 contains only:
--------------------
DEVICE=ib0
TYPE=Infiniband
ONBOOT=yes

BOOTPROTO=static
IPADDR=4.0.0.2
NETMASK=255.0.0.0
--------------------

# ifup ib0
Error: an inet prefix is expected rather than "4.0.0.2/".
Error adding address 4.0.0.2 for ib0.
bind: Cannot assign requested address
Ifconfig uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes.
Because Infiniband address has 20 bytes, only the first 8 bytes are displayed correctly.
Ifconfig is obsolete! For replacement check ip.



This issue seems like the same reported in RHEL6 via BZ #721101




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

Fedora 15 x86_64 (all updates as of 4/25/2011)
rdma-1.0-9.fc15.noarch
initscripts-9.30.1-1.fc15.x86_64
Comment 1 joshua 2012-04-25 20:09:05 EDT
I can't imagine that it matters, but in case I'm wrong:

Infiniband is up and happy on my server, at least as far as layers 1 and 2 go.  It can see both sides, etc, etc:

# ibhosts 
Ca	: 0x002590ffff2ebea8 ports 1 "localhost HCA-1"
Ca	: 0x002590ffff1c88d0 ports 1 "localhost HCA-1"

# ibstat
CA 'mlx4_0'
	CA type: MT26428
	Number of ports: 1
	Firmware version: 2.7.200
	Hardware version: b0
	Node GUID: 0x002590ffff1c88d0
	System image GUID: 0x002590ffff1c88d3
	Port 1:
		State: Active
		Physical state: LinkUp
		Rate: 40
		Base lid: 2
		LMC: 0
		SM lid: 1
		Capability mask: 0x02510868
		Port GUID: 0x002590ffff1c88d1
		Link layer: InfiniBand
Comment 2 Doug Ledford 2012-04-26 08:09:50 EDT
Evidently, the rdma package in f15 is a bit behind, this is a known and fixed issue.  Can you pull the f16 rdma package and see if it solves your problem?
Comment 3 joshua 2012-04-26 11:15:06 EDT
It appears to be the same package in both F15 and F16

$ cat /etc/fedora-release 
Fedora release 16 (Verne)

$ arch
x86_64

$ sudo yumdownloader rdma
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: ftp.us.unixeria.com
 * updates: ftp.us.unixeria.com
rdma-1.0-9.fc15.noarch.rpm                               |  16 kB     00:00
Comment 4 joshua 2012-04-26 14:47:43 EDT
... so I tried the F17beta version, rdma-1.0-11.fc17.noarch.rpm

It still doesn't work, but reduces the error from:


[root@localhost ~]# ifup ib0
Error: an inet prefix is expected rather than "4.0.0.2/".
Error adding address 4.0.0.2 for ib0.
bind: Cannot assign requested address
Ifconfig uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes.
Because Infiniband address has 20 bytes, only the first 8 bytes are displayed correctly.
Ifconfig is obsolete! For replacement check ip.
[root@localhost ~]# ifdown ib0

[root@localhost ~]# rpm -Uvh rdma-1.0-11.fc17.noarch.rpm 
warning: rdma-1.0-11.fc17.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 1aca3465: NOKEY
Preparing...                ########################################### [100%]
   1:rdma                   ########################################### [100%]


... to...


[root@localhost ~]# ifdown ib0
[root@localhost ~]# ifup ib0
Ifconfig uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes.
Because Infiniband address has 20 bytes, only the first 8 bytes are displayed correctly.
Ifconfig is obsolete! For replacement check ip.
Comment 5 joshua 2012-04-27 18:45:45 EDT
I take that back.  It does work.  When using the F17Beta rdma-1.0-11.fc17.noarch.rpm package, we still get the ifconfig error, but the IP addresses are in fact assigned, the ifup script otherwise works, and my ib0 interfaces are ping-able.

Any chance we could get that last error fixed, and a new set of rdma packages pushed to Fedora 15/16/17 ?
Comment 6 joshua 2012-05-29 20:08:56 EDT
Moving to a F17 bug... still partially broken in F17.
Comment 7 joshua 2012-07-06 18:40:45 EDT
Could we get a fix for this please?
Comment 8 Doug Ledford 2012-12-05 13:37:53 EST
The ifconfig issue isn't an error, just a warning.  However, that said, the latest packages don't use ifconfig any more (or at least the rdma owned scripts don't use ifconfig, the ifup-aliases file used to but I believe that has been corrected).
Comment 9 Fedora Update System 2012-12-05 14:00:31 EST
opensm-3.3.15-2.fc18, libibmad-1.3.9-1.fc18, libibumad-1.3.8-1.fc18, rdma-2.0-6.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/rdma-2.0-6.fc18,opensm-3.3.15-2.fc18,libibmad-1.3.9-1.fc18,libibumad-1.3.8-1.fc18
Comment 10 joshua 2012-12-05 15:23:44 EST
Awesome!  Thank you!  Any chance of getting this ported to F17 as well?
Comment 11 Doug Ledford 2012-12-05 15:30:49 EST
There isn't anything to port to f17.  The fix to the ifup-ib script is already there, and the ifconfig warning is from ifup-aliases which is part of a different package.
Comment 12 Fedora Update System 2012-12-05 18:09:31 EST
Package libibmad-1.3.9-1.fc18, libibumad-1.3.8-1.fc18, rdma-2.0-6.fc18, opensm-3.3.15-3.fc18, srptools-0.0.4-16.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libibmad-1.3.9-1.fc18 libibumad-1.3.8-1.fc18 rdma-2.0-6.fc18 opensm-3.3.15-3.fc18 srptools-0.0.4-16.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19794/srptools-0.0.4-16.fc18,rdma-2.0-6.fc18,opensm-3.3.15-3.fc18,libibmad-1.3.9-1.fc18,libibumad-1.3.8-1.fc18
then log in and leave karma (feedback).
Comment 13 Adam Williamson 2012-12-19 16:41:14 EST
The bugs related to the update https://admin.fedoraproject.org/updates/srptools-0.0.4-16.fc18,rdma-2.0-6.fc18,opensm-3.3.15-3.fc18,libibmad-1.3.9-1.fc18,libibumad-1.3.8-1.fc18 were discussed as a group at the 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt .

We considered them en masse with the general justification that dledford wishes to migrate the services in these packages to systemd prior to the release of Fedora 18, and also to fix a small security bug.

The update policy precludes migrating from sysv to systemd post-release, so if we do not allow this update through the freeze, dledford will be stuck maintaining sysv scripts for the whole of the F18 cycle (and he will have to undo all his migration work in the specs). We considered that these updates relate to a fairly unusual technology - infiniband - and that the typical Infiniband user is likely to be capable of working with Doug to resolve any teething issues that appear: accepting this update is very unlikely to cause any problems in 'typical' use. We also considered that Doug generally knows what he's doing.

Thus we accepted the issue as a whole as NTH, and will mark all the proposed bugs as AcceptedNTH, and pull the update through the freeze.
Comment 14 Fedora Update System 2012-12-20 00:30:35 EST
libibmad-1.3.9-1.fc18, libibumad-1.3.8-1.fc18, rdma-2.0-6.fc18, opensm-3.3.15-3.fc18, srptools-0.0.4-16.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.