Bug 1373134

Summary: initial-setup doesn't run on ARM with: "pyanaconda.nm.SettingsNotFoundError: SettingsNotFoundError('eth0',)"
Product: [Fedora] Fedora Reporter: Jan Sedlák <jsedlak>
Component: initial-setupAssignee: Martin Kolman <mkolman>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 25CC: gmarr, jsedlak, mkolman, robatino, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: armhfp   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-13 01:44:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1277287    
Description Flags
program.log none

Description Jan Sedlák 2016-09-05 10:32:02 UTC
Created attachment 1197843 [details]

Description of problem:
When testing Fedora-25-20160904.n.0 compose on ARM from Fedora-Minimal-armhfp-25-20160904.n.0-sda.raw image, initial-setup doesn't start (so user is unable to set root password and create normal user). It shows python traceback and then goes directly to login prompt. Traceback:

Traceback (most recent call last):
  File "/usr/libexec/initial-setup/initial-setup-text", line 8, in <module>
  File "/usr/lib/python3.5/site-packages/initial_setup/__init__.py", line 304, in run
  File "/usr/lib/python3.5/site-packages/pyanaconda/ui/tui/__init__.py", line 178, in setup
    should_schedule = obj.setup(self.ENVIRONMENT)
  File "/usr/lib/python3.5/site-packages/pyanaconda/ui/tui/hubs/__init__.py", line 65, in setup
  File "/usr/lib/python3.5/site-packages/pyanaconda/ui/tui/spokes/network.py", line 61, in initialize
  File "/usr/lib/python3.5/site-packages/pyanaconda/ui/tui/spokes/network.py", line 78, in _load_new_devices
    if nm.nm_device_setting_value(name, "connection", "slave-type"):
  File "/usr/lib/python3.5/site-packages/pyanaconda/nm.py", line 778, in nm_device_setting_value
    raise SettingsNotFoundError(name)
pyanaconda.nm.SettingsNotFoundError: SettingsNotFoundError('eth0',)

See this run in openQA: https://openqa.fedoraproject.org/tests/32103#step/install_arm_image_deployment/18

Version-Release number of selected component (if applicable):

Comment 1 Jan Sedlák 2016-09-05 10:32:21 UTC
Created attachment 1197844 [details]

Comment 2 Jan Sedlák 2016-09-05 10:34:08 UTC
This doesn't seem to happen on KDE where initial-setup runs without problem (but it shows only spoke for creating user, no network spoke).

Comment 3 Jan Sedlák 2016-09-05 10:35:06 UTC
Note that bug 1371338 may be related.

Comment 4 Jan Sedlák 2016-09-05 10:51:58 UTC
I've tested it and it happens also on HW. From https://openqa.fedoraproject.org/tests/32103#previous it looks like that Fedora-25-20160904.n.0 was first compose where it happened. By looking at rpms.json it looks like version of anaconda and initial-setup stayed the same between Fedora-25-20160904.n.0 and Fedora-25-20160903.n.0.

Comment 5 Fedora Blocker Bugs Application 2016-09-05 10:58:28 UTC
Proposed as a Blocker for 25-beta by Fedora user jsedlak using the blocker tracking app because:

 Criterion says: On the first boot after installation, a utility for creating user accounts and other configuration may (may, not must) run prior to a log in screen appearing.

Although there is only "may", when first-boot utility doesn't start on ARM, user is completely unable to log in. When using pre-installed disk image (which is release-blocking), user didn't have a chance to set root password during installation.

Comment 6 Jan Sedlák 2016-09-05 11:08:16 UTC
OK, since text installation also doesn't work on newest compose, it's definitely related to bug 1371338.

If you are sure that this is caused by the same thing (so fixing anaconda text install will also fix initial-setup), mark this as duplicate.

Comment 7 Geoffrey Marr 2016-09-13 01:44:13 UTC

*** This bug has been marked as a duplicate of bug 1371338 ***