Bug 830434 - Omits "IPV6INIT=yes" from kickstart-generated ifcfg-* file
Summary: Omits "IPV6INIT=yes" from kickstart-generated ifcfg-* file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: dualstack F18Blocker, F18FinalBlocker 852808
TreeView+ depends on / blocked
 
Reported: 2012-06-09 14:46 UTC by Tore Anderson
Modified: 2012-12-21 02:14 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 852808 (view as bug list)
Environment:
Last Closed: 2012-12-21 02:14:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
[PATCH] ifcfg-rh: treat missing IPv6 setting as Auto when writing ifcfg file (1.86 KB, patch)
2012-12-17 15:36 UTC, Jirka Klimes
no flags Details | Diff
[PATCH] ifcfg-rh: treat missing IPv6 setting as IPv6 "auto" method (rh #830434) (6.89 KB, patch)
2012-12-18 09:55 UTC, Jirka Klimes
no flags Details | Diff

Description Tore Anderson 2012-06-09 14:46:50 UTC
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.

Comment 1 Jesse Keating 2012-06-11 22:31:04 UTC
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.

Comment 2 Tore Anderson 2012-06-13 23:56:04 UTC
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

Comment 3 Will Woods 2012-08-28 21:21:24 UTC
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'.

Comment 4 Tore Anderson 2012-08-29 06:46:43 UTC
(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

Comment 5 Will Woods 2012-08-29 16:21:04 UTC
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.

Comment 6 Tore Anderson 2012-08-29 18:12:44 UTC
(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

Comment 7 Adam Williamson 2012-11-28 17:49:58 UTC
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.

Comment 8 Chris Lumens 2012-12-05 19:38:51 UTC
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.

Comment 9 Tore Anderson 2012-12-05 19:47:46 UTC
Chris, I verified that the bug is present in F18 Beta, both DVD and Live CD variants. See bug #852808, comment #10.

Comment 10 Chris Lumens 2012-12-05 19:51:19 UTC
Alright, thanks.

Comment 11 Radek Vykydal 2012-12-12 15:26:05 UTC
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?

Comment 12 Tore Anderson 2012-12-13 14:01:02 UTC
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").

Comment 13 Tore Anderson 2012-12-15 18:39:22 UTC
The bug is still present in F18 TC2.

Comment 14 Radek Vykydal 2012-12-17 15:16:20 UTC
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).

Comment 15 Pavel Šimerda (pavlix) 2012-12-17 15:26:31 UTC
(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.

Comment 16 Jirka Klimes 2012-12-17 15:36:38 UTC
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!

Comment 17 Jirka Klimes 2012-12-18 09:55:07 UTC
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.

Comment 18 Fedora Update System 2012-12-18 13:06:55 UTC
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

Comment 19 Fedora Update System 2012-12-18 21:30:41 UTC
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).

Comment 20 Fedora Update System 2012-12-20 05:26:39 UTC
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.

Comment 21 Kamil Páral 2012-12-20 12:51:51 UTC
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.

Comment 22 Tore Anderson 2012-12-20 15:02:20 UTC
(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

Comment 23 Adam Williamson 2012-12-20 21:20:57 UTC
make sure you're not trying it with https? works fine here.

Comment 24 Tore Anderson 2012-12-20 23:14:47 UTC
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

Comment 25 Adam Williamson 2012-12-21 02:14:19 UTC
Thanks.


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