bookworm and network connections

[D. R. Evans]

I just upgraded my main server to bookworm, having successfully, over the
course of the past couple of months, methodically upgraded my other machines
with only minor issues.

Unfortunately, the upgrade of the server, the most important of my machines,
has not been smooth at all, even though no important errors appeared during
the upgrade process.

So right now the thing I want to fix is networking (which of course worked
fine in the last few releases of debian, until now).

The machine has two ethernet ports, which used to be eth0 and eth1 in the old
days, but are now magically called "Wired connection enp11s0(eth0)" and "Wired
connection enp12s0(eth1)".

When I booted the machine after the upgrade, no networking was working at all,
on either interface, even though:

----

zserver# nmcli networking connectivity
full
zserver#

----

which was definitely a lie, as nothing was successfully going in or out of the
machine.

Looking in more detail:

----

[Z:~] nmcli
enp12s0: connected to Wired connection enp11s0(eth0)
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500
ip4 default
inet4 209.97.232.18/24
route4 209.97.232.0/24 metric 100
route4 default via 209.97.232.1 metric 100
inet6 fe80::e0c1:20a:c535:873c/64
route6 fe80::/64 metric 1024

lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

enp11s0: disconnected
"Intel I210"
1 connection available
ethernet (igb), D8:50:E6:C2:76:02, hw, mtu 1500

enp13s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:04, hw, mtu 1500

enp14s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:05, hw, mtu 1500

DNS configuration:
servers: 127.0.0.1 209.97.224.2 209.97.224.3
interface: enp12s0

----

Somehow, it had got into a state where enp12s0 was connected to enp11s0
(whatever that means), with the result that nothing worked.

So, after a bit of messing around with an increasing sense of desperation, I
discovered that:

----

[Z:~] sudo nmcli connection down "Wired connection enp11s0(eth0)"
Connection 'Wired connection enp11s0(eth0)' successfully deactivated (D-Bus
active path: /org/freedesktop/NetworkManager/ActiveConnection/2)

[Z:~] sudo nmcli connection up "Wired connection enp11s0(eth0)"
Connection successfully activated (D-Bus active path:
/org/freedesktop/NetworkManager/ActiveConnection/4)

----

resulted in:

----

[Z:~] nmcli
enp11s0: connected to Wired connection enp11s0(eth0)
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:02, hw, mtu 1500
ip4 default
inet4 209.97.232.18/24
route4 209.97.232.0/24 metric 101
route4 default via 209.97.232.1 metric 101
inet6 fe80::1ae1:dfcf:be36:f72f/64
route6 fe80::/64 metric 1024

enp12s0: connected to Wired connection enp12s0(eth1)
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500
inet4 192.168.0.1/24
route4 192.168.0.0/24 metric 100
inet6 fe80::d30e:86f6:ca86:8986/64
route6 fe80::/64 metric 1024

lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

enp13s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:04, hw, mtu 1500

enp14s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:05, hw, mtu 1500

DNS configuration:
servers: 127.0.0.1 209.97.224.2 209.97.224.3
interface: enp11s0

----

and indeed, everything was now working. Which was good, because I was running
out of ideas, and had no way to reach the Internet to look for more help.

Well, great, sort-of, except that every time I reboot I have to manually issue
the two above nmcli commands to take down and bring back up enp11s.

