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. Version-Release number of selected component (if applicable): According to the changelog, this behaviour started in 17.14-1: - Create default ifcfg-* for each interface (#804504, #804716) (wwoods) How reproducible: 100% 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. Actual results: The network connection fails to activate, becuase the absense of IPV6INIT=yes causes NetworkManager to only attempt to activate IPv4, which is not available. Expected results: The network connection should successfully activate. Additional info: 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.
This may have two parts to it, dracut adding that to ifcfg files it creates, and anaconda adding it to the configs it creates (yay duplicity). Either way I'm tossing it at wwoods.
Oh, and by the way, you should perhaps include IPV6_FAILURE_FATAL=no and IPV4_FAILURE_FATAL=no also. I *think* those are the default if they're not included in the file, but better safe than sorry. Tore
I assume you're using a kickstart, since you're referencing code changes from parse-kickstart; if you're using 'ip=...' boot arguments to configure the device(s) that's handled by the '45ifcfg' module in dracut (and that would be a separate bug). 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. As for comment #2: It's not anaconda's job to set policy; if you want to change the policy for IPV*_FAILURE_FATAL that probably needs to be discussed with the maintainers of 'NetworkManager' and/or 'initscripts'.
(In reply to comment #3) > I assume you're using a kickstart, since you're referencing code changes > from parse-kickstart; if you're using 'ip=...' boot arguments to configure > the device(s) that's handled by the '45ifcfg' module in dracut (and that > would be a separate bug). No, I just did a completely regular install. > 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. Enabling IPv6 is the default in NetworkManager, if there's no ifcfg file at all. That's why this used to work fine, until Anaconda started writing them during installation. 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 for comment #2: It's not anaconda's job to set policy; if you want to > change the policy for IPV*_FAILURE_FATAL that probably needs to be discussed > with the maintainers of 'NetworkManager' and/or 'initscripts'. That policy is determined by FESCo, actually: https://fedorahosted.org/fesco/ticket/819 I'm certain that _FAILURE_FATAL defaults to "no" in NM if there's no ifcfg file at all (which means that was certainly the default behaviour up until the point where anaconda started writing ifcfg files). Alos, I believe they also default to "no" if there is a ifcfg file present as well (I can verify this if you'd like me to), but if they don't, it is actually Anaconda that ended up changing the default policy when it started to write out ifcfg files. In any case, writing out the settings that enforce the default behaviour mandated by FESCo certainly doesn't hurt, and is resilient in the case of built-in defaults changing in either initscripts, NM's ifcfg-rh, or NM core. Tore
Thanks for the explanation about why the defaults seemed to differ between NM and the ifcfg files - that's very helpful! (In reply to comment #4) > (In reply to comment #3) > > I assume you're using a kickstart [...] > > No, I just did a completely regular install. Then this also needs to be fixed in dracut's 'ifcfg' module. I've created bug 852808 for that. > That policy is determined by FESCo, actually: That's fine, but it's still not anaconda's job to *enforce* policy. There are various things that anaconda used to enforce policy on, and it became a tremendous maintenance burden for the anaconda team. Every time someone wanted to change these policies (even for packages they owned!) they had to get us to patch and rebuild anaconda. It was a waste of time for all involved and we're trying as hard as we can to avoid it. On the other hand, writing "IPV6INIT=yes" is required to activate the configuration *requested by the user in the installer*. That's definitely anaconda's job. I should patches for this (and bug 852808) shortly.
(In reply to comment #5) > Then this also needs to be fixed in dracut's 'ifcfg' module. I've created > bug 852808 for that. Thanks! > There are various things that anaconda used to enforce policy on, and it > became a tremendous maintenance burden for the anaconda team. Every time > someone wanted to change these policies (even for packages they owned!) they > had to get us to patch and rebuild anaconda. It was a waste of time for all > involved and we're trying as hard as we can to avoid it. Don't get me wrong, I'm not trying to point fingers and assign blame/tasks, I'm just a simple user and IPv6 enthusiast that just want the installation to work as smoothly on IPv6-only networks as any other. Which package the necessary changes are made in is not important to me, as long as it actually works. As you might have noticed, I did simultaneously pursue the solution of making NM change its interpetation of a ifcfg file without a IPV6INIT setting, which would also have accomplished the goal, but it was rejected (bug #830436). I suppose I could also have pursued a path of making first initscripts' ifup-ipv6 change its default setting for IPV6INIT, which in turn would probably make the NM maintainer more inclined to change the ifcfg-rh module, though. But I would think that would be a hard sell due to breaking backwards compatability... In any case, I just did a quick check with NetworkManager-0.9.7.0-1.git20120820 and the following ifcfg-eth0 file (same as the one Anaconda wrote, plus IPV6INIT=yes): UUID="6d68539e-4a58-491e-b0ee-36d435a886dc" NM_CONTROLLED="yes" HWADDR="00:1D:60:48:F5:9E" BOOTPROTO="dhcp" DEVICE="eth0" ONBOOT="yes" IPV6INIT="yes" It accomplishes the behaviour I want; it makes NM successfully connect to 1) IPv4-only networks, 2) IPv6-only networks, and 3) dual-stacked networks. So it seems that the default values of the _FAILURE_FATAL settings are no/false in NM's ifcfg-rh plugin also - good news for us, as it means there is no need for anaconda to write them out. > On the other hand, writing "IPV6INIT=yes" is required to activate the > configuration *requested by the user in the installer*. That's definitely > anaconda's job. > > I should patches for this (and bug 852808) shortly. Wonderful! If you're able to build CD/DVD ISOs with a patched anaconda on them, I would be very happy to help test and confirm that they solve the issue. Tore
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 installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible" for the case of an IPv6 install. In general we are accepting showstoppers for IPv6-OOTB as blockers since F17.
There's been a commit with this bug number attached for quite some time now: commit 8cec599a7bb517d84773d6c9c80b33ea4ec1c209 Author: Will Woods <wwoods> Date: Tue Aug 28 17:17:12 2012 -0400 parse-kickstart: set IPV6INIT=yes when using ipv6 (#830434) It turns out IPV6INIT defaults to "no", so we need to set this. It would be worth re-testing this and verifying.
Chris, I verified that the bug is present in F18 Beta, both DVD and Live CD variants. See bug #852808, comment #10.
Alright, thanks.
In F18 TC1 we are dumping settings of default auto connections run by NM (because of missing ifcfg files) into ifcfg files. Although these connections enable ipv6 if I am not mistaken, the dumped files don't contain IPV6INIT=yes line, so there seems to be some inconsistency, perhaps in ifcfg-rh plugin writer?
Ok, so with F18 TC1 Live, if I press the "install to hard drive" button, a ifcfg-eth0 file appears that contains the following: HWADDR=52:54:00:C0:1B:C2 TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=no NAME=eth0 UUID=abd3bfef-51e9-4a1f-bb70-02c72b692d3d ONBOOT=yes If I instead boot it up, do *not* press the "install to hard drive" button, but instead open Network Settings, pressing Options..., and then Save... (without actually changing any settings), an ifcfg-Wired_connection_1 file appears, containing the following: HWADDR=52:54:00:C0:1B:C2 TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME="Wired connection 1" UUID=2b11723c-e0d0-4b02-a6c6-22823205e39e ONBOOT=yes So in total six IPv6-related config lines are missing, if the files was supposed to contain the same. In addition the connection name is different ("eth0" vs "Wired_connection_1").
The bug is still present in F18 TC2.
NM creates default auto connection for which NM returns these settings: name: Wired connection 1 uuid: fa4d78b4-0219-4cf1-8e62-760b63510637 type: 802-3-ethernet ------------------------------------------ Setting: 802-3-ethernet mac-address: 82 84 0 127 109 177. Setting: connection timestamp: 1355747214 type: 802-3-ethernet id: Wired connection 1 uuid: fa4d78b4-0219-4cf1-8e62-760b63510637 where ipv4, ipv6 settings are missing (i.e. default) Then anaconda modifies 'connection' 'id' setting to device name ("eth0") and updates settings of the connection with these settings, but the updated settings are: name: eth0 uuid: fa4d78b4-0219-4cf1-8e62-760b63510637 type: 802-3-ethernet ------------------------------------------ Setting: 802-3-ethernet mac-address: 82 84 0 127 109 177. Setting: connection timestamp: 1355747396 type: 802-3-ethernet id: eth0 uuid: fa4d78b4-0219-4cf1-8e62-760b63510637 Setting: ipv4 routes:. addresses:. dns:. method: auto Setting: ipv6 routes:. addresses:. dns:. method: ignore see the last line. And generated ifcfg file mirrors this with missing IPV6INIT=yes Which seems to me as inconsistency on NM side. We probably could easily update also 'ipv6' 'method' setting in anaconda but I'd prefer to fix it in NM (if I am correct).
(In reply to comment #14) > Setting: ipv6 > routes:. > addresses:. > dns:. > method: ignore Method 'ignore' is wrong, the right one is 'auto'. Ignore is sort of obsolete hack to avoid NetworkManager's bugs. As of NetworkManager 0.9.6 you should rely on its IPv6 processing. > Which seems to me as inconsistency on NM side. We probably could easily > update also 'ipv6' 'method' setting in anaconda but I'd prefer to fix it in > NM (if I am correct). Actually, automatic new connections in NM have method set to auto. I don't know how you get the ignore there. All automatically generated connections should have both IPv4 and IPv6 set to auto.
Created attachment 664934 [details] [PATCH] ifcfg-rh: treat missing IPv6 setting as Auto when writing ifcfg file (In reply to comment #11) > In F18 TC1 we are dumping settings of default auto connections run by NM > (because of missing ifcfg files) into ifcfg files. Although these > connections enable ipv6 if I am not mistaken, the dumped files don't contain > IPV6INIT=yes line, so there seems to be some inconsistency, perhaps in > ifcfg-rh plugin writer? Looks like the right analysis!
Created attachment 665388 [details] [PATCH] ifcfg-rh: treat missing IPv6 setting as IPv6 "auto" method (rh #830434) Updated patch. It has also bee pushed to upstream master branch: 954ce65e9968be45378b4f81f05387eac847b33f I'll build F18 package with the patch shortly.
NetworkManager-0.9.7.0-11.git20121004.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/NetworkManager-0.9.7.0-11.git20121004.fc18
Package NetworkManager-0.9.7.0-11.git20121004.fc18: * 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 NetworkManager-0.9.7.0-11.git20121004.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20597/NetworkManager-0.9.7.0-11.git20121004.fc18 then log in and leave karma (feedback).
NetworkManager-0.9.7.0-11.git20121004.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Tore, can you please check whether the issue is really fixed in smoke9 image? http://dl.fedoraproject.org/pub/alt/qa/20121219_f18-smoke9/ Thank you.
(In reply to comment #21) > Tore, can you please check whether the issue is really fixed in smoke9 image? > http://dl.fedoraproject.org/pub/alt/qa/20121219_f18-smoke9/ I'd be happy to, but that URL gives me a 403 Forbidden error message. Tore
make sure you're not trying it with https? works fine here.
I just clicked the link provided. But now it worked, so it must have been some transient problem. Anyway, tried installing on a IPv6-only network using DHCPv6, and it worked just fine. IPV6INIT=yes was found in the default installed ifcfg-eth0 file. So I can confirm that the problem appears to be fixed. Thanks! Tore
Thanks.