[root@F19 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: p5p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1e:c2:1d:50:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.144/24 brd 192.168.1.255 scope global p5p1
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:c2ff:fe1d:507e/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether c6:ee:74:97:d6:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever

Created attachment 749060 [details]
lspci -vv for the NIC

Created attachment 749061 [details]
dmesg

Created attachment 749062 [details]
journalctl for this boot

The wired connection is physically present throughout boot and isn't touched.

Relevant lines before I manually change the wired connection from Off to On in Gnome shell:

May 16 14:19:22 F19.localdomain systemd[1]: Starting Network Manager Wait Online...
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): carrier is OFF
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): new Ethernet device (driver: 'sky2' ifindex: 2)
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): exported as /org/freedesktop/NetworkManager/Devices/0
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): bringing up device.
May 16 14:19:22 F19.localdomain kernel: sky2 0000:0c:00.0 p5p1: enabling interface
May 16 14:19:22 F19.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP): p5p1: link is not ready
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): preparing device.
May 16 14:19:22 F19.localdomain NetworkManager[408]: <info> (p5p1): deactivating device (reason 'managed') [2]
May 16 14:19:22 F19.localdomain NetworkManager[408]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring...
May 16 14:19:22 F19.localdomain NetworkManager[408]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring...

[snip]

May 16 14:19:24 F19.localdomain kernel: sky2 0000:0c:00.0 p5p1: Link is up at 100 Mbps, full duplex, flow control both
May 16 14:19:24 F19.localdomain NetworkManager[408]: <info> (p5p1): carrier now ON (device state 20)
May 16 14:19:24 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
May 16 14:19:24 F19.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): p5p1: link becomes ready


And then when I manually enable the wired connection in Gnome shell, from Off to On:

May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) starting connection 'ens5'
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 1 of 5 (Device Prepare) scheduled...
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 1 of 5 (Device Prepare) started...
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 2 of 5 (Device Configure) scheduled...
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 1 of 5 (Device Prepare) complete.
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 2 of 5 (Device Configure) starting...
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: prepare -> config (reason 'none') [40 50 0]
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 2 of 5 (Device Configure) successful.
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 2 of 5 (Device Configure) complete.
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) scheduled.
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) started...
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: config -> ip-config (reason 'none') [50 70 0]
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> dhclient started with pid 1745
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Beginning IP6 addrconf.
May 16 14:21:03 F19.localdomain avahi-daemon[306]: Withdrawing address record for fe80::21e:c2ff:fe1d:507e on p5p1.
May 16 14:21:03 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) complete.
May 16 14:21:03 F19.localdomain dhclient[1745]: Internet Systems Consortium DHCP Client 4.2.5
May 16 14:21:03 F19.localdomain dhclient[1745]: Copyright 2004-2013 Internet Systems Consortium.
May 16 14:21:03 F19.localdomain dhclient[1745]: All rights reserved.
May 16 14:21:03 F19.localdomain dhclient[1745]: For info, please visit https://www.isc.org/software/dhcp/
May 16 14:21:03 F19.localdomain dhclient[1745]: 
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info> (p5p1): DHCPv4 state changed nbi -> preinit
May 16 14:21:04 F19.localdomain dhclient[1745]: Listening on LPF/p5p1/00:1e:c2:1d:50:7e
May 16 14:21:04 F19.localdomain dhclient[1745]: Sending on   LPF/p5p1/00:1e:c2:1d:50:7e
May 16 14:21:04 F19.localdomain dhclient[1745]: Sending on   Socket/fallback
May 16 14:21:04 F19.localdomain dhclient[1745]: DHCPREQUEST on p5p1 to 255.255.255.255 port 67 (xid=0x61ef0f5f)
May 16 14:21:04 F19.localdomain dhclient[1745]: DHCPACK from 192.168.1.1 (xid=0x61ef0f5f)
May 16 14:21:04 F19.localdomain dhclient[1745]: bound to 192.168.1.144 -- renewal in 35044 seconds.
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info> (p5p1): DHCPv4 state changed preinit -> reboot
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info>   address 192.168.1.144
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info>   prefix 24 (255.255.255.0)
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info>   gateway 192.168.1.1
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info>   hostname 'F19'
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info>   nameserver '75.75.75.75'
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info>   nameserver '75.75.76.76'
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
May 16 14:21:04 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Commit) started...
May 16 14:21:04 F19.localdomain avahi-daemon[306]: Joining mDNS multicast group on interface p5p1.IPv4 with address 192.168.1.144.
May 16 14:21:04 F19.localdomain avahi-daemon[306]: New relevant interface p5p1.IPv4 for mDNS.
May 16 14:21:04 F19.localdomain avahi-daemon[306]: Registering new address record for 192.168.1.144 on p5p1.IPv4.
May 16 14:21:05 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
May 16 14:21:05 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Commit) complete.
May 16 14:21:05 F19.localdomain NetworkManager[408]: <info> (p5p1): device state change: secondaries -> activated (reason 'none') [90 100 0]
May 16 14:21:05 F19.localdomain NetworkManager[408]: <info> Policy set 'ens5' (p5p1) as default for IPv4 routing and DNS.
May 16 14:21:05 F19.localdomain NetworkManager[408]: <info> Activation (p5p1) successful, device activated.

I found part of the problem:
[root@F19 network-scripts]# cat ifcfg-ens5 
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=ens5
UUID=e82eb572-6909-44cb-93b7-e7d4e6398fc7
ONBOOT=no
HWADDR=00:1E:C2:1D:50:7E
PEERDNS=yes
PEERROUTES=yes


onboot=no

But why? Once set to yes, system reboots with p5p1 enabled.

OK I figured this out. 

When installing F19, the ethernet cable is disconnected (and there's no wireless firmware so it isn't even seen as a connection). The installer sees the NIC on launch, but is disconnected. I proceed with the installation per usual, before rebooting, I capture the installer files I'm attaching, including /etc/sysconfig/network-scripts/ifcfg-enp0s3 which contains:

ONBOOT=no

So I'm changing it anaconda, even though it's arguably a Gnome shell bug also. Gnome should change this value so that the Wired On/Off state is sticky through reboots. So it's equally a Gnome bug in my opinion, maybe it's more of a Gnome bug.

Proposing as a blocker on the basis it's cruel and unusual punishment, even though I can find no criteria for it. It's just mean to do this to people. But at worst I think it qualifies for freeze exception.

I imagine all of these cases people talk about, where users don't have internet connections when doing installs, and all of them run into this bug having no idea how to fix it.

Created attachment 749153 [details]
ifcfg-enp0s3

Created attachment 749155 [details]
ifcfg.log

Created attachment 749157 [details]
storage.log

Created attachment 749158 [details]
anaconda.log

Created attachment 749159 [details]
program.log

-1 beta blocker, this doesn't violate any criteria and is easy enough to deal with in any number of ways.

I don't know what's really a bug here, but I suspect it's going to need a degree of unpicking. You're dealing with several different components and config layers, here. Notably, NM has separation between user- and system-level configuration, for one thing.

If the connection is off at every boot after you log in to your user session, even if you've explicitly set it to on in your user session NM, I'd think that's a bug in GNOME, at least by analogy with how wireless connections behave: once you set up a wireless connection in your user session, GNOME will try and reconnect to it whenever it's available. You'd think it would do the same for wired. But if GNOME does bring up the wired connection when you log in - just it doesn't come up before - then I think GNOME would say it's behaving as intended: a regular user sets the state of connections _for that user's session_, not for the system. There is a box labelled 'Make available to other users' in the GNOME network configuration interface which effectively applies your settings for a given connection system-wide if you check it.

Confirm that it's off after I log into my user session, even after that user enabled it before reboot. It's never activated, except manually.

In System Settings > Network > Wired > Gear button > Identity is an option Connect automatically which is not checked. Make available to other users is checked. If I check "Connect automatically" and then reboot, it is persistent.

I think this is an obscenity of UI/UX. I have messed around with this for 6 hours today, and it's about as angry as any bug has made me in a month.

It's unclear if the Gnome team expects anaconda to set ONBOOT=no just because the cable isn't connected when the system is installed, as if the user explicitly unchecked "Connect automatically" in Gnome Settings Network. So it's plausible it's still an anaconda bug.

Anaconda 19.25-1, launch, choose language. The very next screen is Network Configuration where it sees the NIC, and says the cable is unplugged. There's a Configure button. I click it.

In the General tab "Automatically connect to this network when it is available" is not checked.

In Fedora 18 Live, this setting is checked in anaconda. So there's been a change in the automaticity of connecting to networks between 18 and 19. And it's not consistent with how it behaves for a wireless network with the same release.

Formerly we set ONBOOT=yes to at least one device having link in Fedora.

Having ONBOOT=yes for all wired devices (regardless of carrier status) seems acceptable to me. Patch sent for review.

"Having ONBOOT=yes for all wired devices (regardless of carrier status) seems acceptable to me. Patch sent for review."

So, I know there's a lot of history here, it might be worth asking one of the 'old hands' about it. For a long time we only enabled the network connection post-install if it was used during install, even if it was plugged in during install but not used, it would be disabled post-boot.

A default of 'assume we always want to be connected to everything' seems more modern, I guess, but not inherently correct.

Also, looking at your patch, it seems to differ rather from how this stuff was done before: instead of defining different defaults in installclasses/fedora.py and installclasses/rhel.py and having the rest of the code be the same for both (and just applying whatever default is defined in there), you've put a RHEL conditional in network.py. I don't know if that's a no-no or not; it just seemed worth pointing out.

