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