(In reply to Radek Vykydal from comment #0)

> Additional info:
> 
> My suspicion: seems to be a regression of this very build related to changes
> in 
> bug 1727909, https://bugzilla.redhat.com/show_bug.cgi?id=1727909#c10

Looking at the patch briefly:

Previously the autoconnection was not created if there was (from initramfs) (1) a profile tied by DEVICE; we wanted it not to be created also if (2) there is a connection mac-locked to the device but we didn't expect it not to be created if (3) there is generic "Wired Connection" for the device, ie https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/232/diffs#c698d5a519a577dbdef160d0ea5a67db9bf3fdf5_3407_3376 ?

I am not quite sure now if (3) is desired behaviour or not. While adapting to changes by NM in initramfs the autoconnections were convenient for Anaconda to use in this case (as a base for persistent connections created in installer) but we should be able to handle this approach (3) as well because we have to do it when autoconnections are turned off in general (in network configuration as it is currently the case in RHEL) - in this case we just create default persistent connections on our own. Which brings me to a question - is there a way to create a connection that would be the same (regarding the settings) as default auto-connection ? Or actually create default auto-connection on demand ?

It seems that any other kickstart tests than the one checking the connections created by NM didn't start failing so if needed we should be able to cope with (3).

(In reply to Radek Vykydal from comment #0)

> Steps to Reproduce:
> 1. Run installation with 3 network devices 
> - boot options: ip=dhcp:all

should be ip=dhcp

>  (3) there is generic "Wired Connection" for the device

There is nothing special about this "generic" connection "Wired Connection" 8c71049d-32a3-4feb-b940-04af2b25bfc7.

what is a bit unusual, 

  - it is not restricted to a particular device (no "connection.interface-name", "match.interface-names", "ethernet.mac-address")
  - it has "connection.multi-connect" enabled, hence this profile can be active on multiple devices at the same time
  - it is an in-memory connection stored in /run/NetworkManager/system-connections (as you see with `nmcli -f all connection`)




I think with the fix for bug 1727909, this is the desired behaviour. Yes, it's a change in behaviour, but I would say, that it is merely a bugfix. I don't think that the previous behaviour was desirable (neither for bug 1727909, nor for this bug).

Of course, even if I consider this a good bug fix, it is still a problematic change in behaviour (keyword: "bug compatible"), and hence a different solution may be needed (although I don't think so).



> is there a way to create a connection that would be the same (regarding the settings) as default auto-connection ? Or actually create default auto-connection on demand ?

There is no way to trigger the creation of these "Wired connection #" (auto-default) connections. But there isn't anything special about them either, and you can use regular "AddConnection2()" API to create them (see [1]).

The parameters of the default-wired-connection are pretty staightforward. See [2].


Also, default-wired-connection is also in-memory (/run/NetworkManager/system-connection), so depending on what anaconda wants, you also want to create the profile in-memory (with AddConnection2()).



Note that AddConnection2() was only introduced in 1.20 [1]. So, if you want to target older NetworkManager server versions, you need to:

- there are older variants of AddConnection2(): AddConnection() and AddConnectionUnsaved(). These are a subset of what AddConnection2() can do. If you don't need any of the features from AddConnection2(), then the older API can be used.

- if you use libnm 1.20, then nm_remote_settings_add_connection2() will automatically use older D-Bus server API, if the arguments don't request any feature that is only available in AddConnection2(). Note that this implies that anaconda would already require libnm >= 1.20, but support talking to a NetworkManager server version < 1.20.



[1] https://developer.gnome.org/NetworkManager/unstable/gdbus-org.freedesktop.NetworkManager.Settings.html#gdbus-method-org-freedesktop-NetworkManager-Settings.AddConnection2

[2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device-ethernet.c?id=5a24ad53ad241059cf70b6593454fc124520405d#n1418

(In reply to Thomas Haller from comment #3)

> I think with the fix for bug 1727909, this is the desired behaviour. Yes,
> it's a change in behaviour, but I would say, that it is merely a bugfix. I
> don't think that the previous behaviour was desirable (neither for bug
> 1727909, nor for this bug).

I agree.

> Of course, even if I consider this a good bug fix, it is still a problematic
> change in behaviour (keyword: "bug compatible"), and hence a different
> solution may be needed (although I don't think so).
> 

Okay, I am moving this BZ to anaconda and updating our test.

> 
> 
> > is there a way to create a connection that would be the same (regarding the settings) as default auto-connection ? Or actually create default auto-connection on demand ?
> 
> There is no way to trigger the creation of these "Wired connection #"
> (auto-default) connections. But there isn't anything special about them
> either, and you can use regular "AddConnection2()" API to create them (see
> [1]).
> 
> The parameters of the default-wired-connection are pretty staightforward.
> See [2].

Yes, my point was getting the parameters somehow dynamically from NM, to be consistent when creating default connections by Anaconda.
 
Thank you for the hints on the API compatibility. Anaconda either has the sufficient version in installer image, or on existing system it does not do network configuration.

https://github.com/rhinstaller/kickstart-tests/pull/297

Fixed in tests.