Red Hat Bugzilla – Bug 852808
Omits "IPV6INIT=yes" from the generated ifcfg-* file
Last modified: 2013-01-10 01:53:58 EST
In short: when using ifcfg files, ipv6 will not be configured unless "IPV6INIT=yes" is present. The ifcfg module needs to add that to the file(s) it generates.
+++ This bug was initially created as a clone of Bug #830434 +++
[edited for relevance. -ww]
Description of problem:
During the installation of Fedora 17, Anaconda generates an ifcfg-* file that contains the default settings for the network interface, and copies it into the installed system. This file does not contain the essential line "IPV6INIT=yes", which in turn causes NetworkManager *not* to automatically enable IPv6.
Steps to Reproduce:
1. Connect a computer to an IPv6-only wired ethernet network.
2. Install Fedora 17, either using a LiveCD/LiveUSB, or the DVD.
3. Reboot into the installed system.
The network connection fails to activate, becuase the absense of IPV6INIT=yes causes NetworkManager to only attempt to activate IPv4, which is not available.
The network connection should successfully activate.
This bug would actually be a F17 blocker, as it prevents connection to to IPv6-only networks "out of the box". See
<http://lists.fedoraproject.org/pipermail/test/2012-March/106054.html>. Unfortunately, it slipped through my testing. I'm marking it as a F18 blocker for now.
Curiously enough, this does not prevent *installation* on the IPv6-only network (including retrieving the software from mirror servers, in the case of DVD installation). This happens because during installation, NetworkManager brings up the connection automatically before the Anaconda-generated ifcfg-* files appear. When NetworkManager activates a device for which there is no ifcfg-* file, it also automatically enables IPv6. It is only after rebooting into the installed system that the network connectivity does not work any more.
--- Additional comment from firstname.lastname@example.org on 2012-08-28 17:21:24 EDT ---
Anyway, my reading of the initscripts / NetworkManager source and docs seemed to indicate that IPV6INIT=yes was the default, so it was intentionally left out. I guess that's not the case. Luckily that's pretty easy to fix.
--- Additional comment from email@example.com on 2012-08-29 02:46:43 EDT ---
When there's a ifcfg file present, NetworkManager's ifcfg-rh reader plugin steps in with defaults of its own. Its goal is to be as compatible with initscripts' defaults as much as possible, so that enabling/disabling NM on an interface does not change the actual behaviour. See bug #830436, comment #2.
As per bug 830434 comment 5
Will created this clone for dracut's ifcfg module, so reassigning to dracut.
upstream commit 32ec0a762d1dce36f20857ffd222863a3d550ed7
I guess this should be Fedora 18...
dracut-024-1.fc18 has been submitted as an update for Fedora 18.
dracut-024-5.git20121019.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-5.git20121019.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
The relevant update has been pushed stable. Can we close this now? Has the change been cloned into anaconda or wherever it needs to go?
If someone can confirm that the fix is included in the latest F18 prereleases (LiveCD and DVD), I'll be happy to verify it.
The Beta RC1 DVD contains dracut-024-5.git20121019.fc18.x86_64.rpm , so yes, the fix is in Beta RC1: https://dl.fedoraproject.org/pub/alt/stage/18-Beta-RC1/
Created attachment 651298 [details]
Screenshot of default F18 Beta network immediately after installation
I tried installing both from the Live CD and the DVD in a VM with IPv6-only network connectivity (DHCPv6 only, no SLAAC). In both cases, when booting from the install media, the system connected successfully to the network. When NetworkManager started, there was not ifcfg files (except ifcfg-lo), which caused it to use its own built-in defaults, which do IPv6 just fine. So far, so good.
However, during the installation, an ifcfg-eth0 file appeared that did *not* contain IPV6INIT=yes. In the Live CD case, it did not appear until I pressed the big "install to hard drive" button.
This file was then copied to the installation target, so after finishing the installation and rebooting into the installed system, the VM was no longer able to connect to the network. The attached screenshot shows this.
Setting back to ASSIGNED, then. Will!
Discussed at 2012-11-28 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-11-28/f18final-blocker-review-1.2012-11-28-16.59.log.txt . Accepted as a blocker per criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops". In general we are accepting showstoppers for IPV6-OOTB as blockers since F17.
(In reply to comment #10)
> Created attachment 651298 [details]
> Screenshot of default F18 Beta network immediately after installation
> I tried installing both from the Live CD and the DVD in a VM with IPv6-only
> network connectivity (DHCPv6 only, no SLAAC). In both cases, when booting
> from the install media, the system connected successfully to the network.
> When NetworkManager started, there was not ifcfg files (except ifcfg-lo),
> which caused it to use its own built-in defaults, which do IPv6 just fine.
> So far, so good.
> However, during the installation, an ifcfg-eth0 file appeared that did
> *not* contain IPV6INIT=yes. In the Live CD case, it did not appear until I
> pressed the big "install to hard drive" button.
> This file was then copied to the installation target, so after finishing the
> installation and rebooting into the installed system, the VM was no longer
> able to connect to the network. The attached screenshot shows this.
Well, if dracut was not told to use IPV6 via a kernel command line interface, because you have an install medium (which does not need network), then there will be no ifcfg-* file generated (because no network was used in the initramfs).
anaconda should have created the IPv6 ifcfg configuration by itsself.
You should open a bug against anaconda not doing this.
(In reply to comment #13)
> Well, if dracut was not told to use IPV6 via a kernel command line
> interface, because you have an install medium (which does not need network),
> then there will be no ifcfg-* file generated (because no network was used in
> the initramfs).
I did not specify any kernel options. I just booted the DVD/LiveCD with the default settings. An ifcfg-eth0 file was generated, but it did not contain the necessary IPV6INIT=yes.
> anaconda should have created the IPv6 ifcfg configuration by itsself.
Well, it didn't.
> You should open a bug against anaconda not doing this.
Uh, now I'm confused. That's exactly what I did.
(In reply to comment #14)
> Uh, now I'm confused. That's exactly what I did.
Well, this bug is a clone for the dracut part, which can be started with a network configuration in F18, if the anaconda stage2 is on the network. And because if anaconda then runs from stage2 it must not alter the current network connection, when it starts NetworkManager. NetworkManager has to know to use IPv6 in stage2. This is _this_ bug.
The other bugzilla would be about anaconda (or NetworkManager) putting IPV6INIT in the ifcfg-* file, if it started the network all by itsself (root/stage2 not on network, therefore no dracut network) running on a LiveCD or DVD.
Tore: does https://bugzilla.redhat.com/show_bug.cgi?id=830434 sufficiently cover the outstanding issues here, or are you still concerned about the dracut side? thanks!
Adam, before reading comment #15 I hadn't really realised that there was two distinct bugs. The only way I've come across the bug is through regular installs from DVD/LiveCD media.
I never tried network install, so I don't think I came across the dracut bug at all. I'm not sure if I could try to reproduce it, either, since I don't have any computers that supports IPv6 PXE booting. So as far as I'm concerned this bug can be left closed.