Bug 1156073

Summary: network configuration screen is displayed for kickstarted installation when the network device is down on anaconda start
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, robatino, vanmeeuwen+fedora, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-24 12:14:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1043124    
Attachments:
Description Flags
network configuration dialog on start
none
kickstart used
none
anaconda.log
none
ifcfg.log
none
journal.log
none
packaging.log
none
program.log
none
storage.log
none
syslog
none
X.log
none
anaconda-ks.cfg none

Description Kamil Páral 2014-10-23 14:12:07 UTC 
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
Comment 1 Kamil Páral 2014-10-23 14:13:33 UTC 
Created attachment 949908 [details]
network configuration dialog on start
Comment 2 Kamil Páral 2014-10-23 14:14:54 UTC 
Created attachment 949909 [details]
kickstart used
Comment 3 Kamil Páral 2014-10-23 14:15:36 UTC 
Created attachment 949910 [details]
anaconda.log
Comment 4 Kamil Páral 2014-10-23 14:15:40 UTC 
Created attachment 949911 [details]
ifcfg.log
Comment 5 Kamil Páral 2014-10-23 14:16:02 UTC 
Created attachment 949912 [details]
journal.log
Comment 6 Kamil Páral 2014-10-23 14:16:05 UTC 
Created attachment 949913 [details]
packaging.log
Comment 7 Kamil Páral 2014-10-23 14:16:08 UTC 
Created attachment 949914 [details]
program.log
Comment 8 Kamil Páral 2014-10-23 14:16:13 UTC 
Created attachment 949915 [details]
storage.log
Comment 9 Kamil Páral 2014-10-23 14:16:18 UTC 
Created attachment 949918 [details]
syslog
Comment 10 Kamil Páral 2014-10-23 14:16:20 UTC 
Created attachment 949920 [details]
X.log
Comment 11 Kamil Páral 2014-10-23 14:16:22 UTC 
Created attachment 949922 [details]
anaconda-ks.cfg
Comment 12 Kamil Páral 2014-10-23 14:18:15 UTC 
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.
Comment 13 Kamil Páral 2014-10-23 14:38:45 UTC 
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.
Comment 14 Adam Williamson 2014-10-23 16:04:39 UTC 
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.
Comment 15 Vratislav Podzimek 2014-10-24 09:07:41 UTC 
(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"))
Comment 16 Vratislav Podzimek 2014-10-24 09:12:42 UTC 
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.
Comment 17 Kamil Páral 2014-10-24 12:14:14 UTC 
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.