Re: networking.service fails
On Mon, Apr 04, 2022 at 02:38:39AM +0200, Dmitry Katsubo wrote:
> I've exercised several directions to solve the issue, however I've failed. Would be great if somebody can share his idea. After upgrading from Debian buster to bullseye I still have the same issue:
Upgrading from one release to another can easily trigger changes in
interface names, especially if you were previously relying on a deprecated
scheme.
> Apr 4 00:37:28 debian ifup[1287]: ifup: unknown interface eth0
> Apr 4 00:37:28 debian ifup[1287]: ifup: unknown interface eth1
> Apr 4 00:37:28 debian kernel: [ 1.049742] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
> Apr 4 00:37:28 debian kernel: [ 1.066552] r8169 0000:02:00.0 eth0: RTL8168g/8111g, 00:17:e8:92:b7:77, XID 4c0, IRQ 30
> Apr 4 00:37:28 debian kernel: [ 1.066553] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
> Apr 4 00:37:28 debian kernel: [ 1.066581] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
> Apr 4 00:37:28 debian kernel: [ 10.804450] r8169 0000:02:00.0 eth0: renamed from enp2s0
> Apr 4 00:37:28 debian kernel: [ 10.825386] r8169 0000:03:00.0 eth1: renamed from enp3s0
So... you've got some wild stuff going on here.
You have two interfaces. One of them was named enp2s0 and then got
renamed to eth0, which is usually the opposite direction from what one
expects.
The other was named enp3s0 and then got renamed to eth1. Which, again,
is the opposite of what one expects.
Normally, the kernel assigns the name eth0 temporarily to the first
interface that it finds, and then renames it to some "predictable"
name according to obtuse schemes. In your case, I'm imagining that
your interface started as eth0, then got renamed to enp2s0, then renamed
a second time back to eth0.
At the time when ifup tried to run, the interface was named enp2s0, but
your configuration tried to address it by the name eth0.
So, there are many questions here.
How many different interface configuration schemes are you using here?
Which ones are they?
a) Do you set the net.ifnames kernel parameter? If so, what value are
you setting it to?
b) Do you have any non-loopback interfaces configured in the
/etc/network/interfaces file? If so, which ones, and how are
they configured?
c) Do you have an /etc/udev/rules.d/70-persistent-net.rules file? Note
that this file was deprecated in buster. If it continued to work in
buster, that was just a happy accident. If it stopped working in
bullseye, that is not a surprise.
d) Do you have any /etc/systemd/network/*.link files? If so, what's in
them?
e) Do you have network-manager installed? If so, I don't know what
followup questions to ask about it, because I don't use it.
f) Do you have any /etc/systemd/network/*.network files? If so, what's
in those?
g) Do you have any *other* interface configuration schemes in play that
I don't know about?
Once you've identified all of the moving parts in this puzzle, then you
can figure out which ones you actually want to keep, and which ones
you should rip out.
For comparison, my system (Debian 11 bullseye) has one interface. I
configure its name using a file in /etc/systemd/network/ which sets
the name to lan0. Then I configure its in /etc/network/interfaces
using that name.
Some relevant log file lines:
Mar 26 08:01:54 unicorn kernel: [ 1.042579] r8169 0000:02:00.0 eth0: RTL8168gu/8111gu, 18:60:24:77:5c:ec, XID 509, IRQ 127
[...]
Mar 26 08:01:54 unicorn kernel: [ 1.057022] r8169 0000:02:00.0 lan0: renamed from eth0
[...]
Mar 26 08:01:59 unicorn kernel: [ 20.372606] r8169 0000:02:00.0 lan0: Link is Up - 100Mbps/Full - flow control rx/tx
That's just one of many possible ways to configure network interfaces.
You might be using a different scheme. The important thing is that
you pick *one* scheme and set it up correctly. If you've got two or
more competing schemes in play, and they're undoing each other's work,
that's not desirable.
Reply to: