[Pkg-utopia-maintainers] Bug#416526: installation-report:
semi-successful desktop install
Eddy Petrișor
eddy.petrisor at gmail.com
Tue Apr 3 12:53:09 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Langasek wrote:
> On Fri, Mar 30, 2007 at 04:02:42AM +0300, Eddy Petrișor wrote:
>>> Uh, putting your comments on the process *in-line as shell comments* is very
>>> difficult to read; you also show three tests but only show the contents of
>>> /etc/network/interfaces in two of them, which I find confusing. It would be
>>> a lot clearer if you would summarize your findings.
>
>> Ok, I added comments/summaries above each test (in fact 4 of them).
>
> Ok, thanks.
>
> So it happens that I've just done my first real etch install onto a new
> laptop. The desktop is great, but network-manager is /awful/ for my
> purposes; not because I don't want a desktop applet managing my connection
> -- I in fact do want this -- but because it stores all my wep keys under
> lock and key, and as a result my wifi connection isn't brought up until I
> log into the GUI. This is doubly-broken for me because I want to be able to
> use Kerberos for network-based login *at* the GUI...
>
> None of this is anything that I think should be RC for etch, though I look
> forward to trying to help find a solution better-integrated with ifupdown
> for lenny. In the meantime, I'll probably install waproamd for my own use.
>
>> Summaries are separated between some visible markers.
>
>>> It is certainly the case that /etc/init.d/networking should have no effect
>>> on interfaces that are not marked 'auto'.
>
>> allow-hotplug ones should be managed, too (according to the README.Debian
>> examples)
>
> Uh, I don't understand what you mean by "too". I was talking about what
> *ifupdown* does with interfaces that are not marked 'auto', which is:
> nothing. The interface is only managed by /etc/init.d/networking if it's
> marked 'auto'; if it's marked allow-hotplug and *not* marked auto, it's
> managed via the hotplug system exclusively.
>
>>> fact that it is possible in the NM applet to *override* the status of an
>>> interface sounds to me like a feature, not a bug.
>
>> That would be ok *if* I would still be able to use the init script to stop
>> and start networking from the console. Since X might not start, it might
>> not allowing me to maneuver networking from the console until I:
>
>> 1) remove NM from the system,
>> 2) start in X and use NM to start it (which leaves the init script broken with
>> allow-hotplug, and partly broken with auto)
>> 3) add a dummy hook to the interface I want to work with and restart dbus, to NM
>> does not handle the connection anymore
>> 4) modify interfaces to use a static IP
>
>> All of these are suboptimal, IMHO.
>
> Well, at this point the problem you're describing is not reproducible for
> me.
>
> I've set up my ethernet interface as:
>
> # The primary network interface
> auto eth0
> allow-hotplug eth0
> iface eth0 inet dhcp
The default install, in my case had no "auto eth0" line, only an
"allow-hotplug eth0" line.
I tested in a either / or kind of way wrt allow-hotplug/auto.
So what I'm trying to say is that, by default, you don't have
"auto", so you get the asymmetric behaviour. IMO, this violates the
principle of least surprise.
> I have manually disabled networking with NM. I have then run
Strange, you *had*to* disable it? Wasn't it disabled by default?
>> --------------------------------------------------
>
>> The first situation starts with NM removed, after a reboot, with
>> "allow-hotplug" set in interfaces.
>
>> After "networking stop", "networking start" has no effect.
>> So this whole issue looks like is related both to NM and the
>> "allow-hotplug" vs. "auto" option.
>
>> Sorry for not provifing full information here.
>
>> --------------------------------------------------
>
> So what I understand from this description is that 'allow-hotplug eth0' was
> set, and 'auto eth0' was /not/ set, so this behavior of
> /etc/init.d/networking is expected.
Yes, while this is the default I got after installation...
About the "expected", as I said before, I have my reservations.
>> Script started on Jo 29 mar 2007 19:57:11 +0300
>> debian:/# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
[..]
>> debian:/# ps ax | grep dhc
>> 1740 ? S<s 0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
>> 8507 pts/2 R+ 0:00 grep dhc
>> debian:/# /etc/init.d/networking stop
>> Deconfiguring network interfaces...There is already a pid file /var/run/dhclient.eth0.pid with pid 1740
>> killed old client process, removed PID file
[..]
>> debian:/# ps ax | grep dhc
>> 8540 pts/2 S+ 0:00 grep dhc
>> debian:/# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> BROADCAST MULTICAST MTU:1500 Metric:1
>> debian:/# /etc/init.d/networking start
>> Configuring network interfaces...done.
>> debian:/# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> BROADCAST MULTICAST MTU:1500 Metric:1
>> debian:/# /etc/init.d/networking restart
>> Reconfiguring network interfaces...done.
>> debian:/# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> BROADCAST MULTICAST MTU:1500 Metric:1
> This is all consistent with the ifupdown documentation.
> /etc/init.d/networking uses "ifup -a" and "ifdown -a"; when "ifdown -a" is
> called it affects *all* interfaces, when "ifup -a" is called it affects
> *only* those interfaces that are marked 'auto'. Yes, this is asymmetrical,
> but it's asymmetrical for a reason.
That reason being?
>> --------------------------------------------------
>> This test starts without NM installed and with "auto eth0" in interfaces.
>> In this case the init script behaves as expected, stop is stop, start is
>> start, restart is restart.
>> --------------------------------------------------
>
> Right, again as expected.
Yes, of course, this is the desired behaviour :-) .
>> --------------------------------------------------
>> As soon as NM enters the stage, things become weird, even if auto is kept:
>
>> The interface is down, (init) start has no effect until the interface is stopped
>> through the init script.
>
>> (this continues the test above)
>
>> --------------------------------------------------
>
>> debian:/# # I will try to install NM, too
>> debian:/# aptitude install network-manager
>> [...]
>> Reloading system message bus config...done.
>> Restarting network connection manager: NetworkManager.
>> Restarting network events dispatcher: NetworkManagerDispatcher.
>
>> debian:/# ifconfig
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[..]
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
[..]
>> debian:/# /etc/init.d/networking start
>> Configuring network interfaces...done.
>> debian:/# ifconfig
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[..]
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
[..]
>> debian:/# /etc/init.d/networking stop
>> Deconfiguring network interfaces...There is already a pid file /var/run/dhclient.eth0.pid with pid 8818
>> killed old client process, removed PID file
>> Internet Systems Consortium DHCP Client V3.0.4
[..]
>> done.
>> debian:/# ifconfig
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
[..]
>> debian:/# /etc/init.d/networking start
>> Configuring network interfaces...Internet Systems Consortium DHCP Client V3.0.4
[..]
>> bound to 10.0.2.15 -- renewal in 38286 seconds.
>> done.
>> debian:/# ifconfig
>> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
>> inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
[..]
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
[..]
>> debian:/# exit
>
>> Script done on Jo 29 mar 2007 20:34:09 +0300
>
> Ok, looks perfectly consistent to me -- you install network-manager, it
> takes control of the interface; /etc/init.d/networking doesn't bring it up
> because network-manager didn't bring the interface *down* using ifupdown, so
> ifup believes the interface is already configured (this is the same thing
> that happens if you run 'ifconfig eth0 down'); running stop and then start
> again resets this.
Ok, I wasn't aware of that behaviour. It definetly *looked* weird.
>> --------------------------------------------------
>> NM installed, connection was activated the GNOME applet, the interface has
>> "allow-hotplug"
>> /etc/init.d/networking stop has no effect.
>> This configuration would be the one after the default install, *after* the
>> user realises that he has to start the interface via the applet.
>> --------------------------------------------------
>
> Ah, again, in this case the eth1 interface was not brought up by ifupdown,
> but by network-manager; so there's no ifupdown state in
> /etc/network/run/ifstate telling ifdown that it needs to act on this
> interface. I agree that this is surprising; perhaps network-manager could
> be fixed to write to /etc/network/run/ifstate for better integration?
Yes, this is part of the issue I am talking about.
- --
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGEk40Y8Chqv3NRNoRAp2jAJ9xhMCu5Uy75T+vB37+zpYKtHP/mwCguFbP
yQmBUVa0spWNlLLoa4a0jaQ=
=NwWI
-----END PGP SIGNATURE-----
More information about the Pkg-utopia-maintainers
mailing list