Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1003835: udev: XEN domU: Guest RX stalled, unreachable due to nw device naming change
111 views
Skip to first unread message
Felix Odk
Jan 16, 2022, 12:30:05 PM1/16/22
to
Package: udev
Version: 250.2-3
Severity: important
X-Debbugs-Cc: f.oden...@gmx.net
Dear Maintainer,
-- Package-specific info:
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages udev depends on:
ii adduser 3.118
ii libacl1 2.3.1-1
ii libblkid1 2.37.2-6
ii libc6 2.33-2
ii libcap2 1:2.44-1
ii libkmod2 29-1
ii libselinux1 3.3-1+b1
ii libudev1 250.2-3
ii util-linux 2.37.2-6
udev recommends no packages.
udev suggests no packages.
Versions of packages udev is related to:
ii systemd 250.2-3
-- no debconf information
Dear all,
I'm running a stock Debian SID vm on xen, hostname "vm-sid".
Dom0 is on stock Debian Bullseye, providing a virtual bridge for
networking the VMs.
apt updating several packages on domU on 2022-01-13 08:11:00 UTC rendered vm-sid
unaccessible over network upon reboot.
log messages on dom0:
12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0
12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state
12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state
12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode
12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39
12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready
12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready
12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state
12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state
12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled
12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state
Workaround:
After logging into the vm using 'xl console 18', interface could be
identified by 'sudo ip a' and manually brought up using 'sudo ip link set enX0 up'.
ROOT CAUSE:
udev package changed the naming of the primary network device on a XEN
domU from "eth0" to "enX0". Since /etc/network/interfaces is not
updated, nw interface is not automatically brought up anymore, rendering
the vm unreachable.
POSSIBLE FIX:
devise a postinst script that (1) checks whether updated udev will change
the name of the networking device, and (2) updates
/etc/ntework/interfaces accordingly.
Version: 250.2-3
Severity: important
X-Debbugs-Cc: f.oden...@gmx.net
Dear Maintainer,
-- Package-specific info:
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages udev depends on:
ii adduser 3.118
ii libacl1 2.3.1-1
ii libblkid1 2.37.2-6
ii libc6 2.33-2
ii libcap2 1:2.44-1
ii libkmod2 29-1
ii libselinux1 3.3-1+b1
ii libudev1 250.2-3
ii util-linux 2.37.2-6
udev recommends no packages.
udev suggests no packages.
Versions of packages udev is related to:
ii systemd 250.2-3
-- no debconf information
Dear all,
I'm running a stock Debian SID vm on xen, hostname "vm-sid".
Dom0 is on stock Debian Bullseye, providing a virtual bridge for
networking the VMs.
apt updating several packages on domU on 2022-01-13 08:11:00 UTC rendered vm-sid
unaccessible over network upon reboot.
log messages on dom0:
12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0
12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state
12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state
12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode
12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39
12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready
12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready
12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state
12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state
12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled
12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state
Workaround:
After logging into the vm using 'xl console 18', interface could be
identified by 'sudo ip a' and manually brought up using 'sudo ip link set enX0 up'.
ROOT CAUSE:
udev package changed the naming of the primary network device on a XEN
domU from "eth0" to "enX0". Since /etc/network/interfaces is not
updated, nw interface is not automatically brought up anymore, rendering
the vm unreachable.
POSSIBLE FIX:
devise a postinst script that (1) checks whether updated udev will change
the name of the networking device, and (2) updates
/etc/ntework/interfaces accordingly.
Michael Biebl
Jan 17, 2022, 2:20:03 AM1/17/22
to
Am 16.01.22 um 18:18 schrieb Felix Odk:
https://github.com/systemd/systemd/commit/d6eda677b32a0063a77cb639f37c9a454b180da9
See also the relevant NEWS entry:
"
* The predictable naming logic for network interfaces has been extended
to generate stable names from Xen netfront device information.
"
To switch back to the v249 behaviour, you can add
net.naming-scheme=v249 to the kernel command line.
You can find further information in "man systemd-udevd.service" and "man
systemd.net-naming-scheme"
> POSSIBLE FIX:
> devise a postinst script that (1) checks whether updated udev will change
> the name of the networking device, and (2) updates
> /etc/ntework/interfaces accordingly.
I don't think we want to get into the business of mangling other
packages configuration files (which would be a policy violation anyway).
Also keep in mind that ifupdown is by no means the only network
configuration scheme.
At most we could let postinst generate a warning message.
That said, I have no idea if such a script would be feasible and how
reliable the detection would be.
I'm happy to take suggestions how this could be implemented.
Even better, if you have an idea, please submit a MR.
Regards,
Michael
> log messages on dom0:
> 12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0
> 12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state
> 12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state
> 12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode
> 12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39
> 12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready
> 12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready
> 12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state
> 12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state
> 12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled
> 12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state
>
> Workaround:
> After logging into the vm using 'xl console 18', interface could be
> identified by 'sudo ip a' and manually brought up using 'sudo ip link set enX0 up'.
>
> ROOT CAUSE:
> udev package changed the naming of the primary network device on a XEN
> domU from "eth0" to "enX0". Since /etc/network/interfaces is not
> updated, nw interface is not automatically brought up anymore, rendering
> the vm unreachable.
This is probably a result of
> 12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0
> 12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state
> 12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state
> 12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode
> 12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39
> 12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready
> 12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready
> 12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state
> 12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state
> 12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled
> 12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state
>
> Workaround:
> After logging into the vm using 'xl console 18', interface could be
> identified by 'sudo ip a' and manually brought up using 'sudo ip link set enX0 up'.
>
> ROOT CAUSE:
> udev package changed the naming of the primary network device on a XEN
> domU from "eth0" to "enX0". Since /etc/network/interfaces is not
> updated, nw interface is not automatically brought up anymore, rendering
> the vm unreachable.
https://github.com/systemd/systemd/commit/d6eda677b32a0063a77cb639f37c9a454b180da9
See also the relevant NEWS entry:
"
* The predictable naming logic for network interfaces has been extended
to generate stable names from Xen netfront device information.
"
To switch back to the v249 behaviour, you can add
net.naming-scheme=v249 to the kernel command line.
You can find further information in "man systemd-udevd.service" and "man
systemd.net-naming-scheme"
> POSSIBLE FIX:
> devise a postinst script that (1) checks whether updated udev will change
> the name of the networking device, and (2) updates
> /etc/ntework/interfaces accordingly.
packages configuration files (which would be a policy violation anyway).
Also keep in mind that ifupdown is by no means the only network
configuration scheme.
At most we could let postinst generate a warning message.
That said, I have no idea if such a script would be feasible and how
reliable the detection would be.
I'm happy to take suggestions how this could be implemented.
Even better, if you have an idea, please submit a MR.
Regards,
Michael
Michael Biebl
Jan 17, 2022, 2:30:04 AM1/17/22
to
Am 17.01.22 um 08:15 schrieb Michael Biebl:
> I don't think we want to get into the business of mangling other
> packages configuration files (which would be a policy violation anyway).
> Also keep in mind that ifupdown is by no means the only network
> configuration scheme.
>
> At most we could let postinst generate a warning message.
> That said, I have no idea if such a script would be feasible and how
> reliable the detection would be.
> I'm happy to take suggestions how this could be implemented.
> Even better, if you have an idea, please submit a MR.
Another alternative could be to add a udev.NEWS entry.
> packages configuration files (which would be a policy violation anyway).
> Also keep in mind that ifupdown is by no means the only network
> configuration scheme.
>
> At most we could let postinst generate a warning message.
> That said, I have no idea if such a script would be feasible and how
> reliable the detection would be.
> I'm happy to take suggestions how this could be implemented.
> Even better, if you have an idea, please submit a MR.
Michael Biebl
Jan 17, 2022, 11:40:04 AM1/17/22
to
Am 17.01.22 um 08:20 schrieb Michael Biebl:
I'm tossing out another idea:
debian-installer, when installing the system initially, could write a
config for grub which appends net.naming-scheme=<version of systemd the
system was installed with>
So, once the system is installed, the net-naming-scheme would no longer
change.
Haven't yet made up my mind, whether this is a good idea or not.
Would welcome feedback!
Michael
debian-installer, when installing the system initially, could write a
config for grub which appends net.naming-scheme=<version of systemd the
system was installed with>
So, once the system is installed, the net-naming-scheme would no longer
change.
Haven't yet made up my mind, whether this is a good idea or not.
Would welcome feedback!
Michael
0 new messages