6 Aug
2023
6 Aug
'23
8:33 p.m.
Hi,
I upgraded my Debian system from Bullseye to Bookworm earlier today. It mostly went pretty
smoothly, but I have two questions:
1. I remembered to change the interface name from eth0 to enX0 but couldn't connect to
any regular network services (ssh, httpd) after the system was rebooted. I used the Xen
shell to change the interface name back to eth0, and could connect again after a reboot.
Are some systems happy to stay as eth0? This is quite an old system and has been upgraded
in place over several years (started as a Debian 5.x (Lenny) system in 2009.
2. The sysv-rc-conf package is being held back when I apt-get upgrade. If I try to
upgrade it, apt wants to remove a load of packages (about 30). Can I safely just remove
the sysv-rc-conf package? /sbin/init is a symlink to /lib/systemd/systemd, so I presume
I'm using systemd and don't need sysv-rc-conf?
--
Jamie MacIsaac
jamie(a)macisa.ac
6 Aug
6 Aug
10:36 p.m.
Hi,
On Sun, Aug 06, 2023 at 09:33:23PM +0100, Jamie MacIsaac via BitFolk Users wrote:
1. I remembered to change the interface name from eth0
to enX0 but
couldn't connect to any regular network services (ssh, httpd)
after the system was rebooted. I used the Xen shell to change the
interface name back to eth0, and could connect again after a
reboot. Are some systems happy to stay as eth0? This is quite an
old system and has been upgraded in place over several years
(started as a Debian 5.x (Lenny) system in 2009.
As far as I'm aware eth0 will be renamed to enX0 unless you have
taken steps in the past to prevent this. So have you done any of the
things described here?
https://wiki.debian.org/NetworkInterfaceNames#How_to_get_it_back
On a bullseye VM this is what udev thinks about my eth0:
$ sudo udevadm test-builtin net_id /sys/class/net/eth0
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /lib/systemd/network/73-usb-net-by-mac.link
Created link configuration context.
Using default interface naming scheme 'v247'.
ID_NET_NAMING_SCHEME=v247
ID_NET_NAME_MAC=enxaa00004ba0c1
ID_OUI_FROM_DATABASE=DIGITAL EQUIPMENT CORPORATION
Unload module index
Unloaded link configuration context.
and on a bookworm VM this is what it thinks:
$ sudo udevadm test-builtin net_id /sys/class/net/enX0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version: 252
file size: 11993513 bytes
header size 80 bytes
strings 2530377 bytes
nodes 9463056 bytes
Loading kernel module index.
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
Using default interface naming scheme 'v252'.
Parsed configuration file "/usr/lib/systemd/network/99-default.link"
Parsed configuration file "/usr/lib/systemd/network/73-usb-net-by-mac.link"
Created link configuration context.
ID_NET_NAMING_SCHEME=v252
ID_NET_NAME_MAC=enx00165e000605
enX0: MAC address identifier: hw_addr=00:16:5e:00:06:05 → x00165e000605
ID_OUI_FROM_DATABASE=Precision I/O
sd-device: Failed to chase symlinks in "/sys/devices/vif-0/of_node".
ID_NET_NAME_SLOT=enX0
Unload kernel module index.
Unloaded link configuration context.
What does yours say?
2. The sysv-rc-conf package is being held back when I
apt-get
upgrade. If I try to upgrade it, apt wants to remove a load of
packages (about 30). Can I safely just remove the sysv-rc-conf
package? /sbin/init is a symlink to /lib/systemd/systemd, so I
presume I'm using systemd and don't need sysv-rc-conf?
Yes, you can remove it, it's not being used. It doesn't have
anything depending upon it either:
$ apt rdepends sysv-rc-conf
sysv-rc-conf
Reverse Depends:
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
7 Aug
7 Aug
8:11 a.m.
tl;dr - fixed. Removed the "/etc/systemd/network/99-default.link" file then
typed "sudo update-initramfs -u" and rebooted as described in the VIRTUAL
MACHINES section of
https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases
On Sun, 6 Aug 2023, at 23:36, Andy Smith via BitFolk Users wrote:
As far as I'm aware eth0 will be renamed to enX0
unless you have
taken steps in the past to prevent this. So have you done any of the
things described here?
https://wiki.debian.org/NetworkInterfaceNames#How_to_get_it_back
Hi Andy,
Not recently, no. I can't rule out having unwittingly made changes in previous years,
though.
On a bullseye VM this is what udev thinks about my
eth0:
$ sudo udevadm test-builtin net_id /sys/class/net/eth0
<snip
lots-of-details>
and on a bookworm VM this is what it thinks:
$ sudo udevadm test-builtin net_id /sys/class/net/enX0
<snip
lots-more-details>
What does yours say?
"device is missing." :-(
Fixed now, as described in the tl;dr section at the top. There's nothing but comments
in the /etc/systemd/network/99-default.link file, but these comments seem to describe my
situation (and maybe some others over the next few months?) pretty well:
# This machine is most likely a virtualized guest, where the old persistent
# network interface mechanism (75-persistent-net-generator.rules) did not work.
# This file disables /lib/systemd/network/99-default.link to avoid
# changing network interface names on upgrade. Please read
# /usr/share/doc/udev/README.Debian.gz about how to migrate to the currently
# supported mechanism.
Finally, the sysv-rc-conf package was removed - nothing being held back any more:
Yes, you can remove it, it's not being used. It
doesn't have
anything depending upon it either:
Cool. Removed and rebooted without issue - thanks!
Cheers,
jmi
11:08 a.m.
Hi Jamie,
On Mon, Aug 07, 2023 at 09:11:07AM +0100, Jamie MacIsaac via BitFolk Users wrote:
tl;dr - fixed. Removed the "/etc/systemd/network/99-default.link" file then
typed "sudo update-initramfs -u" and rebooted as described in the VIRTUAL
MACHINES section of
https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases
So the existence of such a file is suspicious to me - on a clean
install I don't have an /etc/systemd/network/99-default.link file
only a /lib/systemd/network/99-default.link file and your one in
/etc would be overriding the one in /lib.
I don't have a /etc/systemd/network/99-default.link in any of my
other pre-bookworm VMs either, so I'd be interested in knowing how
that got created in order to be able to advise others whether their
eth0 is going to be renamed.
Anyway, glad you got it sorted!
On Sun, 6 Aug 2023, at 23:36, Andy Smith via BitFolk
Users wrote:
Oh, it did that for /sys/class/net/eth0 even when your interface was
currently called eth0?
$ sudo udevadm test-builtin net_id
/sys/class/net/enX0
<snip lots-more-details>
What does yours say?
"device is missing." :-( Fixed now, as described in the tl;dr section at the
top. There's nothing but comments in the /etc/systemd/network/99-default.link file,
but these comments seem to describe my situation (and maybe some others over the next few
months?) pretty well:
# This machine is most likely a virtualized guest, where the old persistent
# network interface mechanism (75-persistent-net-generator.rules) did not work.
# This file disables /lib/systemd/network/99-default.link to avoid
# changing network interface names on upgrade. Please read
# /usr/share/doc/udev/README.Debian.gz about how to migrate to the currently
# supported mechanism.
Hmm, does look like something that was automatically put in there by
some process…
I found this:
https://sources.debian.org/src/systemd/254-1/debian/changelog/?hl=5707#L5707
which I think might be a reference to it. That's from 2015 and
refers to new installs of systemd 220-7. Maybe this happens if you
originally did your install around that time?
An annoying complication if so as there would be a small chance that
the change WON'T happen to some people!
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
11:30 a.m.
On Mon, Aug 07, 2023 at 11:08:19AM +0000, Andy Smith via BitFolk Users wrote:
So the existence of such a file is suspicious to me -
on a clean
install I don't have an /etc/systemd/network/99-default.link file
only a /lib/systemd/network/99-default.link file and your one in
/etc would be overriding the one in /lib.
I've had a more thorough check and it appears that several of my
Debian 11 (bullseye) hosts do have this file
(/etc/systemd/network/99-default.link) either as an empty file or a
symlink to /dev/null. I also found a Debian 9 (stretch) VM with it.
So it seems like if you did a clean install of stretch, buster or
bullseye then maybe you got that.
That really sucks as it's now rather difficult to say what will
happen on an upgrade to bookworm without going in to a lot of
detail. 🙁
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
12:49 p.m.
On Mon, 7 Aug 2023, at 12:30, Andy Smith via BitFolk Users wrote:
I also found a Debian 9 (stretch) VM with it.
So it seems like if you did a clean install of stretch, buster or
bullseye then maybe you got that.
VM in question a bit older than that - originally Debian 5 (lenny), but stretch is the
earliest reference I've found to that particular file (see
https://lists.debian.org/debian-user/2017/07/msg01453.html). Earlier Debian releases used
a different interface naming method, so I'm guessing the 99-default.link file was
added in the 8 -> 9 dist-upgrade.
That really sucks as it's now rather difficult to
say what will
happen on an upgrade to bookworm without going in to a lot of
detail. 🙁
Agreed that it's yet another thing to trip over, but for anyone confident enough to
perform a dist-upgrade then checking for the existence of
/etc/systemd/network/99-default.link can't be too onerous. And there's this list
and the Xen console!
Cheers,
jmi
2:13 p.m.
Hello,
On Mon, Aug 07, 2023 at 01:49:13PM +0100, Jamie MacIsaac via BitFolk Users wrote:
stretch is the earliest reference I've found to
that particular
file (see
https://lists.debian.org/debian-user/2017/07/msg01453.html).
Earlier Debian releases used a different interface naming method,
so I'm guessing the 99-default.link file was added in the 8 -> 9
dist-upgrade.
It's strange as I do have some VMs that started out as etch or lenny
and been upgraded through to buster or bullseye and most don't have
this file.
Agreed that it's yet another thing to trip over,
but for anyone
confident enough to perform a dist-upgrade then checking for the
existence of /etc/systemd/network/99-default.link can't be too
onerous. And there's this list and the Xen console!
Sadly there have been quite a few support tickets about this, and
even people opening support tickets to be helpful and let us know
that interfaces get renamed!
Very few customers read this list, or the wiki or Debian's release
notes I'm afraid.
It kind of makes me regret not putting net.ifnames=0 on the kernel
command line at install time as then none of this would be an issue.
We debated it here and people said they wanted "the upstream
experience" where possible. I think we were wrong. But I'm not sure
that changing it now would be a good idea.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
4:35 p.m.
On 7 Aug 2023, at 12:30, Andy Smith via BitFolk Users <users(a)mailman.bitfolk.com>
wrote:
I've had a more thorough check and it appears that
several of my
Debian 11 (bullseye) hosts do have this file
(/etc/systemd/network/99-default.link) either as an empty file or a
symlink to /dev/null. I also found a Debian 9 (stretch) VM with it.
So it seems like if you did a clean install of stretch, buster or
bullseye then maybe you got that.
Just checked mine and the two Bookworms (Bitfolk VM and physical server at home) don’t
have it. The physical server was a clean install of Bullseye and the Bitfolk VM has been
upgraded a number of times. I have a clean install of Bullseye on a VM and that doesn’t
have it, either.
The only server that I have it on is a Pi 4B running Raspberry Pi OS (Bullseye) and that
was a clean install. It’s symlinked to /dev/null.
Cheers,
Mike
4:11 a.m.
Hi,
I also did the same upgrade recently.
On Mon, 7 Aug 2023, 00:33 Jamie MacIsaac via BitFolk Users, <
users(a)mailman.bitfolk.com> wrote:
Hi,
I upgraded my Debian system from Bullseye to Bookworm earlier today. It
mostly went pretty smoothly, but I have two questions:
1. I remembered to change the interface name from eth0 to enX0 but
couldn't connect to any regular network services (ssh, httpd) after the
system was rebooted. I used the Xen shell to change the interface name back
to eth0, and could connect again after a reboot. Are some systems happy to
stay as eth0? This is quite an old system and has been upgraded in place
over several years (started as a Debian 5.x (Lenny) system in 2009.
Did you have any firewall rules specifically for eth0? That was what caused
me to lose ssh access after the upgrade.
Kevin
8:14 a.m.
On Mon, 7 Aug 2023, at 05:11, Kevin O'Rourke via BitFolk Users wrote:
Did you have any firewall rules specifically for eth0?
That was what caused me to lose ssh access after the upgrade.
Hi Kevin,
I didn't in this case, but it was definitely worth looking for - thank you for your
reply!
Cheers,
jmi
511
days inactive
512
days old
9 comments
4 participants
participants (4)
-
Andy Smith -
Jamie MacIsaac -
Kevin O'Rourke -
Mike Zanker