This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 804716 - after minimal 17 Beta TC2 install, network service doesn't work
after minimal 17 Beta TC2 install, network service doesn't work
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F17Beta/F17BetaBlocker
  Show dependency treegraph
 
Reported: 2012-03-19 12:22 EDT by Andre Robatino
Modified: 2012-03-25 17:21 EDT (History)
16 users (show)

See Also:
Fixed In Version: anaconda-17.14-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-24 17:59:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.ifcfg.log from 17 Beta TC1 i386 DVD install (1.70 KB, text/plain)
2012-03-20 00:31 EDT, Andre Robatino
no flags Details
ifcfg-eth0 from 17 Beta TC1 i386 DVD install (135 bytes, text/plain)
2012-03-20 00:33 EDT, Andre Robatino
no flags Details
anaconda.ifcfg.log from 17 Beta TC2 i386 DVD install (148 bytes, text/plain)
2012-03-20 00:40 EDT, Andre Robatino
no flags Details

  None (edit)
Description Andre Robatino 2012-03-19 12:22:32 EDT
Description of problem:
After a minimal 17 Beta TC2 install, "systemctl start network.service" doesn't bring up the network. I have to refer to the specific device, for example "dhclient p2p1". Kamil Paral suggested that this could be proposed as a Beta blocker, I'm not sure what the criterion would be though. Please reassign to the correct component.

Version-Release number of selected component (if applicable):
17 Beta TC2 (both i386 and x86_64)

How reproducible:
always
Comment 1 Andre Robatino 2012-03-19 12:28:42 EDT
Correction, he said "blocker" not "Beta blocker". Reassigning to initscripts at his suggestion.
Comment 2 Bill Nottingham 2012-03-19 12:33:58 EDT
What's in your ifcfg files?
Comment 3 Kamil Páral 2012-03-19 12:36:54 EDT
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.
Comment 4 Andre Robatino 2012-03-19 13:29:31 EDT
(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.
Comment 5 Bill Nottingham 2012-03-19 13:32:28 EDT
To anaconda, then. The network script won't do anything if there's no configuration written.
Comment 6 Will Woods 2012-03-19 18:09:27 EDT
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?
Comment 7 Andre Robatino 2012-03-19 18:18:57 EDT
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.
Comment 8 Andre Robatino 2012-03-19 18:58:21 EDT
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.
Comment 9 Will Woods 2012-03-19 21:02:10 EDT
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?
Comment 10 Andre Robatino 2012-03-19 21:17:46 EDT
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.
Comment 11 Bruno Wolff III 2012-03-19 22:07:07 EDT
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.
Comment 12 Andre Robatino 2012-03-20 00:31:25 EDT
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.
Comment 13 Andre Robatino 2012-03-20 00:33:34 EDT
Created attachment 571279 [details]
ifcfg-eth0 from 17 Beta TC1 i386 DVD install

ifcfg-eth0 from the same install (which BTW was using KVM).
Comment 14 Andre Robatino 2012-03-20 00:40:24 EDT
Created attachment 571282 [details]
anaconda.ifcfg.log from 17 Beta TC2 i386 DVD install

Corresponding file from TC2 install. ifcfg-eth0 doesn't exist.
Comment 15 Kamil Páral 2012-03-20 08:55:53 EDT
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.
Comment 16 Jared Smith 2012-03-20 14:04:49 EDT
+1 beta blocker
Comment 17 Adam Williamson 2012-03-20 19:00:59 EDT
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
Comment 18 Adam Williamson 2012-03-21 17:46:03 EDT
<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
Comment 19 Adam Williamson 2012-03-21 18:26:19 EDT
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
Comment 20 Kevin Fenzi 2012-03-21 18:56:37 EDT
+1 NTH, -1 blocker.
Comment 21 Jared Smith 2012-03-21 19:05:07 EDT
After thinking about this a bit more, I'm OK with changing my vote to -1 blocker, +1 NTH.
Comment 22 Robyn Bergeron 2012-03-21 20:05:08 EDT
+1 NTH, -1 blocker,
Comment 23 Jóhann B. Guðmundsson 2012-03-21 20:23:08 EDT
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.
Comment 24 Adam Williamson 2012-03-21 20:37:15 EDT
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
Comment 25 Jóhann B. Guðmundsson 2012-03-22 06:00:28 EDT
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...
Comment 26 Kamil Páral 2012-03-22 07:07:50 EDT
(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.
Comment 27 Jóhann B. Guðmundsson 2012-03-22 08:23:21 EDT
Agreed

Changing my previous vote from +1 Beta to +1 Final
Comment 28 Adam Williamson 2012-03-22 12:20:20 EDT
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
Comment 29 Adam Williamson 2012-03-22 12:44:43 EDT
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
Comment 30 Bill Nottingham 2012-03-22 16:12:51 EDT
Note that if NM is in the minimal install, this is solved without anaconda needing to write a configuration, IIRC.
Comment 32 Adam Williamson 2012-03-22 17:18:03 EDT
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
Comment 33 Bill Nottingham 2012-03-22 17:27:40 EDT
It does it when booting to runlevel 3 on F16 (admittedly, not a minimal install).
Comment 34 Fedora Update System 2012-03-23 01:17:56 EDT
anaconda-17.14-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.14-1.fc17
Comment 35 Fedora Update System 2012-03-23 13:45:22 EDT
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.
Comment 36 Andre Robatino 2012-03-23 18:52:26 EDT
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.
Comment 37 Adam Williamson 2012-03-24 16:47:03 EDT
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
Comment 38 Andre Robatino 2012-03-24 17:09:42 EDT
(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.
Comment 39 Andre Robatino 2012-03-24 17:23:34 EDT
BTW, "systemctl status NetworkManager.service" immediately after boot shows that it is already running.
Comment 40 Andre Robatino 2012-03-24 17:55:06 EDT
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).
Comment 41 Andre Robatino 2012-03-24 17:59:51 EDT
Closing again since it appears that the ONBOOT="no" is bug 806466. But is the ifup error expected?
Comment 42 Adam Williamson 2012-03-25 02:30:59 EDT
No, that doesn't match my experience. For me, ifup blah worked...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 43 Adam Williamson 2012-03-25 02:33:03 EDT
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?
Comment 44 Adam Williamson 2012-03-25 02:37:11 EDT
Weird...I can reproduce this now, but I'm sure in my first test, ifup eth0 worked. Very odd.
Comment 45 Adam Williamson 2012-03-25 02:38:03 EDT
We should open a new bug, anyway, as it's clearly not any of the previous bugs.
Comment 46 Andre Robatino 2012-03-25 02:48:37 EDT
Just reproduced this immediately after a Beta RC1 x86_64 DVD minimal GUI install in a KVM guest. "ifup eth0" gives the error.
Comment 47 Andre Robatino 2012-03-25 17:20:20 EDT
Filed bug 806664. This happens for F17 generally, not just a minimal install.

Note You need to log in before you can comment on or make changes to this bug.