Re: How to avoid systemd/udev unpredictable NIC names
On Tue 31 Aug 2021 at 01:11:33 (+0200), Steve Keller wrote:
> Greg Wooledge <greg@wooledge.org> writes:
> > On Mon, Aug 30, 2021 at 04:41:55PM -0400, Dan Ritter wrote:
> > > Steve Keller wrote:
> > > > I plan to upgrade a server from Debian stretch to buster. Having read
> > > > the release notes I wonder what's the best way to avoid the new scheme
> > > > of unpredictable network interface names.
> > >
> > > In /etc/default/grub, assuming that you are booting with grub,
> > >
> > > GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
> > >
> > > The "quiet" is not necessary and is a different feature.
> >
> > This gives unpredictable results if the system has more than one
> > ethernet interface, or more than one wireless interface.
> >
> > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
>
> OK, several people suggested the kernel command-line option
> net.ifnames=0. Since I almost never change hardware configurations
> this is probably OK even with my two NICs, one on the mainboard, the
> second is a PCI card. If the kernel should really change the
> enumeration of the cards in some future, I will do something about
> that.
By which time, of course, the consequences of this mistake might well
have already happened, eg, juggling your internal network, dmz, and
external internet.
But it's your choice, of course.
> In buster I still need to disable the
> /etc/udev/rules.d/70-persistent-net.rule file since the kernel cmdline
> option doesn't deactivate this. AFAIK, the kernel cmdline option only
> ends up in the environment of process 1, i.e. systemd. Will systemd
> communicate this to udev in a future Debian release or how is that
> supposed to work. The wiki says, the plan for buster was to not
> support this .rules file.
>
> My other option would be customized names using systemd.link files.
> While I prefer eth<n> I would then probably use en<0>, since the wiki
> recommends not using eth<n>. I still don't understand, why eth<n> in
> a systemd.link file would be a problem, since in the udev .rules this
> has worked for years.
It's rather futile as the result is two races instead of one. The
kernel happens to find first the NIC that you want named "eth1",
and so it enumerates it as eth0. (That's the first race.)
Now starts a second race:
. when the kernel finds the other NIC, it wants to enumerate it as eth1,
but meanwhile:
. your customisation immediately wants to rename the first (eth0) NIC
as eth1.
Cheers,
David.
Reply to: