Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1204612 - eth0 is going missing in the cloud images
Summary: eth0 is going missing in the cloud images
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F22BetaBlocker
TreeView+ depends on / blocked
Reported: 2015-03-23 07:23 UTC by
Modified: 2015-03-30 17:22 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-03-30 17:22:13 UTC
Type: Bug

Attachments (Terms of Use)

Description 2015-03-23 07:23:20 UTC
Description of problem: After booting up the latest cloud images, the eth0 is going missing randomly. Sometimes after a reboot, sometimes with a fresh start.

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


How reproducible:

Just keep using a latest Fedora cloud image. For example:  or 

If you have vnc enabled, then you can login to the instance and find eth0 is missing in the ifconfig output.

Comment 1 Fedora Blocker Bugs Application 2015-03-23 07:25:11 UTC
Proposed as a Blocker for 22-beta by Fedora user kushal using the blocker tracking app because:

 Missing eth0 means the cloud image is not usable. As it going missing randomly, this should be counted as a blocker bug.

Comment 2 Lukáš Nykrýn 2015-03-23 09:11:31 UTC
If there is no eth0 device at all then this is not an initscripts bug.

If the eth0 is present but it is not configured, then this is duplicate of

Comment 3 2015-03-23 13:01:39 UTC
In few cases if we login to the system through vnc, and then manually do ifup eth0 then things settle down. May be it is a duplicate. 

I can also see in the journalctl

Mar 23 05:59:44 localhost.localdomain network[290]: Bringing up interface eth0:  ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Device eth0 does not seem to be present, delaying initialization.
Mar 23 05:59:44 localhost.localdomain cloud-init[289]: [CLOUDINIT][DEBUG]: Restoring selinux mode for /var/lib/cloud/handlers (recursive=False)
Mar 23 05:59:44 localhost.localdomain /etc/sysconfig/network-scripts/ifup-eth[435]: Device eth0 does not seem to be present, delaying initialization.

Comment 4 Lukáš Nykrýn 2015-03-23 13:22:29 UTC
Yep so this is the same issue and it can't be fixed in initscripts. Simply stop using network-scripts in those images or ship ifcfg file with DEVTIMEOUT.

Comment 5 Adam Williamson 2015-03-23 16:53:12 UTC
Discussed at 2015-03-23 blocker review meeting: . Accepted as a Beta blocker per Alpha criterion "The installed system must be able to download and install updates with the default console package manager." (as a general proxy for 'network issues', really a cloud image with no network is basically no use to anyone).

Comment 6 Lukáš Nykrýn 2015-03-24 09:11:01 UTC
Again there is nothing reasonable that could be done in initscripts. Simply boot of the system is faster then discovering of network interface. Either use NM as in workstation and desktop or include customized sysconfig/network with higher DEVTIMEOUT.

Comment 7 Václav Pavlín 2015-03-24 12:14:32 UTC
As I am not informed enough to guess why we don't want to/can't use NM in Cloud images, I'd go with the latter suggestion Lukáš has - we already modify sysconfig/network [1] and generate ifcfg during the image creation [2] so we can easily change the DEVTIMEOUT. Kushal, it's your call (as a Cloud WG representative here)


Comment 8 Lukáš Nykrýn 2015-03-24 12:19:58 UTC
Or maybe just modify the default ifcfg-eth0 file.

Comment 9 2015-03-24 12:25:03 UTC
I will make the changes tonight.

Comment 10 2015-03-30 17:22:13 UTC
The latest nightly images have the fix in place.

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