Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)
On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:
>> https://www.debian.org/releases///buster/s390x/release-notes/ch-informa=
> tion.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 screwed up and didn't realize, but that guy in Philly running Debian
on an IBM mainframe feels less left out maybe.
> I'm skeptical as to whether this is (still/currently) accurate.
Me too, after speaking briefly over the wire with Greg Wooledge.
> 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.
That's the spirit.
> /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.
Well, in the bug thread 919390 referenced below Martin Pitt does say
We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.
"in the latest version of systemd."
> 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.
That appears to be correct from a rapid perusal of the referenced
bug.
> 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.
Not even that, it seems (no longer affects 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.
I was going to upgrade to Buster a couple of weeks ahead of time, taking
the bull by the horns for once rather than procrastinating, which is my
ultimate tendency in life, and began reading the release notes (for the
wrong architecture, but, come on, nobody's perfect). It never crossed my
mind to doubt the accuracy of those notes until yesterday when Greg
piped up.
Maybe we should file a bug report against the release notes.
Reply to: