Created attachment 1591947 [details]
/tmp/program.log

Created attachment 1591948 [details]
/tmp/dbus.log

Created attachment 1591949 [details]
journalctl dump

This is the journalctl content of the affected system.

I filtered out all the lines like "kernel: bcm2835-dma 3f007000.dma: vchan f0a0ec46: txd d4d7eed2[31ef]: submitted", that are flooding the journal, but it is something else.

Proposed as a Blocker for 31-beta by Fedora user alciregi using the blocker tracking app because:

 Installation interfaces
When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. 

or

Installation interfaces
The installer must be able to complete an installation using the serial console interface.

I have found that My Rpi3B+ microSD is so flooded by the debug kernel messages (2) that it freezes up.
Peter says the tuesday arm spins will use a nodebug kernel (1) (trying to access the network tui may have caused a timeout)
(1):https://fedoraproject.org/wiki/RawhideKernelNodebug 
(2):"kernel: bcm2835-dma 3f007000.dma: vchan f0a0ec46: txd d4d7eed2[31ef]: submitted"

Discussed during the 2019-07-29 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" was made as the network spoke not working in itself is not a blocker per the criteria (so long as user and root spokes work). Testing during the meeting by multiple testers did not reproduce the bug or find any criteria-violating cases in other scenarios.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-07-29/f31-blocker-review.2019-07-29-16.02.txt

Maybe this should be reassigned to kernel ? If it worked before & the flooding described in comment 5 seem to indicate kernel issues rather than something related to Initial Setup itself.

