[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

On 2019-07-01 at 03:47, Curt wrote:

> Another, less serious, gotcha for those inveterate upgraders and
> newbies who don't read the release notes is that 
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid 
> mechanism for defining device names. This mechanism (automagically) 
> permitted users upgrading from Wheezy to Stretch (where the
> old-style names were deprecated) to continue using their obsolete,
> legacy interface names (eth0, anyone?).
> Me, I migrated to the new-fangled denominations as per the
> instructions at the link below to obviate the eventual loss of
> network connectivity, which is a bummer when you don't what you're
> doing and all the help available is at the other end of the severed
> wire.
> https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

(Any particular reason you linked to the s390x version of the release
notes? It seems to match e.g. the amd64 one for this purpose, so it
shouldn't make a difference, it's just a little unexpected.)

I'm skeptical as to whether this is (still/currently) accurate.

After reading the conversation in the ensuing subthread about cases
where the old-style names as defined in that file were still picked up
and used without troubles after a buster upgrade, I went looking for
more information.

/usr/share/doc/udev/README.Debian.gz has a section on the subject of
migration from the old naming scheme to the new one. Although it does
not seem to state as much explicitly, from that section (and other parts
of the file related to interface names), it appears as if this detail
may apply only to machines running systemd. In particular, the file's
multiple references to /etc/systemd/network/99-default.link seem as if
they may be relevant.

Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces' found
a reference to bug 919390, which seems to be about someone reporting
this behavior as a bug. That bug has been closed as "fixed upstream",
and that closure is what I found in the changelog. The patch which fixes
the bug was committed as being a revert of an earlier change. That
commit happened in January, and the package was released to unstable on
January 27th; it's long since made it to testing, i.e., buster.

It's still possible that there's other activity which affects all of
this and which I've missed (related to the non-udev systemd packages,
most likely), but at a glance, it looks as if the release notes and the
README alike may be inaccurate / out of date. Even if they aren't, it
looks as if they may be incomplete, by describing only the situation as
it affects machines with systemd.

Although I don't run systemd on this machine, and my second system which
used to have it (and I think still does) doesn't use it as the init
system, I manage a very minor server at work which does use it as init
system. In the event that we actually upgrade that server rather than
migrating its service to another machine, this change may wind up being
relevant to me; I'll want to keep it in mind.

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: