On Tuesday 27 August 2019 23:42:25 David Wright wrote:
> On Tue 27 Aug 2019 at 19:41:41 (-0400), Gene Heskett wrote:
> > On Tuesday 27 August 2019 17:38:34 David Wright wrote:
> > > On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > > > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > > > I'll do it, but the date on it is today, so I suspect
> > > > > something in /lib/udev/rules.d is behind the re-write.
> > > >
> > > > If that file exists, it's used. Quotes in the file are ignored.
> > > > Valid content in the file is used to map various interfaces
> > > > (typically identified by their MAC addresses) to interface
> > > > names.
> > > >
> > > > If the file does not exist, it will be (re)created.
> > > >
> > > > If the file exists, but your interface isn't in it (as
> > > > determined by whatever criteria are being used to identify the
> > > > interface, typically the MAC address), then a new name will be
> > > > assigned for it (skipping the names that are already in use),
> > > > and this will be written to the file.
> > > >
> > > > So, the suggestion was to remove the file from the system before
> > > > replacing all your interfaces (or moving the hard drive to a new
> > > > computer, which from the hard drive's point of view is
> > > > equivalent to "you replaced all the interfaces"). In that
> > > > situation, the file doesn't exist, so it will be created from
> > > > scratch. You've got one or more interfaces that don't (yet)
> > > > have assigned names, so names will be assigned to them. One of
> > > > them will become eth0, one of them will become eth1, and so on,
> > > > depending on how many interfaces there are in the new machine.
> > > >
> > > > If you have exactly one interface, it will become eth0, and you
> > > > will be happy.
> > > >
> > > > If you have more than one interface, you have no way of knowing
> > > > which one will become eth0. That's the situation the newfangled
> > > > thing was intended to remedy, but it doesn't really succeed at
> > > > that either.
> > >
> > > I think you're being oblique. There's a race. The udev method was
> > > not designed to eliminate that, but to make sure that the
> > > resulting names would forever be the same, once the race has been
> > > run the first time.
> > >
> > > In the past, when I have had a mobo fail and moved everything into
> > > a spare box, I've found that the new machine (I assume it's the
> > > CMOS sensu lato) is happiest when you add one card at a time, run
> > > the POST and let the CMOS deal with it; then add the next.
> > > In a similar manner, you *could* fix the race by booting up linux
> > > with one new interface at a time …
> > >
> > > > In almost every situation, you need to let the computer ASSIGN
> > > > the names first, then login to it and see what interface got
> > > > what name, and then adjust your configs accordingly.
> > >
> > > … but really there's no need, because it's obvious from the rules
> > > file what is going on.
> > >
> > > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > > ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
> > > ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> > >
> > > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > > ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
> > > ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
> >
> > Add another stanza that ends with eth2.
> >
> > And normally, one expects to see discovery someplace in dmesg.
> > but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth*
> > anyplace in the dmesg. Nor have I found a 6 doublet MAC address.
>
> Why? Here's an entry from one of my laptops:
>
> # USB device 0x:0x (ndiswrapper)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> ATTR{address}=="c4:3d:c7:bf:8d:0e", ATTR{dev_id}=="0x0", \
> ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
>
Nothing even remotely resembling that in my dmesg from that machine.
Since I have to goto the machine, which I'll do much later today, and
see if I can still make notes that make sense. I'll start by
editing /e/n/i to use the eth2 I do see.
> That entry is over five years old, from when I briefly used a Netgear
> wifi stick in it. Why should dmesg know anything about it today?
Good question, David. Here all this time I've been convinced that dmesgs
were always freshly generated. Maybe its still plugged in?
Thanks.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
