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.
Bug 2056362 - Changing NIC type rolls back the checkpoint
Summary: Changing NIC type rolls back the checkpoint
Keywords:
Status: CLOSED DUPLICATE of bug 2056386
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cockpit
Version: 8.6
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Martin Pitt
QA Contact: peyu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-02-21 05:07 UTC by peyu
Modified: 2022-02-23 14:18 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-23 14:18:38 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)
page after changing IPv{4,6} to manual (26.40 KB, image/png)
2022-02-22 08:18 UTC, Martin Pitt
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-112895 0 None None None 2022-02-21 09:24:19 UTC

Description peyu 2022-02-21 05:07:49 UTC
Description of problem:
Login cockpit, configure the NIC with IPv4 and IPv6 with "Manual" type:
1. The IPv6 setting does not take effect and will return to "Automatic" mode immediately.
2. The settings for IPv4 can take effect, but if switch from "Manual" mode to other modes, it fails.


Version-Release number of selected component (if applicable):
RHVH: rhvh-4.5.0.2-0.20220216.0+1

subscription-manager-cockpit-1.28.25-1.el8.noarch
cockpit-bridge-261-1.el8.x86_64
cockpit-system-261-1.el8.noarch
cockpit-storaged-261-1.el8.noarch
cockpit-ws-261-1.el8.x86_64
cockpit-261-1.el8.x86_64
cockpit-ovirt-dashboard-0.15.1-2.el8ev.noarch


How reproducible:
100%

Steps to Reproduce:
1. Install redhat-virtualization-host-4.5.0-202202161646_8.6
2. Login cockpit via firefox browser
3. Go to "Networking" -> "Interfaces"
4. Click a NIC to enter its configuration page
5. Configure the NIC with IPv4 and IPv6 with "Manual" type and fill in the IP address
6. Click the "Change the settings" button in the "Connection will be lost" dialog that pops up
7. Check the type of IPv4 and IPv6
8. Switch the settings from "Manual" type back to "Automatic"/or other type 


Actual results:
1. The IPv6 setting does not take effect and will return to "Automatic" mode immediately.
2. The settings for IPv4 can take effect, but if switch from "Manual" mode to other modes, it fails.

Expected results:
Set the IPv4 and IPv6 of the NIC to "Manual" mode should take effect, and can switch back to other modes.

Additional info:

Comment 1 peyu 2022-02-21 07:04:54 UTC
Configuring a type other than the default type for the NIC's IPv4 and IPv6 will also fail.

Comment 2 Martin Pitt 2022-02-22 08:18:20 UTC
Created attachment 1862565 [details]
page after changing IPv{4,6} to manual

Hello peyu, thanks for your report! I tried to reproduce this.

> 5. Configure the NIC with IPv4 and IPv6 with "Manual" type and fill in the IP address
> 6. Click the "Change the settings" button in the "Connection will be lost" dialog that pops up

I changed an "inactive" eth card to IPv4 "manual" with 1.2.3.4/24 and gw 1.2.3.1, then clicked "change the settings".
I then changed the IPv6 settings of the same card to "manual" with "ab12::2/32" and gw ab12::1, again clicked "change settings.
(These are completely bogus addresses of course)

> 7. Check the type of IPv4 and IPv6

This worked fine:

    IPv4:  Address 1.2.3.4/24 via 1.2.3.1
    IPv6:  Address ab12:0:0:0:0:0:0:2/32 via ab12:0:0:0:0:0:0:1

(See attached screenshot)

This was kept even after a page reload, and `nmcli con show 'System eth1'` agrees:

ipv4.method:                            manual
ipv4.dns:                               --
ipv4.addresses:                         1.2.3.4/24
ipv4.gateway:                           1.2.3.1

ipv6.method:                            manual
ipv6.dns:                               --
ipv6.addresses:                         ab12::2/32
ipv6.gateway:                           ab12::1


> 8. Switch the settings from "Manual" type back to "Automatic"/or other type 

I switched back to "Automatic", first with keeping the additional manual address. Then again with dropping it, so that both are only "Automatic". I also tried "Link local" and "Disabled", both worked.

I use the same version as you (cockpit-system-261-1.el8.noarch).

So there must be something subtly different. Most probably NetworkManager runs into some error and does not accept the new settings.

Can you please try this again, and capture

   journalctl --since '10 minutes ago' > /tmp/journal.txt

after the issue happens, and attach /tmp/journal.txt here? It's also worth opening the developer console (Ctrl+Shift+J) and watch out for errors/warnings when that happens.

Thanks!

Comment 5 Martin Pitt 2022-02-23 03:35:30 UTC
Thanks! This confirms that it's an unintended checkpoint rollback. I.e. the same root cause as bug #2056386, just that this is harder for me to reproduce.

Marius is working on the other one, and this is almost surely going to be addressed by the same fix.

Comment 6 Martin Pitt 2022-02-23 14:18:38 UTC
Marking this as a duplicate for now, as the other bug has a bit more state.

*** This bug has been marked as a duplicate of bug 2056386 ***


Note You need to log in before you can comment on or make changes to this bug.