I tried putting them in my rc.local file, but that had no effect (for reasons
that I don't understand; I was sure that that would paper over the problem).

So how do I fix this so that the networking is configured to work correctly
during the boot sequence, as it has always done before?

(I suppose it has to be said explicitly: I did not change any configuration
files ... indeed, these days I don't even know where the files are that
control the network devices.)

All the other machines that I have upgraded to bookworm have only a single
ethernet port, which may be why I have not seen this issue after any other
upgrade.

Doc

--
Web: http://enginehousebooks.com/drevans

[Michael Kjörling]

On 1 Sep 2023 14:02 -0600, from doc....@gmail.com (D. R. Evans):

> Well, great, sort-of, except that every time I reboot I have to manually
> issue the two above nmcli commands to take down and bring back up enp11s.
>
> I tried putting them in my rc.local file, but that had no effect (for
> reasons that I don't understand; I was sure that that would paper over the
> problem).

Well, as you note, it's not a fix. Still, if a workaround gets you
closer to where you want to be...

I don't think /etc/rc.local is executed by default on modern Debian
systems. Have you checked to make sure that rc-local.service is
enabled and actually gets started during boot? Is there anything
relevant in the logs for that? Is /etc/rc.local set as executable?

--
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[Greg Wooledge]

On Fri, Sep 01, 2023 at 08:32:40PM +0000, Michael Kjörling wrote:
> I don't think /etc/rc.local is executed by default on modern Debian
> systems. Have you checked to make sure that rc-local.service is
> enabled and actually gets started during boot? Is there anything
> relevant in the logs for that? Is /etc/rc.local set as executable?

The rc-local.service is enabled by default. It will execute /etc/rc.local
if it exists and is executable.

The Debian installer used to create a stub /etc/rc.local file which had
a correct shell script shebang, and the necessary permissions. This is
longer created during installation, so the user would need to create
it themselves, if they want to have it. They'd also have to know enough
to put a correct shebang on it, and to do chmod +x. That's not a huge
barrier to entry, but it's just enough to confuse some people.

Double-checking "systemctl status rc-local.service" certainly wouldn't
hurt, just to make sure everything's working as desired.

[Michel Verdier]

On 2023-09-01, D. R. Evans wrote:

> The machine has two ethernet ports, which used to be eth0 and eth1 in the old
> days, but are now magically called "Wired connection enp11s0(eth0)" and "Wired
> connection enp12s0(eth1)".

If you want old names put in /etc/default/grub

GRUB_CMDLINE_LINUX="net.ifnames=0"

(add other parameters if you have some)
and do update-grub

> zserver# nmcli networking connectivity
> full

network manager is good for changing networks. For a server the network
must not change normally. So you could put configuration in
/etc/network/interfaces.d/ with something like :

auto enp11s0
iface enp11s0 inet static
mtu 1500
metric 101
address 209.97.232.18/24
netmask 255.255.255.0
gateway 209.97.232.1

auto enp12s0
iface enp12s0 inet static
mtu 1500
metric 100
address 192.168.0.1/24
netmask 255.255.0.0

auto lo
iface lo inet loopback

I you want IPv6 add :

iface enp11s0 inet6 auto
iface enp12s0 inet6 auto

Once it works you can then remove network manager

[The Wanderer]

On 2023-09-01 at 16:50, Greg Wooledge wrote:

> On Fri, Sep 01, 2023 at 08:32:40PM +0000, Michael Kjörling wrote:
>
>> I don't think /etc/rc.local is executed by default on modern Debian
>> systems. Have you checked to make sure that rc-local.service is
>> enabled and actually gets started during boot? Is there anything
>> relevant in the logs for that? Is /etc/rc.local set as executable?
>
> The rc-local.service is enabled by default. It will execute /etc/rc.local
> if it exists and is executable.
>
> The Debian installer used to create a stub /etc/rc.local file which had
> a correct shell script shebang, and the necessary permissions. This is
> longer created during installation, so the user would need to create
> it themselves, if they want to have it. They'd also have to know enough
> to put a correct shebang on it, and to do chmod +x. That's not a huge
> barrier to entry, but it's just enough to confuse some people.

It's actually still available, although I expect you're right that in a
default configuration it won't be installed during Debian installation:

$ dlocate /etc/rc.local
initscripts: /etc/rc.local
$ apt-cache policy initscripts
initscripts:
Installed: 3.07-1
Candidate: 3.07-1
Version table:
*** 3.07-1 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
900 http://ftp.us.debian.org/debian testing/main i386 Packages
100 /var/lib/dpkg/status
$ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.

if test -d /etc/boot.d ; then
run-parts /etc/boot.d
fi

This is in an environment that's running sysvinit, not systemd;
'sysvinit-core' currently depends on the 'initscripts' package. I'm not
in a position to tell whether there would be issues trying to install
'initscripts' in a systemd environment, but I just offhand wouldn't
particularly expect there to be.

--
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

[D. R. Evans]

Thank you for your thoughts...

As people are addressing the rc.local issue (I now realise that I shouldn't
have mentioned it :-) )... I just checked, and:

1. rc.local is being executed;
2. it is executing the nmcli commands;
3. the commands are successful.

But it remains true that when the boot is fully complete, the networking is
still hosed in the way that I described. So, apparently, putting commands in
rc.local doesn't provide the workaround that I expected. I think that we
should concentrate on the underlying networking issue so that it comes up
properly rather than being derailed by trying to fix the networking after the
fact.