(In reply to Martin Kolman from comment #7)
> Maybe this should be reassigned to kernel ? If it worked before & the
> flooding described in comment 5 seem to indicate kernel issues rather than
> something related to Initial Setup itself.

I think that the flooding is not related to this issue. If I don't select the network spoke I'm able to complete the installation and to login. And the flooding is still here.

If you look at the end of the attached journalct dump, you can see that there is a python "crash" related to the setup program.

FWIW I can't test again such device, maybe with a newer image, until the next week.

Thanks.

Tested this with a RasPi 3B+ and Fedora-Minimal-armhfp-Rawhide-20190717.n.0-sda.raw.xz. While the kernel messages are annoying, I was able to use the network spoke to configure the network and finish the install.

Just tested this with the latest rawhide release, Fedora-Minimal-armhfp-Rawhide-20190730.n.0-sda.raw.xz and a RasPi 3B+ and had no kernel messages appear and the network spoke worked just fine. Without looking at logs, I would consider this fixed/non-issue as there is no flooding of kernel messages anymore and the network spoke is working like it should.

Alessio, can you confirm the latest rawhide release fixes your original issue? If not, can you provide us with more information regarding the error?

(In reply to Geoffrey Marr from comment #11)
> Alessio, can you confirm the latest rawhide release fixes your original
> issue? If not, can you provide us with more information regarding the error?

Sorry but I don't have access to the device until Monday.
All the information I can provide is attached here.
BTW if you would like to close the bug,I will eventually reopen it if I continue to experience such issue.

Thanks.

Ok.
I just tested Fedora-Minimal-armhfp-Rawhide-20190802.n.1-sda.raw.xz and all works as expected.
Thanks and sorry for the trouble.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Using Fedora-Minimal-armhfp-31-20190905.n.0-sda.raw.xz
I encounter this problem again.

I inserted the SD card in my PC. Looking at /run/media/alessio/__/tmp/anaconda.log, these are the latest lines.

...
05:32:36,956 ERR ui.tui: 
======= Screen stack =======
----------- TOP ------------
ScreenData(NetworkSpoke,None,False)
ScreenData(InitialSetupMainHub,None,False)
============================


And this is from journalctl

...

Sep 03 11:28:37 localhost initial-setup[739]: setting up the UI
Sep 03 11:28:37 localhost anaconda[739]: anaconda: threading: Running Thread: initial_setup_multi_tty_thread (2977989728)
Sep 03 11:28:37 localhost initial-setup[739]: multi TTY handler starting
Sep 03 11:28:37 localhost anaconda[739]: simpleline: GLib event loop is used!
Sep 03 11:28:40 localhost anaconda[739]: anaconda: ui.tui.hubs: Initialization controller for hub InitialSetupMainHub expected but missing.
Sep 03 11:28:40 localhost anaconda[739]: simpleline: Scheduling screen InitialSetupMainHub
Sep 03 11:28:40 localhost anaconda[739]: simpleline: New signal RenderScreenSignal enqueued with source ScreenScheduler
Sep 03 11:28:40 localhost initial-setup[739]: starting the UI
Sep 03 11:28:40 localhost anaconda[739]: simpleline: Starting main loop
Sep 03 11:28:40 localhost anaconda[739]: simpleline: Processing screen ScreenData(InitialSetupMainHub,None,False)
Sep 03 11:28:40 localhost anaconda[739]: simpleline: Input is required by ScreenData(InitialSetupMainHub,None,False) screen
Sep 03 11:32:36 localhost anaconda[739]: simpleline: New signal InputReceivedSignal enqueued with source InputHandlerRequest
Sep 03 11:32:36 localhost anaconda[739]: simpleline: New signal InputReadySignal enqueued with source InitialSetupMainHub
Sep 03 11:32:36 localhost anaconda[739]: simpleline: Pushing screen NetworkSpoke to stack
Sep 03 11:32:36 localhost anaconda[739]: simpleline: New signal RenderScreenSignal enqueued with source ScreenScheduler
Sep 03 11:32:36 localhost anaconda[739]: simpleline: Processing screen ScreenData(NetworkSpoke,None,False)
Sep 03 11:32:36 localhost anaconda[739]: simpleline: New signal ExceptionSignal enqueued with source ScreenScheduler
Sep 03 11:32:36 localhost anaconda[739]: simpleline: Executing inner loop
Sep 03 11:32:36 localhost anaconda[739]: simpleline: New signal ExceptionSignal enqueued with source ScreenScheduler
Sep 03 11:32:36 localhost anaconda[739]: anaconda: ui.tui: 
                                         ======= Screen stack =======
                                         ----------- TOP ------------
                                         ScreenData(NetworkSpoke,None,False)
                                         ScreenData(InitialSetupMainHub,None,False)
                                         ============================
Sep 03 11:32:36 localhost initial-setup[739]: Initial Setup crashed due to unhandled exception:
                                              Traceback (most recent call last):
                                                File "/usr/lib/python3.7/site-packages/simpleline/render/screen_scheduler.py", line 234, in _process_screen
                                                  top_screen.ui_screen.refresh(top_screen.args)
                                                File "/usr/lib/python3.7/site-packages/pyanaconda/ui/tui/spokes/network.py", line 312, in refresh
                                                  summary = self._summary_text()
                                                File "/usr/lib/python3.7/site-packages/pyanaconda/ui/tui/spokes/network.py", line 263, in _summary_text
                                                  msg += self._activated_device_msg(name)
                                                File "/usr/lib/python3.7/site-packages/pyanaconda/ui/tui/spokes/network.py", line 288, in _activated_device_msg
                                                  {"addr": addr_str, "netmask": netmask_str, "gateway": gateway_str}
                                              UnboundLocalError: local variable 'addr_str' referenced before assignment
...

The issue from comment #16 should be fixed by https://github.com/rhinstaller/anaconda/pull/2120

Proposed as a Freeze Exception for 31-beta by Fedora user rvykydal using the blocker tracking app because:

 Safe isolated fix making Network Configuration of Fedora-Minimal-armhfp-Rawhide in initial setup work again (with F31 Beta)

+1 FE, for me.

FEDORA-2019-2cabc3f936 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2cabc3f936

anaconda-31.22.4-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-2cabc3f936

Ok.
Using Fedora-Minimal-armhfp-31-20190919.n.1-sda.raw.xz I ignored network part during initial setup. Configured the network, updated anaconda-tui via dnf. Then I issued systemctl enable initial-setup and finally reboot.
Now option 3 (network configuration) works.

(In reply to Alessio from comment #22)
> Ok.
> Using Fedora-Minimal-armhfp-31-20190919.n.1-sda.raw.xz I ignored network
> part during initial setup. Configured the network, updated anaconda-tui via
> dnf. Then I issued systemctl enable initial-setup and finally reboot.
> Now option 3 (network configuration) works.

Nice! BTW, if possible also check the Bodhi update (linked in comment 21) & give it karma, so that it can go stable soon. :)

(In reply to Martin Kolman from comment #23)
> give it karma, so that it can go stable soon. :)

Done! :-)
Thank you.

anaconda-31.22.4-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.