Description of problem: This bug only happens, if: 1. you start an offline installation medium, like DVD (not netinst) AND 2. you served the kickstart in an offline way, therefore you placed it on disk partition (i.e. no network or initrd delivery) If this happens, you see a network configuration screen when anaconda starts, even though you provided correct network configuration inside the kickstart file. In my case: > network --device link --activate which should, according to documentation, start the first device with link up. In my VM I have just a single network device. I've found the bug while checking https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Hd_Device_Path_Ks_Cfg . Version-Release number of selected component (if applicable): anaconda 21.48.10-1 F21 Beta TC4 Server DVD How reproducible: always Steps to Reproduce: 1. format the VM disk before hand, create a single partition, copy the kickstart into root 2. start the DVD with inst.ks=hd:vda1:/ks.cfg 3. after anaconda starts, see the network configuration dialog Actual results: the dialog is shown Expected results: the dialog is not shown, because this is supposed to be an unattended installation
Created attachment 949908 [details] network configuration dialog on start
Created attachment 949909 [details] kickstart used
Created attachment 949910 [details] anaconda.log
Created attachment 949911 [details] ifcfg.log
Created attachment 949912 [details] journal.log
Created attachment 949913 [details] packaging.log
Created attachment 949914 [details] program.log
Created attachment 949915 [details] storage.log
Created attachment 949918 [details] syslog
Created attachment 949920 [details] X.log
Created attachment 949922 [details] anaconda-ks.cfg
This seems to violate https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Unattended_installation : Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention.
I have found out that adding > network --hostname=foobar into the kickstart makes anaconda run unattended and not present the network configuration dialog. However, this is a regression from F20. I have tested the same kickstart with F20 DVD, and I don't need to set hostname manually in F20's anaconda. Also, the anaconda documentation at http://fedoraproject.org/wiki/Anaconda/Kickstart#network does not specify at all which option are mandatory for unattended installation and which ones are not. (Anaconda devs, could you please improve that while fixing this problem?). And finally, specifying hostname is *not* necessary when using F21 Server netinst, only with DVD. So overall, I still think this is a bug, and not an incomplete kickstart file.
Just for the record, can you check if it works with 'cdrom' instead of 'url' (i.e. an actual offline install?) for my money if it only affects a case where you go to the trouble of using an offline install medium and offline kickstart delivery mechanism, but then for some reason decide to use network repos, that seems pretty marginal.
(In reply to Adam Williamson (Red Hat) from comment #14) > Just for the record, can you check if it works with 'cdrom' instead of 'url' > (i.e. an actual offline install?) Looking at the code I think 'cdrom' should work: NetworkStandaloneSpoke: @property def completed(self): return (not can_touch_runtime_system("require network connection") or nm.nm_activated_devices() or self.data.method.method not in ("url", "nfs"))
Does the spoke show that network is connected when it starts or eventually when you wait? If yes, the bug seems to be with the NM state change not triggering continuing from the spoke. If not, there's probably a bigger issue with network not being activated at all by the 'network' kickstart command described above.
Uh oh, I can no longer reproduce this issue with Beta RC1, nor Beta TC4! I also tried bare metal, no problem there. I can only assume that the problem was somehow caused by the fact that my host system was on wifi instead of on wired at the time when I tried it. So I assume it's probably related to libvirt on the host system than anaconda itself. I'll close this for the moment, and if I see it again and is able to reproduce it, I'll open a new report.