Created attachment 1588363 [details] journal from the installation Description of problem: Network device configured by kickstart is activated in installer irrespectively of its --activate / --no-activate option Version-Release number of selected component (if applicable): Fedora-Rawhide-20190707.n.0 NetworkManager-1.20.0-0.3.fc31 (seems not to be problem in NetworkManager-1.20.0-0.2.fc31) How reproducible: Always Steps to Reproduce: 1. Install with a network device (additionally to another one, used during installation, eg with boot options ip=ens3:dhcp) configured in kickstart so that it is not activated in installer, eg: network --device ens10 --bootproto static --ip 192.168.122.234 --netmask 255.255.255.0 --gateway 192.168.122.255 --nameserver 10.34.39.2 --no-activate --onboot yes 2. 3. Actual results: The device ens10 is activated in installer (after switch root) using default autoconnection. Expected results: The device ens10 is not activated in installer (honoring --no-activate option). Additional info: Seems to be related to the changes from integration of NetworkManager in initramfs, but by some later patches? (see the versions above). Maybe ifcfg file with ONBOOT=no created in initramfs based on kickstart and passed during switch root (which is still happening now) used to prevent NM from creating and activating default autoconnection which is no more true currently (restart of NM after start in initramfs makes a difference?).
The case from the description seems to be fixed with NetworkManager-1.20.0-0.5.fc31. I'll check similar cases from our kickstart tests suite.
(In reply to Radek Vykydal from comment #1) > The case from the description seems to be fixed with > NetworkManager-1.20.0-0.5.fc31. > I'll check similar cases from our kickstart tests suite. The case is fixed but when using --bindto=mac: network --device ens10 --bootproto static --ip 192.168.122.234 --netmask 255.255.255.0 --gateway 192.168.122.255 --nameserver 10.34.39.2 --no-activate --onboot yes --bindto=mac it is failing as described in the description (the device is activated). The --bindto=mac option is for binding the ifcfg file to hw address (using HWADDR instead of DEVICE). In the default case, this existing ifcfg (/etc/sysconfig/network-scripts/ifcfg-ens10) generated in initramfs by anaconda from kickstart: # Generated by parse-kickstart TYPE="Ethernet" DEVICE="ens10" UUID="9cd57024-6b02-4757-b264-c3680c924d44" ONBOOT="no" BOOTPROTO="static" IPADDR="192.168.122.234" NETMASK="255.255.255.0" GATEWAY="192.168.122.255" IPV6INIT="yes" DNS1="10.34.39.2" prevents generating (and generating) connetion "Wired connection 1" by NM for ens10. In the --bindto=mac case this ifcfg file (using HWADDR instead of DEVICE) does not: # Generated by parse-kickstart TYPE="Ethernet" HWADDR="52:54:00:99:c2:ee" UUID="939e84c6-f6e7-4fa4-a05e-f982e847fb74" ONBOOT="no" BOOTPROTO="static" IPADDR="192.168.122.234" NETMASK="255.255.255.0" GATEWAY="192.168.122.255" IPV6INIT="yes" DNS1="10.34.39.2"
Created attachment 1601311 [details] logs from the default case from comments #2
Created attachment 1601312 [details] logs from the --bindto=mac case from comment #2
(In reply to Radek Vykydal from comment #2) > prevents generating (and generating) connetion "Wired connection 1" by NM prevents generating (and activating) ...
Thomas, any idea how we could approach the change in comment #2?
(In reply to Radek Vykydal from comment #6) > Thomas, any idea how we could approach the change in comment #2? it's just a bug. Let's fix it!! https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/232 Feel free to reassign to NetworkManager, if you don't need the BZ.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
fixed upstream: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/232
FEDORA-2019-998f473be9 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-998f473be9
NetworkManager-1.20.4-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-998f473be9
I checked NetworkManager-1.20.4-1.fc32 in rawhide compose and the issue from comment #2 seems to be fixed. Thank you.
(In reply to Radek Vykydal from comment #13) > I checked NetworkManager-1.20.4-1.fc32 in rawhide compose and the issue from > comment #2 seems to be fixed. Thank you. For the reference, these kickstart tests were fixed as expected: bindtomac-network-static-2-httpks bindtomac-onboot-activate-httpks bindtomac-bridge-2devs-https On the other hand, one test started failing: network-autoconnections-dhcpall-httpks I filed bug 1758468 for the issue.
NetworkManager-1.20.4-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.