wired ethernet disabled between reboots, was: when startup delays become bugs

[Chris Murphy]

On May 21, 2013, at 1:09 PM, Dan Williams <dcbw at redhat.com> wrote:
>>> 
>>> 
>>> But this bug has brought me to a plethora of buggy behavior in the Gnome Settings Network panel, so maybe the misery was worth it.
>> 
>> *THIS*. *This* kind of thing is why NetworkManager remains unusable
>> for production network configuratoin. The very powerful and flexible
>> shell scripting written into the /etc/sysconfig/network-scripts
>> infrastructure is neither pro0perly displayed by nor manageable by the
>> NetworkManager gui's. It is not even a good GUI becuase it violates
>> over half of the open source GUI guidelines published by Eric Raymond
>> in his essay on GU's, "The Luxury of Ignorance".
> 
> I'd be very interested to know how, exactly, the network-scripts are
> "neither properly displayed nor manageable".  What options in the
> scripts do you not find in the GUI?

I think he's talking about buggy behavior rather than lake of parity. I have mind to file bugs on what I've experienced but the summary is:

1. Connect Automatically may work as designed, but it's a flawed design. It makes no sense to have an admin user enable a network through the Gnome shell toolbar icon (Network icon, flip the switch from Off to On), reboot, and then have no network. The widespread convention for all other such UI switches is that they're sticky. I don't have to go make them behave sticky by checking something five layers deep. Something I wouldn't have even considered exists as it's apparently unique, I've never encountered an automaticity option on Windows or OS X. It's a bizarre convention. Off means off, make that sticky through reboots. On means on, make that sticky through reboots.

2. The two buttons on the reset page, don't do anything. I click them, nothing happens. Only if I add one or more new profiles do those buttons do anything.

3. The naming convention of the interfaces is confusing. Sometimes it's ifcfg-en5s0 and sometimes ifcfg-p5p1 for the same interface and I don't know why. And even something in the network stack gets confused, while anaconda with a cable unattached install creates one settings file, isn't later honored until I rename it as p5p1 or whatever.

It's is sorta like no one has used this and bothered to file bugs on the behavior. Myself included. It's just a lot of really negative user experience, with a lot of testing and bugs to be file to describe the wonky behaviors.


>  And if so, please state *which*
> GUI, whether that's GNOME control center, nm-connection-editor, or KDE's
> network panel.

Gnome > Settings > Network

>  Also note the NetworkManager daemon and API usually
> provides the full range of functionality, customization, knobs,
> twiddles, properties, etc, and it's up to the GUIs to figure out what to
> display.  There's also nmcli, which we're furiously working on to expose
> everything admins may need without a GUI.

Maybe someone can explain to me the use case for ONBOOT= where its value isn't tied to the current network state. I wasted an inordinate,  unreasonable amount of time trying to figure this out before I realized what was going on.

An necessarily this relates to anaconda because it's setting up the weird behavior only for cabled ethernet connections lacking a cable at the time of the install. Yet it doesn't work this way for WiFi. It's inconsistent.


Chris Murphy