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"
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?
Lastly, I've never seen a /dev/eth* or /dev/wlan* and have no idea
who would create them or what they would be used for.
> > There's a machine with two 3Com NICs. If you don't like the
> > allocation, you just switch eth0 and eth1. (One assumes that the
> > backplanes have been physically marked so that the connectors
> > themselves can be distinguished.) So you don't need to touch
> > your configuration, by which I assume you mean /e/n/i and suchlike.
> >
> yes.
>
> > > I do not know of any way around this, other than only ever having
> > > one interface per computer, which may work OK in some situations,
> > > but definitely not in others.
Cheers,
David.
