Bug 804716

Correction, he said "blocker" not "Beta blocker". Reassigning to initscripts at his suggestion.

What's in your ifcfg files?

I think this Alpha criterion could be applied:

"The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"

I know it is possible to enable network devices using dhclient, but that's way too low-level solution and you have to do it after each reboot (need ssh? forget it:). Having the network service disabled by default is a very bad choice itself, but if the network doesn't work even after you enable it, that's not what I see as "satisfying the criterion".

Proposing as F17 Beta blocker.

(In reply to comment #2)
> What's in your ifcfg files?

I only have an ifcfg-lo file, and its contents are the same as those for my stable F16 install.

To anaconda, then. The network script won't do anything if there's no configuration written.

How did you configure the network? Using boot args, a kickstart, or the GUI?

If boot args/kickstart can you show the network line(s) or boot arg(s) used?

No configuration during install. I simply did a minimal GUI install changing no defaults (except "Graphical"->"Minimal), then booted into the installed system and attempted "systemctl start network.service" which normally works but does not with Beta TC2. The install was in a VirtualBox 4.1.10 VM and the network device name is "p2p1". Have not attempted yet with KVM.

Confirmed with a KVM minimal GUI install using the 17 Beta TC2 i386 DVD. After booting into the installed system, "systemctl start network.service" doesn't work, I have to use "dhclient eth0". The only ifcfg-* file is ifcfg-lo.

Could this have something to do with the fact that the packages on the DVD are not used during install (bug 804446), forcing the network to be used? That is also a new TC2 bug.

I'm confused. If I understand you correctly, you're saying that you did the following:

1) install from the installation DVD, and
2) do not configure the network during the install.

And that, before F17-TC2, ifcfg-eth0 would exist after the install. Is that right?

What would be the contents of ifcfg-eth0 in that case?

I didn't explicitly check whether ifcfg-* existed, I just started the network service (either with "service network start" or "systemctl start network.service") after booting into the new install, and before 17 Beta TC2 it always worked, using the exact same procedure.

I'm +0 on the beta blocker status of this right now. It's not clear to me that a minimal install is covered by Beta. I am +1 NTH if the fix isn't too invasive.

Created attachment 571278 [details]
anaconda.ifcfg.log from 17 Beta TC1 i386 DVD install

Did a minimal GUI install from the 17 Beta TC1 i386 DVD, in the exact same way as 17 Beta TC2. The file ifcfg-eth0 exists, and "systemctl start network.service" works.

Created attachment 571279 [details]
ifcfg-eth0 from 17 Beta TC1 i386 DVD install

ifcfg-eth0 from the same install (which BTW was using KVM).

Created attachment 571282 [details]
anaconda.ifcfg.log from 17 Beta TC2 i386 DVD install

Corresponding file from TC2 install. ifcfg-eth0 doesn't exist.

I can confirm this problem. F17 Beta TC2 i386 installed in minimal installation does not have the ifcfg-eth0 file, therefore network does not work except for manually running dhclient.

+1 beta blocker

(In reply to comment #11)
> It's not clear to me that
> a minimal install is covered by Beta.

We don't distinguish different types of installations in our criteria except where explicitly stated. Therefore I conclude network (and therefore downloading of system updates) should work no matter if you have chosen default, minimal or custom installation (except if you remove some essential packages manually, in that case it's probably understandable).

Using the system updates criterion is a bit stretch here, I have to admit. I would rather see a specific criterion saying the network must just work.

+1 beta blocker

kamil: considering the 'updates' criterion a proxy for 'network must work' has a long and honored tradition, we've always treated it that way =) but an explicit criterion could certainly be proposed if you felt like it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

<wwoods> adamw: yeah, so I'm adding a setDefaultConfig() function, to write out a default config like loader used to



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I'm actually -1 blocker on this. Network has never been up out of the box after a minimal install, and I'm not sure the difference between 'service network start' and 'dhclient eth0' is huge enough that we should consider it a blocker when you need to do the latter instead of the former. Especially a *Beta* blocker.

I'm +1 NTH, though, as it's probably a good idea for now to replicate the 'loader' behaviour of writing an ifcfg file to the installed system. We don't know for sure that not doing so might not have other impacts.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

+1 NTH, -1 blocker.

After thinking about this a bit more, I'm OK with changing my vote to -1 blocker, +1 NTH.

+1 NTH, -1 blocker,

This is a clear blocker thus +1 to blocking from me. 

And I think that we should just remove all the "gray area" surrounding network functionality both in the installer and after the install in beta ( we might be a bit more willing dancing on the gray are for alpha ) it should just work for wired Ethernet connection both for ipv4 and ipv6 and in all the installation method's the installer has to offer period.

What do you mean by 'just work', Johann? Are you talking about 'going back to enabling the network service' or 'having the network up OOTB'?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I thought it was pretty obvious what I meant but to clarify after an install regardless if it's minimal,default or everything networking should be enabled and default to dhcp thus just work regardless if you are on an ipv4 or ipv6 network...

(In reply to comment #25)
> I thought it was pretty obvious what I meant but to clarify after an install
> regardless if it's minimal,default or everything networking should be enabled
> and default to dhcp thus just work regardless if you are on an ipv4 or ipv6
> network...

I have the same opinion. We shouldn't punish users who chose minimal install because it's somehow "less supported". If it's included in the installer, it should be supported. Network should be up and running after installation. (If we feel that minimal installation should be somehow less supported, I'd rather see it as an unofficial spin or something).

OTOH due to all the technical difficulties I feel reluctant to block F17 on this (it was broken for such a long time already). I'd like to make sure that 'service network start' works in F17 Beta of Final (I don't insist on Beta, but I definitely see it as +1 blocker for Final). Having networking work OOTB after minimal install would be a good goal for F18. If we announce this this much in advance, there's plenty of time for all the required development to happen. In the mean time we can draft criteria that say that networking must work OOTB regardless of IP version or installation type. If we agree on that.

Agreed

Changing my previous vote from +1 Beta to +1 Final

yeah, I think Kamil is right there. If we want to try and promote such a policy change then we can, but it is a policy change, and right now isn't the time to introduce it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

OK, so we have multiple issues under discussion here now - let me try to summarize and link things out so we don't get confused.

This bug, this specific bug, is for the fact that anaconda no longer generates and installs ifcfg files. It was reported for the specific consequence of this, that the 'network' service does not work after a minimal install (any non-NM install).

I believe Will was adding an 'ifcfg generator' to the noloader branch so anaconda will start spitting out an ifcfg file again, but long term, he thinks there's no particular reason for anaconda to handle this, and it may stop again in future. I'm not sure if the 'ifcfg generator' will be part of 17.14 - Will / Brian, can you comment?

There's two other bugs relevant to the wider discussion we're having here:

1) The 'network' service is not enabled by default after a non-NM network installation. That's https://bugzilla.redhat.com/show_bug.cgi?id=693602 , where there's quite extensive historical discussion.

2) For a long time, we never brought up the network by default after installation on a non-network installation - whether minimal or full, NM or non-NM didn't really matter, because it was a policy choice. The bug report for this one wa https://bugzilla.redhat.com/show_bug.cgi?id=498207 . We actually changed that behaviour in F16, for NM installs at least, so when you do a non-network install (DVD install) with NM included, the network is enabled on reboot.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Note that if NM is in the minimal install, this is solved without anaconda needing to write a configuration, IIRC.

Done: http://git.fedorahosted.org/git/?p=comps.git;a=commitdiff;h=a7f19825d325364d5d59107617ddc95bdebcd88b

I'm not sure we've actually tested that NM brings up an interface with no ifcfg file in a minimal install config. But hey, let's see what RC1 ends up working like, and we can re-open if necessary.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

It does it when booting to runlevel 3 on F16 (admittedly, not a minimal install).

anaconda-17.14-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.14-1.fc17

anaconda-17.14-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

After a minimal GUI install from the 17 Beta RC1 i386 DVD, I still need to use "dhclient p2p1" (p2p1 is the network device in a VirtualBox guest). The network service doesn't work, even though ifconfig shows p2p1 active.

Andre: 'ifup p2p1' or 'systemctl start NetworkManager.service' should work. The fact that the interface isn't up after boot in RC1 is https://bugzilla.redhat.com/show_bug.cgi?id=806466.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #37)
> Andre: 'ifup p2p1' or 'systemctl start NetworkManager.service' should work. The
> fact that the interface isn't up after boot in RC1 is
> https://bugzilla.redhat.com/show_bug.cgi?id=806466.

"systemctl start NetworkManager.service" does not work. "ifup p2p1" also doesn't work and gives the error

Error: Can't obtain connections: settings service is not running.

BTW, "systemctl status NetworkManager.service" immediately after boot shows that it is already running.

If I change the ONBOOT line in ifcfg-p2p1 from ONBOOT="no" to ONBOOT="yes", the network comes up automatically at boot time. "ifdown p2p1" will bring down the network, but "ifup p2p1" does not bring it back up (get the same error as before).

Closing again since it appears that the ONBOOT="no" is bug 806466. But is the ifup error expected?

No, that doesn't match my experience. For me, ifup blah worked...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Huh, I can get that error on my desktop by trying to do anything with nmcli. Are you sure you tested from a DVD install without updates-testing?

Weird...I can reproduce this now, but I'm sure in my first test, ifup eth0 worked. Very odd.

We should open a new bug, anyway, as it's clearly not any of the previous bugs.

Just reproduced this immediately after a Beta RC1 x86_64 DVD minimal GUI install in a KVM guest. "ifup eth0" gives the error.

Filed bug 806664. This happens for F17 generally, not just a minimal install.