Bug 1777893

Summary: FC31 kernel does not honor persistent net name. Same FC30 kernel does
Product: [Fedora] Fedora Reporter: sean darcy <seandarcy2>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 31CC: airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, kgagnon, linville, masami256, mchehab, mjg59, ol+redhat, patmans, samuel-rhbugs, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-24 17:02:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg from fc31 boot
none
dmesg from same machine, same kernel, but fc30. net names honored. none

Description sean darcy 2019-11-28 15:47:41 UTC
Created attachment 1640425 [details]
dmesg from fc31 boot

1. Please describe the problem:
On boot persistent interface names not honored

2. What is the Version-Release number of the kernel:
kernel-5.3.11-300.fc31.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
Yes. It works in FC30 version of the SAME kernel:
kernel-5.3.11-200.fc30.x86_64

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Boot.


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:


6. Are you running any modules that not shipped with directly Fedora's kernel?:
No

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

See :

https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/TTCZIHNTBQ6FFJ7XN5WKTG6BPLH5RU3A/

The names are set up in network-scripts, which works for the FC30 kernel. I've since added .link files in /etc/systemd/network. Also 70-persistent-net.rule. None honored by the FC31 kernel.

Comment 1 sean darcy 2019-11-28 19:54:52 UTC
Created attachment 1640483 [details]
dmesg from same machine, same kernel, but fc30. net names honored.

Comment 2 Oleg Girko 2020-01-02 20:41:07 UTC
This is what happened when I was upgrading from Fedora 30 to Fedora 31. I wrote it down and now I'm presenting my observations here.

I had "/etc/udev/rules.d/70-persistent-net.rules" file with the following contents:

    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="XX:XX:XX:XX:XX:XX", ATTR{type}=="1", NAME="int"

(where "XX:XX:XX:XX:XX:XX" is MAC address of my Ethernet card).

The interface was configured as a slave in the bridge using "/etc/NetworkManager/system-connections/int.nmconnection" file with the following contents:

    [connection]
    id=int
    uuid=1f203685-ba36-4d0c-83d2-52219b8fe37e
    type=ethernet
    master=f2513c25-3560-42e4-bc32-1e1a23ae0697
    permissions=
    slave-type=bridge
    timestamp=1572822395

    [ethernet]
    mac-address=XX:XX:XX:XX:XX:XX
    mac-address-blacklist=

    [bridge-port]

(I use "keyfile" plugin of NetworkManager instead of "ifcfg-rh", but I think that it's not important for this case).

All IPv4 and IPv6 configuration is configured in bridge master interface.

All this worked well in Fedora 30 and earlier versions, but broke after upgrading to Fedora 31.

Now after adding "udev_log=debug" to "/etc/udev/udev.conf" file there are the following entries in journal for "systemd-udevd" service:

    Nov 03 22:29:36 jr.infoserver.lv systemd-udevd[924]: enp0s31f6: Failed to rename network interface 2 from 'enp0s31f6' to 'int': Device or resource busy
    Nov 03 22:29:36 jr.infoserver.lv systemd-udevd[924]: enp0s31f6: Failed to process device, ignoring: Device or resource busy

and after that NetworkManager starts ignoring this interface because it's "strictly umanaged".

If I re-trigger adding this interface with "udevadm trigger --action=add --subsystem-match=net --attr-match=address=XX:XX:XX:XX:XX:XX --attr-match=type=1" command, I see the same errors in journal for "systemd-udevd" service. but the interface gets added to the bridge without being renamed.

If I put the interface down with "ip link set enp0s31f6 down" command and re-trigger adding it with the same "udevadm" command as above, it gets added to the bridge without errors in journal for "systemd-udevd" service.

This all was happening with 5.3.7-301.fc31.x86_64 kernel (the one available when I was upgrading to Fedora 31). When I was booting with 5.3.7-200.fc30.x86_64 kernel (the same version, but for Fedora 30), interface was being renamed successfully on boot without any errors.

This makes me think that something has changed in the kernel built for Fedora 30 that prevents interface renaming in Fedora 31 with "Device or resource busy" error.
Either the interface was not up on boot in Fedora 30, or it was OK to rename it when it's up.

Also, it changes nothing if I configure interface renaming in ".link" file in "/etc/systemd/network" directory instead of rule file in "/etc/udev/rules.d": renaming the interface still fails with the same error.

As a workaround, I've stopped renaming the interface and use it as bridge's slave with its original name.

Comment 3 Ben Cotton 2020-11-03 16:48:12 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Ben Cotton 2020-11-24 17:02:09 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.