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.
> 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.
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>
