Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1755580 - initial-setup.service not activating in device with gsm module
Summary: initial-setup.service not activating in device with gsm module
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initial-setup
Version: 31
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Martin Kolman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2019-09-25 18:19 UTC by nicolasoliver03
Modified: 2019-10-07 00:02 UTC (History)
5 users (show)

Fixed In Version: initial-setup-0.3.76-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-07 00:02:06 UTC
Type: Bug


Attachments (Terms of Use)
Output of journalctl --unit initial-setup.out (148.35 KB, text/plain)
2019-09-25 18:19 UTC, nicolasoliver03
no flags Details
full journalctl output (246.71 KB, text/plain)
2019-09-26 15:10 UTC, Paul Whalen
no flags Details

Description nicolasoliver03 2019-09-25 18:19:00 UTC
Created attachment 1619200 [details]
Output of journalctl --unit initial-setup.out

Description of problem:
In Fedora IoT, initial-setup.service is blocking systemd initialization on the Compulab Fitlet2 with GSM module. Works fine in a Fitlet2 that does not have a GSM module. 

Version-Release number of selected component (if applicable):
rpm -qa initial-setup
  initial-setup-0.3.73-1.fc31.x86_64

rpm-ostree status 
  ● ostree://fedora-iot:fedora/devel/x86_64/iot
                   Version: 31.20190925.0 (2019-09-25T14:30:38Z)
                    Commit: 8f28d65fa990add14ccf56c00c458e9d6a4af478bbeb4cc566903ad0c14a443f
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

How reproducible:
Install the Fedora IoT version specified above in a Compulab Fitlet2 with GSM module. In the first boot, the initial-setup prompt will appear, and will not respond to the user inputs. The initial-setup service will stay in activating phase indefinitely  

Steps to Reproduce:
1. In a Compulab Fitlet2 with GSM, install Fedora IoT 31.20190925.0
2. After installation, wait until the initil-setup prompt appear
3. Try to interact with the prompt, it will not go away

Actual results:
The user cannot continue once the initial-setup prompt appears

Expected results:
The user should be able to 'c' and continue with the normal boot

Additional info:

Comment 1 Martin Kolman 2019-09-26 10:19:22 UTC
Indeed, one of the last messages before the Initial Setup process crashes is network related:

Sep 25 10:16:24 fedora-iot-2 initial-setup[744]: starting the UI
Sep 25 10:16:24 fedora-iot-2 anaconda[744]: simpleline: Starting main loop
Sep 25 10:16:24 fedora-iot-2 anaconda[744]: simpleline: Processing screen ScreenData(InitialSetupMainHub,None,False)
Sep 25 10:16:24 fedora-iot-2 anaconda[744]: simpleline: Input is required by ScreenData(InitialSetupMainHub,None,False) screen
Sep 25 10:16:35 fedora-iot-2 org.fedoraproject.Anaconda.Modules.Network[874]: DEBUG:anaconda.modules.network.device_configuration:NM device added: cdc-wdm0
Sep 25 10:16:35 fedora-iot-2 org.fedoraproject.Anaconda.Modules.Network[874]: DEBUG:anaconda.modules.network.device_configuration:add_device: not adding cdc-wdm0: unsupported type
Sep 25 10:16:55 fedora-iot-2 systemd[1]: initial-setup.service: Main process exited, code=killed, status=15/TERM
Sep 25 10:16:55 fedora-iot-2 systemd[1]: initial-setup.service: Failed with result 'signal'.
Sep 25 10:16:55 fedora-iot-2 systemd[1]: Stopped Initial Setup configuration program.

But the weird thing is that there is no further information other than "Main process exited, code=killed, status=15/TERM" - could you perhaps also attach a full journal log (potentially sanitized), not just the output of the initial-setup.service ? Could be the traceback or other relevant data ended up not registered as output of the initial-setup.service unit. Thanks in advance! :)

Comment 2 Paul Whalen 2019-09-26 15:10:10 UTC
Created attachment 1619627 [details]
full journalctl output

full journalctl output attached.

Comment 3 Paul Whalen 2019-09-26 15:14:22 UTC
From journalctl:

