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

[Adam Williamson]

On Tue, 2013-05-21 at 14:33 -0600, Chris Murphy wrote:
> On May 21, 2013, at 2:08 PM, Adam Williamson <awilliam at redhat.com> wrote:
> 
> > On Tue, 2013-05-21 at 14:02 -0600, Chris Murphy wrote:
> > 
> >> 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.
> > 
> > The question of whether it should be *system wide* is a different
> > question from whether it should *persist*.
> 
> I'm just trying to figure out the simple case for now: single user who
> is an admin. I'm experiencing undesirable behavior. If this simple and
> common case isn't working out well, then I don't expect the more
> complex cases to work out much better. And as an ape who wears pants,
> I try to limit how confused I get in a given time frame.

It's my experience that this is a dangerous way to operate. You can't
just pretend complex cases don't exist and 'fix' the simple case. Well,
you can, but the chances are about 100% that the next thing that happens
will be an irate bug report from someone in the 'complex' bucket.

In my experience it's much better to step back and consider the correct
design for *all*, or at least as many as possible, supported use cases,
then implement that, than start trying to take short cuts.

> 
> 
> 
> > 
> >> 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. 
> > 
> > That's nothing to do with NM, it's the 'persistent device naming' stuff
> > at a lower level. Up to F18 this was being done by biosdevname, which
> > gave the 'p5p1' naming; in F19 it's being done by systemd, which gives
> > the 'en5s0' naming. There was an effort to ensure they at least both
> > called the most common case 'em1', but beyond that, they have different
> > naming schemes. Life's fun, huh. This kinda sucks, but it's not NM's
> > fault. There was discussion of the issue on this list earlier in the f19
> > cycle.
> 
> Is Gnome > Settings > Network leveraging Network Manager? If so, it's
> using a different naming convention than systemd, and it seems the two
> are involved in some non-deterministic confusion.

I'm not sure what you mean by 'it's using', exactly.

You are in the GNOME control center's network configuration module. It
does, indeed, configure NetworkManager.

Note that the name of a NetworkManager connection is a different thing
from the name of a network interface, though often the name of an NM
connection is initially set to match that of the network interface which
backs it. You can change one without changing the other, and vice versa.
This may be a source of some confusion (and possibly bugs) here. I don't
have enough familiarity with your situation to say.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net