Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
While attempting to use `reapply` in the Nmstate project, we have found that in case the wired setting is not defined/added to the new profile, the reapply operation will fail, claiming that the mac address change is not supported.
`nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)`
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Fetch existing profile using `get_connection_by_id`.
2. Create new profile using SimpleConnection.new()
3. Add to the new profile the wanted setting (connection and IPvX in our case) using `add_setting`. (do not include the wired setting)
4. Replace existing profile settings with the new profile setting using `replace_settings_from_connection(new_profile)`.
5. Commit the existing profile changes using `commit_changes_async`.
7. Execute reapply with the existing profile.
Actual results:
Step 7 fails with the following error:
`nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)`
Expected results:
Reapply should succeed because no wired changes have been requested.
Additional info:
Workaround:
Fetching the wired setting from the current profile and using it in the new profile has resolved the problem.
Created attachment 1627660[details]
reproducer in python for ethernet device
run these commands before python script:
nmcli con add type ethernet con-name testeth2 ifname eth2
nmcli device diconnect eth2
ip a add 192.168.5.5/24 dev eth2
Comment 8Beniamino Galvani
2019-10-22 19:49:42 UTC
(In reply to Filip Pokryvka from comment #7)
> Created attachment 1627660[details]
> reproducer in python for ethernet device
>
> run these commands before python script:
>
> nmcli con add type ethernet con-name testeth2 ifname eth2
> nmcli device diconnect eth2
> ip a add 192.168.5.5/24 dev eth2
I tried this and the reapply fails with error:
Can't reapply changes to '802-3-ethernet.mac-address' setting (3)
because the assumed connection on eth2 has ethernet.mac-address set while the new connection doesn't have it. NM computes the difference between the connection currently active and the one to reapply and finds that ethernet.mac-address changed, but that isn't a property that can be reapplied at runtime. This sounds correct in my opinion.
Comment 11Beniamino Galvani
2020-03-02 09:15:38 UTC
(In reply to Edward Haas from comment #10)
> Is this issue resolved? Why is the BZ still open?
There are multiple issues related to reapplying an optional
setting.
The first one is that the wired setting was implicitly added by NM
when saving some connection types (bridges, bonds, etc.), and so if
you tried to reapply the same connection again without changes, NM
would complain because the new connection didn't have a wired setting
while the old one did. This issue was solved in this bz.
The other issue is that at the moment NM refuses to perform a reapply
if the new connection adds a wired setting with all default values (or
if it removes it and it was all defaults previously).
For the wired setting, a missing setting and one with all defaults is
equivalent; but this is not true for other settings. For example, a
missing sriov setting means not to touch SR-IOV related parameters;
while a sriov setting with default values (zero VFs) means to reset
VFs. So we need to implement a setting-specific comparison logic.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:1162