NM fails to connect when booting ?? -[not quite SOLVED]

[Michael J Gruber]

Bill Davidsen venit, vidit, dixit 18.03.2009 23:52:
> Michael J Gruber wrote:
>> Todd Zullinger venit, vidit, dixit 18.03.2009 04:25:
>>> William Case wrote:
>>>> It has been reported by someone else as a medium level bug.  See:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=470477
>>> Or see the changelog of NetworkManager-0.7.0.99-3:
>>>
>>> * Mon Mar 09 2009 Dan Williams <dcbw at redhat.com> - 1:0.7.0.99-3
>>> - Missing ONBOOT should actually mean ONBOOT=yes (rh #489422)
>>>
>>> Bug #489422 is "No network after last NM update"
>>> https://bugzilla.redhat.com/489422
>>>
>>>> The bug comments gave me the following work around:
>>>>
>>>> The automatic wired network connection can be made to work by doing:
>>>>
>>>> "if and only if the flag ONBOOT in
>>>> /etc/sysconfig/network-scripts/ifcfg-eth0 is set to "yes""
>>>>
>>>> My ifcfg-eth0 file had ONBOOT=no; I changed it to ONBOOT=yes and now my
>>>> Internet connection is made automatically on boot.
>>>>
>>>> I would think that this is more than a medium level concern,
>>>> particularly for new users of Fedora 10.
>>> Well, the levels aren't really used my many maintainers (though maybe
>>> they are for RHEL bugs, which 470477 is...).  But aside from that, the
>>> NM release on Fedora fixes the bug that a missing ONBOOT parameter is
>>> treated differently in NM than it was by the network service.  I can't
>>> see how having ONBOOT=no and NM not starting that device could be
>>> construed as an NM bug though.  It's perhaps a bug if some tool is
>>> automatically writing the ONBOOT=no into the ifcfg file when it
>>> shouldn't be.
>>
>> I'm sorry I have to disagree here, for two reasons:
>>
>> 1) People who installed F10 from DVD/CD have ONBOOT=no in their config
>> because anaconda put it there. Their wired connections used to be
>> brought up automatically by NM after logon, and this behaviour is
>> *broken* now. A bugfix which breaks existing, desirable behaviour for
>> existing users is a regression.
>>
> Do you see ONBOOT=no as a bugfix, and if so what bug? Every install probably 
> should ask if a NIC is present, and set to boot, never, or per-user via NM.

No, the fact that NM looks at ONBOOT is a bugfix
(https://bugzilla.redhat.com/show_bug.cgi?id=489398) which breaks
existing users' autoconnect.

> 
>> 2) ONBOOT really ought to be about what's happening on boot only. If
>> ONBOOT=no, don't bring up the interface during boot. If NM is allowed to
>> manage the device, NM should bring it up after logon no matter what
>> ONBOOT says. [1]
>>
> That makes it hard to have devices defined which aren't brought up. It's more of 
> an interference between anaconda, network and NM, but I don't think ignoring 
> ONBOOT is a great way to solve it, not breaking the setting in the first place 
> seems more useful.

I'm all for making things clearer in this regard (did I say doc?), for
F11. I just don't think it's a good idea to break F9/F10 installations
per update.

> 
>> So, if you want to change the default, go ahead and change it
>> consistently (anaconda+nm) for F11, but please don't break existing
>> default F10 installations.
>>
>> Michael
>>
>> [1] NM used to list these devices as "auto eth0" with editable config.
>> Now they are listed as "system eth0" which can't be edited. Maybe that
>> is the real root of the new behaviour?
>>
> 
>