Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:
> On Tuesday 17 May 2016 10:38:52 Elimar Riesebieter wrote:
> > * Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:
> > > On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
> > [...]
> > > > In my opinion, a warning is in order ("this might not be doing
> > > > what you think it does"), but deprecated seems exaggerated to me.
> > > >
> > > > [1] Schocking Truth! Not everything seen on the Internet is true!
> > >
> > > About 4th or 5th down in that list of hits, this one labeled for
> > > debian, is a bit long winded but finishes up recommending one edit
> > > his personal .bash-aliases file to contain this:
> > >
> > > alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop;
> > > date; echo sleeping; sleep 2; echo waking; date; invoke-rc.d
> > > networking start'"
> > >
> > > Is that simple? Elegant and correct? No, if the networking script
> > > was broken, its still broken!
> >
> > Again, I recommend to read [0] and [1].
> >
> > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
>
> Looks like mine has been "fixed" by the removal of the hotplug stuff. I
> do not see that as a disadvantage, udev can do that much unwanted damage
> all by itself.
I'm not sure what this has to do with your argument with udev.
IIRC you had been switching cards and got up to eth5 when you posted.
Apparently you hadn't read man udev, and though you said you'd scanned
/etc/udev/rules.d/70-persistent-net.rules you didn't post it, so we
couldn't point anything out. udev had been doing what it was designed
to do.
You don't see any disadvantage to removing the "hotplug stuff".
Hooray, let's go back to PCs as static boxes. Shut it down to add
a USB device. Who needs udev anyway?
> > [1]
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> >
> And this falls over in its morning oatmeal if the box you installed on
> turns out to be a dud, so you go get another box and just move the hard
> drive because you've already moved 20 megs worth of gcode you don't want
> to do again if you reinstall on the newer box. udev remembers the old
> interface and very helpfully dreams up a new name for it, without
> reaching into the interfaces file to correct the port names there. Or
> advising the user about it unless he goes crawling thru the logs. You
> get no warning other than the networking can't be brought up that worked
> perfectly on the box with an AMD Family 15 cpu with an unfixable halt
> bug because it doesn't yet do a microcode update at the family 15 time
> point. That non-warned about renaming is not an excusable behavior.
> But it took me 2 days to fix it each time I moved the drive because I
> had to come here and hope for an answer each time. I learned a lot
> thanks to the kind folks here, but I fail to grok the reason for that
> behavior in the first place. Because of some rare condition, you make
> all the other users with a less rare condition suffer?
A previous time this reference was pointed out to you, you realised
that it has no relevance to wheezy. Even if you upgrade to jessie,
it's of little relevance as Debian preserves the existing behaviour
if you don't try to wreck it/second-guess it/believe every posting on
the internet.
If you remember that far back, the linux kernel, faced with two NICs,
would toss a coin before naming one eth0 and the other eth1. This had
the splendid side-effect that you could think your LAN was the WAN and
vice versa, and there was nothing you could do about it.
udev meant that each NIC always got the same name even if you took it
out of the box one week and put it back the next. It is easy to
override that behaviour if it's undesired.
You appear to think that the old behaviour (the first NIC discovered
gets named eth0) is the only sensible behaviour because everyone is
always tinkering with the hardware, swapping boards out etc. as you do.
If that is really important, why not just write a script to clean
/etc/udev/rules.d/70-persistent-net.rules at every reboot.
That solves your problem, but allows other people to have a default
system that can sensibly give a stable configuration on machines
that have more than instance of each type of hardware (multiple
NICs, burners, USB devices.
Cheers,
David.
Reply to: