openQA NFS kickstart install tests with recent Rawhide nightlies sometimes die early, with a traceback displayed on the anaconda tmux pane. The traceback ends with this error:
Glib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.NetworkManager.Settings.Connection' on object at path /org/freedesktop/NetworkManager/Settings/2 (19)
This test passes 'inst.ks=nfs:10.0.2.110:/export/root-user-crypted-net.ks' as a kernel param, to load the kickstart from an NFS server. The kickstart itself looks like this:
network --device=link --activate --bootproto=dhcp
timezone --utc America/New_York
rootpw --iscrypted $6$ansiogjasd0io9u3$9E1vMbLbXW14grtguedFGVjvhyBz1T.KIA3MJl1SWnGbtTpiXIAjbazIQAUKRNkNIEmd3mI0NCkFIVBrN41fZ.
user --name=test --password=$6$ansioasgfgadsghd$O8O8zom5hx.V8ib1jV91xuvIgYqA2b99tzhibkk3URITdCrDtbRbwJjMK1kW4l0/9W0brraGC4NUBtDoGv4Kl. --iscrypted
Created attachment 1269091 [details]
Created attachment 1269092 [details]
Created attachment 1269093 [details]
Created attachment 1269094 [details]
Created attachment 1269095 [details]
/var/log (in a .tar.gz)
Also happens with other types of kickstart install too, apparently, e.g.:
That's install_kickstart_firewall_configured , where the kickstart is retrieved via HTTP - inst.ks=http://fedorapeople.org/groups/qa/kickstarts/firewall-configured-net.ks .
Seems to be the same issue as bug 1439051. Probably caused by changes in new NM (bug 1394579). I am going to post a patch handling the exception shortly but handling the changes in anaconda will require some deeper review.
This also appears to be happening to some F26 installs, so nominating as a Beta blocker: it's a conditional violation of Alpha criterion "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account." - https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria#scripted-user-creation - as this basically seems to manifest as 'kickstart installs sometimes fail'.
Note to self: revert the createhdds workaround for this when it's fixed in f26 stable.
Discussed during the 2017-04-10 blocker review meeting: 
The decision to classify this bug as an AcceptedBlocker was made as it violates the following criteria:
"The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account."
(In reply to Radek Vykydal from comment #7)
> Seems to be the same issue as bug 1439051. Probably caused by changes in new
> NM (bug 1394579). I am going to post a patch handling the exception shortly
> but handling the changes in anaconda will require some deeper review.
The NM changes have been modified in bug 1443878 to support installer use case better.
Adam, I strongly believe the issues described in this bug (the traceback) were fixed in bug 1439051 so I am marking this one as a duplicate. Do you agree or does it need further verification?
Still, we need to make sure that NM updates donw for the same issue in RHEL 7 make it into F26 (https://bugzilla.redhat.com/show_bug.cgi?id=1443878#c8)
*** This bug has been marked as a duplicate of bug 1439051 ***
Radek: Well, I haven't seen *this* traceback in any kickstart tests lately, yeah. For the last few days, though, some of them seem to be failing with a different error:
still, haven't seen this one, so it's probably fixed.