On Sat, 6 Apr 2019 21:40:52 +0100 Justin B Rye <justin.byam....@gmail.com> wrote:
> Karl O. Pinc wrote: > > A) Added text in "what's new" section explaining the (sorta-new) > > interface naming scheme and why it's good. Mention there > > I hope you're aware that the last release-notes announced in > > https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names > that "predictable"-style nicnames were already the default for > Stretch unless overridden in /etc/udev/rules.d/. And they > referenced the udev README that says this mechanism won't be > supported in Buster Nope. I'm not aware. I don't tend to read the "what's new", just the upgrade instructions and the section that says what I need to do to get ready for the next release. Or maybe I did read it and that's what led me to file this bug report, because there's no mention in the "what needs to happen for the next release" section. I do know that the new names are the default for new stretch installs. But stretch systems upgraded from jessie retain old names. Upgrading them to buster without migrating names will break networking. This is what needs to be addressed. Anyway, it is new in buster, and pretty major for anyone with old interface names, that new names are required. _Somewhere_ it should say what the rationale is, and how to parse the new names. Especially for those who manage remote systems, for whom maintaining connectivity throughout the upgrade process is critical. Sorry for running-on. I guess I'm not sure what your point is. Is there something specific in the patch of whats-new.dbk or upgrading.dbk that you'd like changed? > > C) Actual upgrade instructions. This is in-progress. > > > > There are really 2 paths for manual migration of > > interface names: one for when you have console/physical > > access and another when you don't. In the first case, > > you can try the new names, see what name you get, and > > migrate /etc/. Without console access you need to > > calculate the new interface name, migrate, and hope > > you got the right name after reboot. To calculate > > the right interface name you need additional background > > information. I've whacked up a teeny script, with > > no dependencies, to compute the common case. But it > > does require the pciid as input, and I suggest installing > > pciutils to get lspci to find pciids. > > Whether I'm accessing it physically or via ssh, can't I use something > like: > udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET > or > udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null > ...? That worked for me even on Jessie machine. I don't know. I just tried both the above on a jessie box running on a VM and it did not show me an ID_NET_NAME_PATH, which I presume is what shows me the new-style interface name? I don't have a stretch box with old-style names to test on. Regards, Karl <k...@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
