Re: udev being an ass
On Wed 28 Aug 2019 at 03:00:01 (-0400), Gene Heskett wrote:
> 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.
Wait a minute: you've just proved that you recognise stanzas in
/etc/udev/rules.d/70-persistent-net.rules, so why are you looking for
it in dmesg? And anyway, all the stanzas listed here are from my
machines, not yours.
> 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.
Why bother to do that: when you're lining up the sights on a mounted
gun, why would you start shifting the target around?
> > 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.
They are. That's why my dmesg doesn't see the stick at all: it's not
plugged in. It's tossed in a box with sundry USB memory sticks.
> Maybe its still plugged in?
Repeat: no.
But that wlan stanza above (last of the three quoted) is persistent,
it's in a file called 70-persistent-net.rules and the hint is in the
name of the file.
If that machine ever does meet that stick again, it'll name it wlan0:
NAME="wlan0". And it will have recogised it by its MAC, the address
attribute: ATTR{address}=="c4:3d:c7:bf:8d:0e". That's really all
you need to know about the stanza, even if it does look like swahili.
Cheers,
David.
Reply to: