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) See e.g.: https://openqa.stg.fedoraproject.org/tests/88187 https://openqa.stg.fedoraproject.org/tests/89133 https://openqa.stg.fedoraproject.org/tests/91557 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: install bootloader --location=mbr network --device=link --activate --bootproto=dhcp url --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch lang en_US.UTF-8 keyboard us timezone --utc America/New_York clearpart --all autopart rootpw --iscrypted $6$ansiogjasd0io9u3$9E1vMbLbXW14grtguedFGVjvhyBz1T.KIA3MJl1SWnGbtTpiXIAjbazIQAUKRNkNIEmd3mI0NCkFIVBrN41fZ. user --name=test --password=$6$ansioasgfgadsghd$O8O8zom5hx.V8ib1jV91xuvIgYqA2b99tzhibkk3URITdCrDtbRbwJjMK1kW4l0/9W0brraGC4NUBtDoGv4Kl. --iscrypted reboot %packages @core %end
Created attachment 1269091 [details] anaconda.log
Created attachment 1269092 [details] program.log
Created attachment 1269093 [details] storage.log
Created attachment 1269094 [details] syslog
Created attachment 1269095 [details] /var/log (in a .tar.gz)
Also happens with other types of kickstart install too, apparently, e.g.: https://openqa.fedoraproject.org/tests/76229 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: [1] 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." [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-04-10/f26-blocker-review.2017-04-10-16.01.txt
(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: https://openqa.fedoraproject.org/tests/89073#step/_boot_to_anaconda/8 still, haven't seen this one, so it's probably fixed.