Dmitry Semyonov wrote:
> The existing text creates an impression that what you should pay
> attention to is only the "onboard" name. Since all this was new to me,
> there was no ONBOARD name, and there was the usual PATH name there, I
> just assumed it was safe to use it without paying attention to the
> presence of a SLOT name, (which non-intuitively was listed between the
> lowest priority MAC and the lower priority PATH names).
So you would have benefitted from the addition of "or slot name" (but
we still haven't heard from anybody who would need to be told that
onboard names outrank slot names).
>>> the final name is assigned according to the following list of
>>> decreasing priorities:
>>> * ID_NET_NAME_FROM_DATABASE
>>
>> This would mean that (on my current system) "ASUSTek COMPUTER INC."
>> would take priority - no.
>
> You probably mixed it with the ID_OUI_FROM_DATABASE variable. The
> ID_NET_NAME_FROM_DATABASE is very rare according to some documentation
> I read while investigating the issue.
Hmm... I can't see anyone on the Internet claiming to have seen this
in the wild - and it isn't mentioned in the Freedesktop guide, the old
net-id.c comments, or the udev README. The one source I can find that
does seem to recognise it as existing is systemd.link(5). Odd!
>>> * ID_NET_NAME_ONBOARD
>>
>> This is the one the Release Notes already warn will take priority if
>> present (on my system, it isn't).
>
> It would be a stretch to call parenthesized side note a warning.
A side note presenting facts that you might need to be aware of in
order to devise a migration plan, presented in the section "issues".
Admittedly, "stretch" does come into this, but mostly as the release
when the Release Notes started including warnings about this.
>>> * ID_NET_NAME_SLOT
>>
>> This is the one it doesn't mention. If it's present, readers who are
>> following instructions will see it in the output and need to find out
>> for themselves what it means before they can construct their migration
>> plan - it's explained in the docs we point at*
>
> Somehow, it was not so obvious to me, and the referenced docs are also
> not very clear about the name selection process, (not to mention a
> bunch of unrelated information there you need to read through before
> arriving at the important bits).
Yes. the whole process of trying to predict "predictable names" is a
massive pain. And yes, we *could* have filled the Release Notes with
huge red-block-capital warnings - but the deprecation of
/etc/udev/rules.d/70-persistent-net.rules that all this was intended
to warn about (first announced in a udev NEWS.Debian file in mid-2015)
turned out to have been backed out again at the last minute! So we
were already navigating a fine line between the developers who insist
that the old system's unsupported and the users who consider this
unnecessary scaremongering.
And now the nearest thing anybody's written to a HOWTO is suffering
from linkrot, so we'll need to come up with a replacement.
>> There's an extra complication here that your order-of-priority list
>> doesn't account for.
>
> Indeed, a USB-to-Ethernet dongle lists both MAC and PATH names but
> uses the lower priority MAC name by default.
> So, my last note should probably be:
> "Warning: MAC names are normally preferred over PATH ones for USB
> network hardware."
Unfortunately, this takes us right back to what I went on to say:
>> The problem with giving too many details is that readers may assume
>> these are *all* the details they need to know, and for a topic like
>> this with its myriad corner-cases, I can't believe we're ever going to
>> be able to provide that One True Complete HOWTO Guide.
>
> We can provide the most important information, (which hopefully I was
> able to distill with your help), and clearly warn about potential
> corner cases that will require a whole lot more reading and
> understanding if one wants to be on the safe side while performing the
> migration on a remote system.
I don't know if we can even afford to claim we've got a complete list
of corner-cases; I'd never heard of ID_NET_NAME_FROM_DATABASE, and we
haven't even touched the question of VMs.
> The problem is that the current instructions miss important details,
> and do not clearly warn about potential pitfalls.
So what did actually go wrong on your systems? You disabled
/etc/udev/rules.d/70-persistent-net.rules and they started using an
unpredictable slot-based "predictable name"?
>> This should give enough information to devise a migration plan. (If
>> - the udevadm output includes an "onboard" name, that takes priority;
>> + the udevadm output includes an "onboard" name or a "slot" name, that takes
>> priority;
>> MAC-based names are normally treated as a fallback, but may be needed
>> for USB network hardware.)
>>
>> But just how common are slot names? Is it in fact possible for a NIC
>> to have both an onboard name and a slot name?
>
> Since I do not know the answers I included the full prioritized list
> into my suggestion.
> Your proposed change would be enough in my case but I still think it
> is not visible enough as a warning.
It may be that what we most need is a clear statement that the
information here is *not complete*, and that people devising a
migration plan for a remote system need to read a proper detailed
HOWTO. Unfortunately, the nearest thing to an official guide is bad
and getting worse.
If I start trying to assemble a Debian Wiki page that the Release
Notes could point at, can you help? (Criticising it counts as help.)
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
