Bug 1276706 - Issue getting an IP address on the cfme-5.5 appliance
Summary: Issue getting an IP address on the cfme-5.5 appliance
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Beta 2
: 5.5.0
Assignee: Nick Carboni
QA Contact: Milan Falešník
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-30 14:57 UTC by Chris Pelland
Modified: 2015-12-08 13:42 UTC (History)
5 users (show)

Fixed In Version: 5.5.0.9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-08 13:42:42 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2551 0 normal SHIPPED_LIVE Moderate: CFME 5.5.0 bug fixes and enhancement update 2015-12-08 17:58:09 UTC

Description Chris Pelland 2015-10-30 14:57:56 UTC
There is a problem getting an IP address on the cfme-5.5 appliance (Only tested
vSphere) in build 5.5.0.8.

 
Workaround:
To obtain IP address after booting up, please add the following line to /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
 

Devel status 10/29: Devel made a fix in the kickstart that will ensure that we have the configuration we need on first boot and we just finished testing out both upstream and downstream appliances built with that fix in place.

PR has been created and waiting to be merged: 
https://github.com/ManageIQ/manageiq-appliance-build/pull/72

Devel is still diagnosing the underlying issue that is causing us to end up with an invalid configuration after the build.

Comment 1 Nick Carboni 2015-10-30 15:38:36 UTC
The root cause is the difference in tools writing the configuration files in question.

/etc/sysconfig/network-scripts/ifcfg-eth0 is being written by the anaconda dracut module parse-kickstart file upstream.

This means we write the device line we need here (https://git.fedorahosted.org/cgit/anaconda.git/tree/dracut/parse-kickstart?h=anaconda-19.31.122-1#n363) unconditionally.

The same file downstream is being written by dracut's ifcfg module.
We are running into issues with the "eth0" interface being recognized as a "kernel ethernet name" here (http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/45ifcfg/write-ifcfg.sh?h=RHEL-7#n109) and here (http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/40network/net-lib.sh?h=RHEL-7#n705)

If dracut sees a "kernel ethernet name" it writes the HWADDR rather than DEVICE.  One should be all we need for proper network configuration, but imagefactory removes the HWADDR here (https://github.com/redhat-imaging/imagefactory/blob/master/imgfac/FactoryUtils.py#L109) because we wouldn't want to specify a device MAC on a VM image (as the mac should be unique across multiple deployments)

So the PR referenced above may be our best bet until we can either move to the new network interface naming scheme (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) which should remove the issue with dracue or alter our build process to do what we need it to do regarding network interface config.

Comment 2 Nick Carboni 2015-11-03 15:22:05 UTC
Latest build still had issue.  Moving back to ON_DEV

Comment 4 CFME Bot 2015-11-03 16:27:35 UTC
New commit detected on ManageIQ/manageiq-appliance-build/master:
https://github.com/ManageIQ/manageiq-appliance-build/commit/299b249d7ddb6ca0a6fd9be9c92c4f3332115e7d

commit 299b249d7ddb6ca0a6fd9be9c92c4f3332115e7d
Author:     Nick Carboni <ncarboni>
AuthorDate: Tue Nov 3 10:23:12 2015 -0500
Commit:     Nick Carboni <ncarboni>
CommitDate: Tue Nov 3 10:23:12 2015 -0500

    Fix the line that conditionally prints DEVICE=
    
    The original PR used && in place of ||
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1276706

 kickstarts/base.ks.erb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 5 Milan Falešník 2015-11-04 17:08:16 UTC
This issue is no longer present on 5.5.0.9, the appliance gets an IP address "out of the box"

Comment 7 errata-xmlrpc 2015-12-08 13:42:42 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.

https://access.redhat.com/errata/RHSA-2015:2551


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