Re: udev being an ass
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"
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.
> 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.
Reply to: