Bug 1439388 - Kickstart installs sometimes die with traceback ending in gdbus error
Summary: Kickstart installs sometimes die with traceback ending in gdbus error
Keywords:
Status: CLOSED DUPLICATE of bug 1439051
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F26BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2017-04-05 21:31 UTC by Adam Williamson
Modified: 2017-05-03 02:18 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-28 09:02:37 UTC


Attachments (Terms of Use)
anaconda.log (1.84 KB, text/plain)
2017-04-05 21:36 UTC, Adam Williamson
no flags Details
program.log (986 bytes, text/plain)
2017-04-05 21:38 UTC, Adam Williamson
no flags Details
storage.log (255 bytes, text/plain)
2017-04-05 21:39 UTC, Adam Williamson
no flags Details
syslog (258.06 KB, text/plain)
2017-04-05 21:39 UTC, Adam Williamson
no flags Details
/var/log (in a .tar.gz) (2.45 KB, application/x-gzip)
2017-04-05 21:39 UTC, Adam Williamson
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1439051 None None None Never

Internal Links: 1439051

Description Adam Williamson 2017-04-05 21:31:08 UTC
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

Comment 1 Adam Williamson 2017-04-05 21:36:31 UTC
Created attachment 1269091 [details]
anaconda.log

Comment 2 Adam Williamson 2017-04-05 21:38:26 UTC
Created attachment 1269092 [details]
program.log

Comment 3 Adam Williamson 2017-04-05 21:39:07 UTC
Created attachment 1269093 [details]
storage.log

Comment 4 Adam Williamson 2017-04-05 21:39:23 UTC
Created attachment 1269094 [details]
syslog

Comment 5 Adam Williamson 2017-04-05 21:39:48 UTC
Created attachment 1269095 [details]
/var/log (in a .tar.gz)

Comment 6 Adam Williamson 2017-04-06 03:14:39 UTC
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 .

Comment 7 Radek Vykydal 2017-04-06 10:10:18 UTC
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.

Comment 8 Adam Williamson 2017-04-06 23:14:22 UTC
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'.

Comment 9 Adam Williamson 2017-04-08 03:13:00 UTC
Note to self: revert the createhdds workaround for this when it's fixed in f26 stable.

Comment 10 Geoffrey Marr 2017-04-10 20:21:44 UTC
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

Comment 11 Radek Vykydal 2017-04-25 11:43:29 UTC
(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.

Comment 12 Radek Vykydal 2017-04-28 09:02:37 UTC
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 ***

Comment 13 Adam Williamson 2017-05-03 02:18:32 UTC
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.


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