Description of problem: Anaconda isn't creating the file "/etc/sysconfig/network", which it did on Fedora 18 and previous. Version-Release number of selected component (if applicable): Fedora 19 Beta release How reproducible: Every time on both physical hardware and KVM installations Steps to Reproduce: 1. Kickstart installation: ------ network --bootproto dhcp %post /bin/systemctl enable network.service /bin/systemctl disable NetworkManager.service ------ Actual results: There is no "/etc/sysconfig/network" file and network.service does not function. You have no network connectivity. Expected results: In Fedora 18 and previous, the file "/etc/sysconfig/network" was created and contained: ------ # Generated by anaconda NETWORKING=yes ------ In Fedora 18, network.service worked as expected. Additional info: As a workaround, one can manually create the missing file.
Yep, I ran into this as well. The biggest problem is that things just mysteriously don't work with no obvious error indication until you go low level and start running individual ifup commands, then you finally see a message on stdout about the missing file (which is real easy to fix, it is just real hard to find).
Changing the title slightly after talking with folks at SELF. The install method doesn't really matter, the bottom line is that anaconda doesn't create this file anymore. Perhaps it should be created by something else? I don't care how it is fixed, but I do think that enabling network.service should still work the same as in the past.
It's more buggy. I reported back in May: https://lists.fedoraproject.org/pipermail/test/2013-May/115582.html Still the name of the file ifcfg-... does not match the interface name (eth0, p5p1, ...) in some install cases, so expect more networking related problems (not only "network" file missing). Someone must fix these before F19 is out.
We put writing-out /etc/sysconfig/network in anaconda back. It should be in F19 TC2 http://serverbeach1.fedoraproject.org/pub/alt/stage/19-TC2/ . As for biosdevname (p4p1) vs. new predictable systemd device naming (enp5s0), we are working on that. The latter is being added to dracut/initramfs which should solve one subset of the issues but there seems to be more to be done to get the naming in accord completely.
Great! I've retested with TC2 and network.service worked as I expected.
*** This bug has been marked as a duplicate of bug 965841 ***