[[ I speculate wildly that systemd or something doesn't complete configuring
the network until after rc.local has finished processing (I know that rc.local
executes late in the boot process, but I don't think that that means that
everything else has *finished* executing when rc.local runs). I may easily be
wrong, but really I don't think I care. ]]

I just want to get the networking to come up properly :-)

I don't understand modern systemd-controlled networking initiation well enough
to know where to look for something that the upgrade might have clobbered, nor
how I might go about fixing it.

[Greg Wooledge]

On Fri, Sep 01, 2023 at 03:18:47PM -0600, D. R. Evans wrote:
> [[ I speculate wildly that systemd or something doesn't complete configuring
> the network until after rc.local has finished processing (I know that
> rc.local executes late in the boot process, but I don't think that that
> means that everything else has *finished* executing when rc.local runs). I
> may easily be wrong, but really I don't think I care. ]]

On Debian, there's an override file:


unicorn:~$ cat /usr/lib/systemd/system/rc-local.service.d/debian.conf
[Unit]
# not specified by LSB, but has been behaving that way in Debian under SysV
# init and upstart
After=network-online.target

# Often contains status messages which users expect to see on the console
# during boot
[Service]
StandardOutput=journal+console
StandardError=journal+console


The "After=network-online.target" line is supposed to ensure that
rc-local.service doesn't run until the network configuration has been
completed. However, the definition of "completed" here can be murky.
In particular, when using /etc/network/interfaces, only interfaces that
are marked as "auto" need to be up, to satisfy this criterion. An
interface that's only "allow-hotplug" isn't required to be up.

Also, since the issue here involves network configuration, it would
seem counterintuitive to expect it to be done in a service that runs
*after* the network is supposed to be up.

[D. R. Evans]

Greg Wooledge wrote on 9/1/23 15:38:

> In particular, when using /etc/network/interfaces, only interfaces that
> are marked as "auto" need to be up, to satisfy this criterion. An

I don't think that debian has used used /etc/network/interfaces for a while,
at least not by default. Certainly there's nothing useful there on the machine
that I just upgraded and whose networking is failing to configure itself
correctly.

Network Manager -- I think -- uses some completely different mechanism for
managing networking (although I have no idea what that mechanism is.)

[Andy Smith]

Hello,

On Fri, Sep 01, 2023 at 04:16:46PM -0600, D. R. Evans wrote:
> I don't think that debian has used used /etc/network/interfaces for a while,
> at least not by default.

All of my Debian servers (and desktops) have an
/etc/network/interfaces file and ifupdown installed. It depends upon
choices made in the installer as to whether ifupdown is installed at
all.

> Network Manager -- I think -- uses some completely different mechanism for
> managing networking (although I have no idea what that mechanism is.)

Yes, it is ifupdown which uses that file. NetworkManager is
configured another way. Uusally NetworkManager will ignore
interfaces which are mentioned in /etc/network/interfaces, so if you
have ifupdown installed and put stuff in /etc/network/interfaces, it
should be ifupdown (and only that) that configures them.

As others have mentioned, NetworkManager is not usually considered a
good choice for servers with a static networking environment.

You need to decide whether you are going to persevere with
configuring NetworkManager, or switch to something else (generally
ifupdown or systemd-networkd).

I don't know enough about NetworkManager to advise you how to get
out of the situation you are in. I only use it on laptops and
generally don't touch it, there.

Your situation appears to have been triggered by the renaming of
your network interfaces (which was warned about in the release
notes). You should decide whether to revert that (it's already been
posted how to do that, also see the wiki link below), or go with it.

Both of these are worth reading:

https://wiki.debian.org/NetworkConfiguration
https://wiki.debian.org/NetworkInterfaceNames

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Greg Wooledge]

Debian *absolutely* uses /etc/network/interfaces. By default, in a
Standard installation. But as you noted, it's optional. Debian *also*
allows the use of Network Manager, systemd-networkd, and probably several
other systems for configuring one's network(s).

I haven't installed Debian 12 yet (upgraded to it, but haven't installed
it), but I did a Debian 11 install yesterday. And I can assure you,
that system uses /etc/network/interfaces just like every other Debian
system I've ever run. I used a Standard install, then booted it to
confirm that all the necessary firmware was present, and then installed
KDE (among other things). I don't know whether N-M is installed on
that system -- I didn't check -- but it doesn't matter, because the
machine's sole ethernet interface is configured in /e/n/i and therefore
N-M would skip it.

Returning to the previous topic, I have no idea how
After=network-online.target interacts with N-M. I have experience with
network-online.target vs. /e/n/i and its absurd "allow-hotplug" default
setting, but I don't use N-M so I don't know how that works.

[D. R. Evans]

Andy Smith wrote on 9/1/23 16:32:

> Your situation appears to have been triggered by the renaming of
> your network interfaces (which was warned about in the release

These weird names like "Wired connection enp11s0(eth0)" were names that the
debian installer came up with several OS versions ago (stretch, perhaps?).

Anyway, they haven't changed since bullseye, when everything worked (i.e.,
early this morning, before I ran the upgrade :-( ).

>
> Both of these are worth reading:
>
> https://wiki.debian.org/NetworkConfiguration
> https://wiki.debian.org/NetworkInterfaceNames

I'll take a look at those.

[D. R. Evans]

Michel Verdier wrote on 9/1/23 15:06:

>
> If you want old names put in /etc/default/grub
>
> GRUB_CMDLINE_LINUX="net.ifnames=0"
>

Nice to know, but I'll stay with the new names, I think.

> network manager is good for changing networks. For a server the network
> must not change normally. So you could put configuration in
> /etc/network/interfaces.d/ with something like :
>
> auto enp11s0
> iface enp11s0 inet static
> mtu 1500
> metric 101
> address 209.97.232.18/24
> netmask 255.255.255.0
> gateway 209.97.232.1
>
> auto enp12s0
> iface enp12s0 inet static
> mtu 1500
> metric 100
> address 192.168.0.1/24
> netmask 255.255.0.0
>

When I'm feeling less tired and prone to making a mistake, I'll do this.

The old method seems so much simpler, so I'd be happy to go back to it. It
seems that enough people are using it that it doesn't seem likely that it'll
go away anytime soon.

When I installed debian on this computer -- quite a few years ago -- I'm
pretty sure it just went off and installed all the Network Manager stuff
without asking. And, to be honest, it's worked fine for the last several
years. I can't imagine why its so messed up now. I (obviously) didn't change
anything related to Network Manager myself; the upgrade is entirely
responsible for its now-non-functioning state.

> I you want IPv6 add :
>
> iface enp11s0 inet6 auto
> iface enp12s0 inet6 auto
>

I would love IPv6, but my ISP doesn't support it, and has no plans to do so,
so for now I'm stuck in IPv4 land.

> Once it works you can then remove network manager
>

That sounds like something to celebrate. I'll try to get time to work on all
this over the weekend, and let everyone know how it turns out.

Thanks to everyone for their suggestions.

[David Wright]

On Fri 01 Sep 2023 at 17:38:48 (-0400), Greg Wooledge wrote:
> On Fri, Sep 01, 2023 at 03:18:47PM -0600, D. R. Evans wrote:
> > [[ I speculate wildly that systemd or something doesn't complete configuring
> > the network until after rc.local has finished processing (I know that
> > rc.local executes late in the boot process, but I don't think that that
> > means that everything else has *finished* executing when rc.local runs). I
> > may easily be wrong, but really I don't think I care. ]]
>
> On Debian, there's an override file:
>
> unicorn:~$ cat /usr/lib/systemd/system/rc-local.service.d/debian.conf
> [Unit]
> # not specified by LSB, but has been behaving that way in Debian under SysV
> # init and upstart
> After=network-online.target
>
> # Often contains status messages which users expect to see on the console
> # during boot
> [Service]
> StandardOutput=journal+console
> StandardError=journal+console
>
>
> The "After=network-online.target" line is supposed to ensure that
> rc-local.service doesn't run until the network configuration has been
> completed. However, the definition of "completed" here can be murky.

> In particular, when using /etc/network/interfaces, only interfaces that
> are marked as "auto" need to be up, to satisfy this criterion. An

> interface that's only "allow-hotplug" isn't required to be up.
>
> Also, since the issue here involves network configuration, it would
> seem counterintuitive to expect it to be done in a service that runs
> *after* the network is supposed to be up.

I don't see that the OP is doing anything complicated that requires
rc.local to run at all. They just need to distinguish between the two
interfaces, and then configure them in a conventional manner. A .link
file and the ifupdown package should be able to cope with that.
(I haven't used the buster-onwards interface matching/renaming
facility myself, which could replace using the .link file.)

On Fri 01 Sep 2023 at 18:33:51 (-0400), Greg Wooledge wrote:
> On Fri, Sep 01, 2023 at 04:16:46PM -0600, D. R. Evans wrote:
> > Greg Wooledge wrote on 9/1/23 15:38:
> >
> > > In particular, when using /etc/network/interfaces, only interfaces that
> > > are marked as "auto" need to be up, to satisfy this criterion. An
> >
> > I don't think that debian has used used /etc/network/interfaces for a while,
> > at least not by default. Certainly there's nothing useful there on the
> > machine that I just upgraded and whose networking is failing to configure
> > itself correctly.
> >
> > Network Manager -- I think -- uses some completely different mechanism for
> > managing networking (although I have no idea what that mechanism is.)
>
> Debian *absolutely* uses /etc/network/interfaces. By default, in a
> Standard installation. But as you noted, it's optional. Debian *also*
> allows the use of Network Manager, systemd-networkd, and probably several
> other systems for configuring one's network(s).
>
> I haven't installed Debian 12 yet (upgraded to it, but haven't installed
> it), but I did a Debian 11 install yesterday. And I can assure you,
> that system uses /etc/network/interfaces just like every other Debian
> system I've ever run. I used a Standard install, then booted it to
> confirm that all the necessary firmware was present, and then installed
> KDE (among other things). I don't know whether N-M is installed on
> that system -- I didn't check -- but it doesn't matter, because the
> machine's sole ethernet interface is configured in /e/n/i and therefore
> N-M would skip it.

Installing bookworm (standard packages, no DE) installed and
configured ifupdown as per usual here.

> Returning to the previous topic, I have no idea how
> After=network-online.target interacts with N-M. I have experience with
> network-online.target vs. /e/n/i and its absurd "allow-hotplug" default
> setting, but I don't use N-M so I don't know how that works.

I know you have a low opinion of allow-hotplug, but I can't see that
auto/allow-auto is necessarily better for the naive user that doesn't
install a DE for whatever reason.

AIUI auto gives you a one-shot attempt to start the network at boot
time, and if that fails for any reason (eg USB not yet plugged in/
not detected/hardblocked on/etc), you get a long timeout before the
login prompt, and may have to reboot to get it to attempt again.

OTOH allow-hotplug gets you to a login prompt as normal, without the
network being up, and then rectifying the problem makes ifupdown/udev
automatically have another go.

Cheers,
David.

[Greg Wooledge]

On Fri, Sep 01, 2023 at 08:40:43PM -0500, David Wright wrote:
> I know you have a low opinion of allow-hotplug, but I can't see that
> auto/allow-auto is necessarily better for the naive user that doesn't
> install a DE for whatever reason.
>
> AIUI auto gives you a one-shot attempt to start the network at boot
> time, and if that fails for any reason (eg USB not yet plugged in/
> not detected/hardblocked on/etc), you get a long timeout before the
> login prompt, and may have to reboot to get it to attempt again.
>
> OTOH allow-hotplug gets you to a login prompt as normal, without the
> network being up, and then rectifying the problem makes ifupdown/udev
> automatically have another go.

It depends on the hardware, and how the system is going to be used.
A built-in ethernet interface SHOULD NOT be configured as "allow-hotplug".
It should be "auto". I'd argue that the same applies to a PCI card or
other non-built-in but internal device. If you have to take the machine
apart to remove the device, it's "auto".

allow-hotplug is intended for things like USB ethernet interfaces, as
you mention. They're literally hot-pluggable, and may not be present
when the system is booted. If you're dealing with one of those, then
by all means, use allow-hotplug for it. That's what it's for.

My gripe is that the installer has (traditionally?) used allow-hotplug for
ALL ethernet interfaces, including the built-in interfaces on a server.
This causes massive problems with the ordering of service initializations
at boot. It took me a *long* time and a lot of digging to figure out why
things were breaking, so I try to pass that knowledge along for others.

[D. R. Evans]

David Wright wrote on 9/1/23 19:40:

> I don't see that the OP is doing anything complicated that requires
> rc.local to run at all. They just need to distinguish between the two

Correct. I was simply trying to workaround the problem by putting commands
into rc.local that are known to work when I type them manually.

I wish I had never mentioned rc.local. It seems to have taken over the thread,
whereas it's not the problem that I'm trying to fix at all :-(

Regarding the whole "Network Manager versus old-style" thing, I would gladly
have done it all old style, except that when I first installed debian on the
system, it went the Network Manager route. And because that all worked until
today's upgrade (which was, I think, the third upgrade upgrade of debian
stable on the machine; so it worked correctly for a lustrum or so), I didn't
pay much attention to it apart from being mildly annoyed that it looked a lot
more complicated than old-style network management.

The real problem remains, per the original post, that Network Manager isn't
configuring the interfaces properly and seems to be sort-of setting one
interface to be the same as the other, with the result that neither of them
work. I'm going to try switching to old-style when I feel confident that I
have enough high-quality time to make the switch, and I expect that to work.

It would be nice to really fix the Network Manager misconfiguration; but it
seems that the expertise here is all with old-style. Which is fine. I'm happy
to go back to old-style.

I probably need to file some sort of bug report against the upgrade, but I'd
like to get a better feel for how the misconfiguration is happening before I
do that.

[Michael Kjörling]

On 1 Sep 2023 21:41 -0600, from doc....@gmail.com (D. R. Evans):

> It would be nice to really fix the Network Manager misconfiguration; but it
> seems that the expertise here is all with old-style. Which is fine. I'm
> happy to go back to old-style.

You might want to poke around a little among the files in
/etc/NetworkManager, particularly /e/NM/system-connections. That's
what NetworkManager _should_ be using to set up the interfaces. See if
there's something there to explain the two seemingly being intertwined.

You might already have done this, of course, and if so, I apologize
for pointing out something you've already tried.

[Brian]

The netmask line is unneeded. See interfaces(5).

THe loopback stanza is also unneeded. See the changelog for ifupdown.

--
Brian.

[Timothy M Butterworth]

On Sat, Sep 2, 2023 at 6:34 AM Brian <ad...@cityscape.co.uk> wrote:

On Fri 01 Sep 2023 at 16:56:42 -0600, D. R. Evans wrote:

> Michel Verdier wrote on 9/1/23 15:06:
>
> >
> > If you want old names put in /etc/default/grub
> >
> > GRUB_CMDLINE_LINUX="net.ifnames=0"
> >
>
> Nice to know, but I'll stay with the new names, I think.
>
> > network manager is good for changing networks. For a server the network
> > must not change normally. So you could put configuration in
> > /etc/network/interfaces.d/ with something like :
> >
> > auto enp11s0
> > iface enp11s0 inet static
> >     mtu 1500
> >     metric 101
> >     address 209.97.232.18/24
> >     netmask 255.255.255.0
> >     gateway 209.97.232.1
> >
> > auto enp12s0
> > iface enp12s0 inet static
> >     mtu 1500
> >     metric 100
> >     address 192.168.0.1/24
> >     netmask 255.255.0.0
> >

The netmask is wrong, it should be 255.255.255.0.

 

>
> When I'm feeling less tired and prone to making a mistake, I'll do this.
>
> The old method seems so much simpler, so I'd be happy to go back to it. It
> seems that enough people are using it that it doesn't seem likely that it'll
> go away anytime soon.

The netmask line is unneeded. See interfaces(5).

THe loopback stanza is also unneeded. See the changelog for ifupdown.

--
Brian.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[Brian]

On Fri 01 Sep 2023 at 22:32:00 +0000, Andy Smith wrote:

> Hello,
>
> On Fri, Sep 01, 2023 at 04:16:46PM -0600, D. R. Evans wrote:
> > I don't think that debian has used used /etc/network/interfaces for a while,
> > at least not by default.
>
> All of my Debian servers (and desktops) have an
> /etc/network/interfaces file and ifupdown installed. It depends upon
> choices made in the installer as to whether ifupdown is installed at
> all.

Installation over ethernet, no DE - ifupdown provided.
Installation over ethernet or wireless with a DE - network-manager provided.
Installation over wireless without a DE - nothing provided, that is, no networking.

--
Brian.

[Brian]

On Fri 01 Sep 2023 at 18:33:51 -0400, Greg Wooledge wrote:

> On Fri, Sep 01, 2023 at 04:16:46PM -0600, D. R. Evans wrote:
> > Greg Wooledge wrote on 9/1/23 15:38:
> >
> > > In particular, when using /etc/network/interfaces, only interfaces that
> > > are marked as "auto" need to be up, to satisfy this criterion. An
> >
> > I don't think that debian has used used /etc/network/interfaces for a while,
> > at least not by default. Certainly there's nothing useful there on the
> > machine that I just upgraded and whose networking is failing to configure
> > itself correctly.
> >
> > Network Manager -- I think -- uses some completely different mechanism for
> > managing networking (although I have no idea what that mechanism is.)
>
> Debian *absolutely* uses /etc/network/interfaces. By default, in a
> Standard installation. But as you noted, it's optional. Debian *also*
> allows the use of Network Manager, systemd-networkd, and probably several
> other systems for configuring one's network(s).

It's only optional in the sense that preseeding would determine the
outcomme. AFAIK, a user is not presented with a selectable opion with
a standard or expert installation.

--
Brian.

[Brian]

On Sat 02 Sep 2023 at 06:55:26 -0400, Timothy M Butterworth wrote:

> On Sat, Sep 2, 2023 at 6:34 AM Brian <ad...@cityscape.co.uk> wrote:

[...]

I did not write any of the text you quote.

--
Brian.

[Anssi Saari]

"D. R. Evans" <doc....@gmail.com> writes:

> I don't think that debian has used used /etc/network/interfaces for a
> while, at least not by default. Certainly there's nothing useful there
> on the machine that I just upgraded and whose networking is failing to
> configure itself correctly.

I used to think that too. In fact, I believe in some update last decade
my desktop system switched to something other than ifupdown, probably
systemd-networkd and the stuff in /etc/network/interfaces stopped
working.

But when I recently installed Debian (headless server) on a little pizza
box, I did end up with ifupdown running the network. So it's still the
default. The new system's network config is pretty simple and the couple
of little things beyond basic DHCP client I needed were easily handled by
ifupdown and the kernel itself so no reason to touch it.

[Brian]

On Sat 02 Sep 2023 at 13:09:45 +0100, Brad Rogers wrote:

> On Sat, 2 Sep 2023 12:08:37 +0100
> Brian <ad...@cityscape.co.uk> wrote:
>
> Hello Brian,

>
> >I did not write any of the text you quote.
>

> <pedant>
> You did, but it was not what Timothy was responding to.
> </pedant>
> What you wrote was quoted right at the bottom of the message, and
> irrelevant to Timothy's response.

Not pedantic at all; you are obviously correct in what you point out.
I should read more carefully. Thank you, Brad.

--
Brian.

[Greg Wooledge]

On Sat, Sep 02, 2023 at 01:09:45PM +0100, Brad Rogers wrote:
> Which begs the question:
> Why do some people respond to a message from person Y, when they're
> /actually/ dealing with something written by person X?

Because we've already deleted the message from person X, and didn't
notice the issue, or think of our response, until seeing the message
again, as cited by person Y.

[D. R. Evans]

Michael Kjörling wrote on 9/2/23 03:23:

>
> You might want to poke around a little among the files in
> /etc/NetworkManager, particularly /e/NM/system-connections. That's
> what NetworkManager _should_ be using to set up the interfaces. See if
> there's something there to explain the two seemingly being intertwined.
>
> You might already have done this, of course, and if so, I apologize
> for pointing out something you've already tried.
>

I hadn't before but I went and looked carefully this morning. Since I am
running ZFS, I can go back and look at those files before the upgrade and see
what, if anything has changed.

The only change was that there is now an "ntpsec" file in /e/NM/dispatcher.d.
Nothing changed anywhere else in or under /e/NM.

But see a long posting that I'm about to make about all this, with a subject
line containing the word "WORKAROUND".

[D. R. Evans]

Brian wrote on 9/2/23 04:51:

> Installation over ethernet, no DE - ifupdown provided.
> Installation over ethernet or wireless with a DE - network-manager provided.

Yep, that one's exactly what I experienced.

Although the machine is used more like a server than a desktop, it has DE
(KDE) to make it easier on the occasions I do need to do some work on the machine.

> Installation over wireless without a DE - nothing provided, that is, no networking.
>

[Brian]

On Sat 02 Sep 2023 at 13:42:38 -0600, D. R. Evans wrote:

> Brian wrote on 9/2/23 04:51:
>
> > Installation over ethernet, no DE - ifupdown provided.
> > Installation over ethernet or wireless with a DE - network-manager provided.
>
> Yep, that one's exactly what I experienced.
>
> Although the machine is used more like a server than a desktop, it has DE
> (KDE) to make it easier on the occasions I do need to do some work on the
> machine.
>
> > Installation over wireless without a DE - nothing provided, that is, no networking.

This server and desktiop distinction is so artificial. It's all software. Jobs are
undertaken, whether or not they are done by daemons or not. All my machines provide
server and so-called desktop functions.

Putting KDE on a machine intended as a mail server doesn't degrade it.

--
Brian.

[David Wright]

On Fri 01 Sep 2023 at 21:57:39 (-0400), Greg Wooledge wrote:
> On Fri, Sep 01, 2023 at 08:40:43PM -0500, David Wright wrote:
> > I know you have a low opinion of allow-hotplug, but I can't see that
> > auto/allow-auto is necessarily better for the naive user that doesn't
> > install a DE for whatever reason.
> >
> > AIUI auto gives you a one-shot attempt to start the network at boot
> > time, and if that fails for any reason (eg USB not yet plugged in/
> > not detected/hardblocked on/etc), you get a long timeout before the
> > login prompt, and may have to reboot to get it to attempt again.
> >
> > OTOH allow-hotplug gets you to a login prompt as normal, without the
> > network being up, and then rectifying the problem makes ifupdown/udev
> > automatically have another go.
>
> It depends on the hardware, and how the system is going to be used.
> A built-in ethernet interface SHOULD NOT be configured as "allow-hotplug".
> It should be "auto". I'd argue that the same applies to a PCI card or
> other non-built-in but internal device. If you have to take the machine
> apart to remove the device, it's "auto".
>
> allow-hotplug is intended for things like USB ethernet interfaces, as
> you mention. They're literally hot-pluggable, and may not be present
> when the system is booted. If you're dealing with one of those, then
> by all means, use allow-hotplug for it. That's what it's for.

I think you have to include laptops, where the wifi might be built-in
but might not be switched on/unblocked at boot time. I have a laptop
with a (toggling) hard blocker. If the AC power has been disconnected
(the battery is flat), it boots up blocked, so I know to press the
toggle just /once/. If I can't remember whether it's been disconnected
or not, then I don't know whether to press the toggle. Having auto
specified in /e/n/i would make each boot a gamble.

> My gripe is that the installer has (traditionally?) used allow-hotplug for
> ALL ethernet interfaces, including the built-in interfaces on a server.
> This causes massive problems with the ordering of service initializations
> at boot. It took me a *long* time and a lot of digging to figure out why
> things were breaking, so I try to pass that knowledge along for others.

Fair enough, but I feel that setting a default that suits the naive
user with a simple one-machine setup might have weighted the choice
made by the d-i team. (I'm not sure how one divines an intent to set
up a "server" BTW.) Obviously I don't know what specific things broke
in your case, but I wouldn't call the OP's system a simple setup.

Cheers,
David.

[Celejar]

On Fri, 1 Sep 2023 18:33:51 -0400
Greg Wooledge <gr...@wooledge.org> wrote:

...

> Standard installation. But as you noted, it's optional. Debian *also*
> allows the use of Network Manager, systemd-networkd, and probably several
> other systems for configuring one's network(s).

Yes - I use iwd for basic (wireless) network configuration.

--
Celejar

[David Wright]

On Fri 01 Sep 2023 at 21:31:39 (+0100), Brad Rogers wrote:
> On Fri, 1 Sep 2023 14:02:31 -0600 D. R. Evans wrote:
>
> >So how do I fix this so that the networking is configured to work
> >correctly during the boot sequence, as it has always done before?
>
> I had changing ethernet port issues and found that creating
> /etc/systemd/network/99-default.link
>
> with the stanza
>
> --8X-----
>
> [Match]
> MACAddress=AA:BB:CC:DD:EE:FF
> # Substitute the real MAC address
>
> [Link]
> Name=ethN
> # Replace N with something unique (e.g. 0)
>
> --8X---
>
> works well. I see no reason that creating two stanzas with (I hope) the
> obvious changes, one for each i/f, should fail.
>
> Now somebody's bound to come along and say
> "No, there's a better way....."

I've no argument with the method of naming the interfaces with more
meaningful and stable names, though the OP's problem seems to have
been not using the new names to disambiguate them. But FTR, just a
couple of niggles:

Renaming an interface (that the kernel likely originally named as eth0
or eth1) to eth0 is a confusing thing to do. Pick a name that can't
clash with anything else: I would avoid anything that the kernel or
udev might choose. Popular choices are lan0, internet0.

A filename like /etc/systemd/network/80-mywired.link avoids overriding
systemd's /lib/systemd/network/99-default.link. I'm not sure why you
would want to override it.

Cheers,
David.