Sep 26 10:05:01 fitlet2 ModemManager[777]: <warn>  Modem couldn't be initialized: Couldn't check unlock status: Couldn't get SIM lock status after 6 retries
Sep 26 10:05:01 fitlet2 ModemManager[777]: <info>  Modem: state changed (unknown -> failed)
Sep 26 10:05:01 fitlet2 NetworkManager[849]: <info>  [1569510301.1395] manager: (cdc-wdm0): new Broadband device (/org/freedesktop/NetworkManager/Devices/6)
Sep 26 10:05:01 fitlet2 NetworkManager[849]: <info>  [1569510301.1409] device (cdc-wdm0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Sep 26 10:05:01 fitlet2 NetworkManager[849]: <info>  [1569510301.1417] device (cdc-wdm0): modem state 'failed'
Sep 26 10:05:01 fitlet2 NetworkManager[849]: <info>  [1569510301.1433] modem-broadband[cdc-wdm0]: failed to retrieve SIM object: No SIM object available
Sep 26 10:05:01 fitlet2 org.fedoraproject.Anaconda.Modules.Network[939]: DEBUG:anaconda.modules.network.device_configuration:NM device added: cdc-wdm0
Sep 26 10:05:01 fitlet2 org.fedoraproject.Anaconda.Modules.Network[939]: DEBUG:anaconda.modules.network.device_configuration:add_device: not adding cdc-wdm0: unsupported type

Comment 4 Martin Kolman 2019-09-26 15:34:13 UTC
(In reply to Paul Whalen from comment #2)
> Created attachment 1619627 [details]
> full journalctl output
> 
> full journalctl output attached.

Thanks for the full log! But still, I'm confused - while there is the same "not adding cdc-wdm0: unsupported type" as the last line coming from Initial Setup, I can't see the service being killed ("initial-setup.service: Main process exited, code=killed, status=15/TERM") anywhere, as in the previous log excerpt.

While indeed, it looks like this is all related to the GSM module and how the TUI Network spoke interacts with it when enumerating network devices via Network Manager/Modem Manager, I'm still missing any pointers how that leads to the Initial Setup process getting killed.

Comment 5 nicolasoliver03 2019-10-02 17:18:34 UTC
I have updated my system to the latest Fedora IoT compose, it is still running into the same issue

ostree://fedora-iot:fedora/devel/x86_64/iot
                 Version: 31.20190925.0 (2019-09-25T14:30:38Z)
              BaseCommit: 8f28d65fa990add14ccf56c00c458e9d6a4af478bbeb4cc566903ad0c14a443f
            GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

The same error message is printed: not adding cdc-wdm0: unsupported type

Comment 6 Fedora Update System 2019-10-03 18:57:03 UTC
FEDORA-2019-ae6daeb206 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ae6daeb206

Comment 7 Martin Kolman 2019-10-03 19:29:49 UTC
So for the record, this was caused by the ttyUSB0-4 consoles the GSM module creates. Initial Setup tried to use them as normal user facing consoles but they apparently were not ready for that, likely started blocking, thus freezing the Initial Setup text interface on the other actual user facing console.

I've fixed it for now by blacklisting the ttyUSB0-4 consoles from being used by Initial Setup. This should be good for now, but a more robust solution might be needed if someone actually has a user facing console on ttyUSB and wants to use it.

PR with the fix can be found here:
https://github.com/rhinstaller/initial-setup/pull/77

Comment 8 Paul Whalen 2019-10-03 23:56:41 UTC
Verified fixed in initial-setup-0.3.75-1.fc31.

Comment 9 nicolasoliver03 2019-10-04 17:07:16 UTC
Thank you! it works now with the following Fedora IoT ostree:

● ostree://fedora-iot:fedora/devel/x86_64/iot
                   Version: 31.20191003.0 (2019-10-03T22:42:38Z)
                BaseCommit: 4e860662b94949218466e7d4a9f3bbe3a2c309af99ab7c4a82df47b84321f5b8
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

Comment 10 Fedora Update System 2019-10-04 22:50:33 UTC
anaconda-31.22.6-1.fc31, initial-setup-0.3.76-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-ae6daeb206

Comment 11 Fedora Update System 2019-10-07 00:02:06 UTC
anaconda-31.22.6-1.fc31, initial-setup-0.3.76-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.


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