Most interestingly, why does Chris' testing indicate this behaviour changed between 18 and 19? It seems like your patch is to code that's been around for a while, but his testing indicates something else changed quite recently; maybe that's worth looking at?

There's been another change between anaconda 19.25-1 and 19.28-1. 

If the computer has a recognized wired NIC without cable attached, 19.25-1 will present on page 2, a Network Configuration page with a Configure button. Under the same conditions, 19.28-1 doesn't present the Network Configuration page.

In both cases /etc/sysconfig/network-scripts/ifcfg-ens5 contains ONBOOT=no.

(In reply to Adam Williamson from comment #17)
> "Having ONBOOT=yes for all wired devices (regardless of carrier status)
> seems acceptable to me. Patch sent for review."
> 
> So, I know there's a lot of history here, it might be worth asking one of
> the 'old hands' about it. For a long time we only enabled the network
> connection post-install if it was used during install, even if it was
> plugged in during install but not used, it would be disabled post-boot.


And for that long time there had been user complaints to change it in a way we did in F17: if no network has been used during installation (eg DVD install) and we find a wired device having link before end of installation we configure it to be enabled post-boot.
commit b3394593e521ffd1dc051e7ff330e99af903d420
(bug 498207, bug 806466)

> 
> A default of 'assume we always want to be connected to everything' seems
> more modern, I guess, but not inherently correct.
> 

That's why I only say "acceptable for me". I don't like it much either and I don't dare to say what is correct here. I expected complains or feedback in patch review but there were not any.

> Also, looking at your patch, it seems to differ rather from how this stuff
> was done before: instead of defining different defaults in
> installclasses/fedora.py and installclasses/rhel.py and having the rest of
> the code be the same for both (and just applying whatever default is defined
> in there), you've put a RHEL conditional in network.py. I don't know if
> that's a no-no or not; it just seemed worth pointing out.

It is intentional, I'd keep networking code (and its dependencies) in network module and use installclass just to tell us what type of installation we are in. I don't see any benefit in having the actual working code (eg what we used to have in setNetworkOnbootDefault) in installclasses modules.

> 
> Most interestingly, why does Chris' testing indicate this behaviour changed
> between 18 and 19? It seems like your patch is to code that's been around
> for a while, but his testing indicates something else changed quite
> recently; maybe that's worth looking at?

It is exactly the thing that has been added for RHEL (post F18) and is conditionalized to be applied just to RHEL in this patch.

commit 70e7941f4062ced0dc5d553148b70590e293cbdb
Author: Radek Vykydal <rvykydal>
Date:   Tue Feb 19 10:47:17 2013 +0100

    Set ONBOOT=no for default autoconnections (#905918, #886090)
    
    Autoconnections are set up by NM for devices not having ifcfg file
    (ie those not activated by dracut or not configured in kickstart).
    We want to default to "no" for this devices in RHEL.
    We even don't want to bring up the autoconnections in installer
    environment, but that is something for a separate bug.

diff --git a/pyanaconda/network.py b/pyanaconda/network.py
index 456fd33..06136e1 100644
--- a/pyanaconda/network.py
+++ b/pyanaconda/network.py
@@ -314,6 +314,8 @@ def dumpMissingDefaultIfcfgs():
         try:
             nm.nm_update_settings_of_device(devname, 'connection', 'id', devname)
             log.debug("network: dumping ifcfg file for default autoconnection on %s" % devname)
+            nm.nm_update_settings_of_device(devname, 'connection', 'autoconnect', False)
+            log.debug("network: setting autoconnect of %s to False" % devname)
         except nm.DeviceSettingsNotFoundError as e:
             log.debug("network: no ifcfg file for %s" % devname)
         rv = True


On top of this behaviour - honoring NM's ONBOOT=yes for Fedora - the removed setNetworkOnbootDefault (from fedora.py) does nothing.

Discussed at 2013-05-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-20/f19beta-blocker-review-7.2013-05-20-16.07.log.txt . Rejected as a blocker as it does not come close to violating any criteria and is easy to adjust post-install. Rejected as a freeze exception issue as we're getting close to beta release and it doesn't seem a good idea to fiddle too much unnecessarily at this point: we can do it post-Beta, though.

Radek - did you guys decide whether to go ahead with this or not yet? I personally don't have any objection to it, I just knew it was a 'sensitive' area so I wanted to point it out to make sure everyone was on board. If the rest of the team is fine with it, though, let's go ahead...

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

AFAICS this hasn't been changed, default is still 'no'.

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

I can confirm this "cruel and unusual punishment" is still present on F22 Final. I took F22 Workstation Live, booted it on a desktop pc with ethernet cable unplugged, installed, rebooted, and plugged in the cable. It does not connect automatically, I have to manually enable the wired connection after every boot. In other words, it has ONBOOT=no. It is possible to enter the wired configuration settings and set "connect automatically", but you have to know about it.

This is fixed with F23 Alpha. Radek says there're no longer setting ONBOOT=no by default.