On Mon, Jan 27, 2020 at 1:40 PM sean darcy via networkmanager-list <
networkmanager-list@gnome.org> wrote:

> On 1/26/20 3:16 AM, Thomas Haller via networkmanager-list wrote:
> > On Sat, 2020-01-25 at 14:34 -0500, sean darcy via networkmanager-list
> > wrote:
> >> Fedora FC31. NetworkManager-1.20.10-1.fc31.x86_64
> >> This a cross post with Fedora user.
> >>
> >> On FC31 I can't persistently rename the interfaces, see:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1777893
> >>
> >> I'll give up and use FC31 interface names : enp1s0 and enp0s20u3.
> >>
> >> I've used nmtui to set up the interfaces. But NM won't activate them
> >> because they are "strictly unmanaged" !!
> >
> > Hi,
> >
> >
> > I think this is a bug.
> >
> > NetworkManager is running in initrd. Thereby it already activates the
> > interface. Later, udev wants to rename the interface, but since it's
> > already up, it fails to do so.
> >
> > The result is that udev doesn't indicate that the device is
> > initialized, which causes NM to wait for it (and thus it's unmanaged).
> >
> > It seems there are several potential issues:
> >
> >    - why does NetworkManager even run in initrd, if you didn't configure
> > it to do so?
> >
> >    - if NM is running in initrd, should it wait for udev to rename the
> > device?
> >
> >    - why does udev completely fail in this case?
> >
> >    - maybe NM should after a timeout stop waiting for udev, to mitigate
> > this issue.
> >
> >
> > You could look at the logfile to verify that. Enable level=TRACE
> > logging, but most interesting are also the messages from initrd and
> > udev.
> >
> >
> > best,
> > Thomas
> >
> >>
> >> What does that mean and how do I fix it ?
> >>
> >> Is there some other way to persistently activate the interface ?
> >>
> >> /etc/network/interfaces does not exist.
> >>
> >> sean
> >>
> >>    cat /etc/sysconfig/network-scripts/ifcfg-enp*
> >> TYPE=Ethernet
> >> PROXY_METHOD=none
> >> BROWSER_ONLY=no
> >> BOOTPROTO=none
> >> IPADDR=10.10.11.251
> >> PREFIX=24
> >> DNS1=10.10.11.251
> >> DEFROUTE=no
> >> IPV4_FAILURE_FATAL=no
> >> IPV6INIT=no
> >> IPV6_AUTOCONF=yes
> >> IPV6_DEFROUTE=yes
> >> IPV6_FAILURE_FATAL=no
> >> IPV6_ADDR_GEN_MODE=stable-privacy
> >> NAME=enp0s20u3
> >> UUID=bf8aa45c-31e4-403a-9c14-c1a59bf0f2b2
> >> ONBOOT=yes
> >> DEVICE=enp0s20u3
> >>
> >> TYPE=Ethernet
> >> PROXY_METHOD=none
> >> BROWSER_ONLY=no
> >> BOOTPROTO=dhcp
> >> DEFROUTE=yes
> >> IPV4_FAILURE_FATAL=no
> >> IPV6INIT=yes
> >> IPV6_AUTOCONF=yes
> >> IPV6_DEFROUTE=yes
> >> IPV6_FAILURE_FATAL=no
> >> IPV6_ADDR_GEN_MODE=stable-privacy
> >> NAME=enp1s0
> >> UUID=a1b089e9-5a13-4df7-8f09-9f54ebc56cea
> >> DEVICE=enp1s0
> >> ONBOOT=yes
> >>
>
> I put net.ifames=0 in the kernel command line. I removed the
> /etc/udev/rules/70-persistent-net.rules. I set up
> /etc/sysconfig/network-scripts/ifcfg-eth[01].
>
>
I also put biosdevname=0 on the kernel line and install the biosdevname
package.  No udev rule editing needed with these as well as net.ifnames=0.



> On reboot, I had eth0 and eth1. eth1 was active. But eth0 was not
> active. When I used nmtui to activate eth0. I got the dreaded "strictly
> unmanaged" error.
>
> Here's dmesg | grep eth0
>
> :25 lenovo-gateway.riverside kernel: r8169 0000:01:00.0 eth0:
> RTL8168gu/8111gu, 50:7b:9d:0b:8a:ab, XID 509, IRQ 44
> :25 lenovo-gateway.riverside kernel: r8169 0000:01:00.0 eth0: jumbo
> features [frames: 9200 bytes, tx checksumming: ko]
> :27 lenovo-gateway.riverside NetworkManager[484]: <info>
> [1580149767.5593] manager: (eth0): new Ethernet device
> (/org/freedesktop/NetworkManager/Devices/2)
> :27 lenovo-gateway.riverside NetworkManager[484]: <info>
> [1580149767.5594] device (eth0): state change: unmanaged -> unavailable
> (reason 'managed', sys-iface-state: 'external')
> :27 lenovo-gateway.riverside kernel: r8169 0000:01:00.0 eth0: Link is Down
> :30 lenovo-gateway.riverside kernel: r8169 0000:01:00.0 eth0: Link is Up
> - 1Gbps/Full - flow control off
> :30 lenovo-gateway.riverside kernel: IPv6: ADDRCONF(NETDEV_CHANGE):
> eth0: link becomes ready
> :30 lenovo-gateway.riverside NetworkManager[484]: <info>
> [1580149770.5499] device (eth0): carrier: link connected
> :30 lenovo-gateway.riverside NetworkManager[484]: <info>
> [1580149770.5502] device (eth0): state change: unavailable ->
> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
> :55 lenovo-gateway.riverside systemd-udevd[695]: eth0: Failed to rename
> network interface 2 from 'eth0' to 'external': Device or resource busy
> :55 lenovo-gateway.riverside systemd-udevd[695]: eth0: Failed to process
> device, ignoring: Device or resource busy
> Jan 27 13:30:33 lenovo-gateway.riverside NetworkManager[975]: <info>
> [1580149833.3056] device (eth0): carrier: link connected
> Jan 27 13:30:33 lenovo-gateway.riverside NetworkManager[975]: <info>
> [1580149833.3059] manager: (eth0): new Ethernet device
> (/org/freedesktop/NetworkManager/Devices/4)
>
>
> Note at :55 udev tries to rename the device. But there's NO udev rule to
> do so. So where's that from ??
>
>
> grep -R external /etc/udev/rules.d/*
> /etc/udev/rules.d/40-libsane.rules:# If your scanner is supported by
> some external backend (brother, epkowa,
> /etc/udev/rules.d/S99-2000S1.rules:# If your scanner is supported by
> some external backend (brother, epkowa,
>
> It seems udev tries to rename the device, and fails because the
> "resource is busy", whatever that means. But then NetworkManager won't
> activate it.
>
> I'm surprised this problem hasn't arisen with every multihomed machine,
> but there are no posts I've found.
>
> How do I get udev not to try to rename eth0 ? But that's a udev problem.
>
> This is the NetworkManager list. How do I force NetworkManager to
> "manage" this interface ?
>
> sean
>
>
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to