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): initscripts-9.56.1-7 How reproducible: Just keep using a latest Fedora cloud image. For example: http://koji.fedoraproject.org/koji/taskinfo?taskID=9273089 or If you have vnc enabled, then you can login to the instance and find eth0 is missing in the ifconfig output.
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.
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 https://bugzilla.redhat.com/show_bug.cgi?id=1194623
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] util.py[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.
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.
Discussed at 2015-03-23 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-23/f22-blocker-review.2015-03-23-16.02.log.txt . 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). https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
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.
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) [1] https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n144 [2] https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n155
Or maybe just modify the default ifcfg-eth0 file.
I will make the changes tonight.
The latest nightly images have the fix in place. http://koji.fedoraproject.org/koji/taskinfo?taskID=9359447