Bug 1731415 - Network spoke doesn't work on RPi3 initial-setup
Summary: Network spoke doesn't work on RPi3 initial-setup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initial-setup
Version: 31
Hardware: armv7hl
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Kolman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks: F31BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2019-07-19 11:11 UTC by Alessio
Modified: 2019-09-21 00:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-21 00:02:29 UTC
Type: Bug


Attachments (Terms of Use)
/tmp/anaconda.log (3.39 KB, text/plain)
2019-07-19 11:11 UTC, Alessio
no flags Details
/tmp/program.log (1.59 KB, text/plain)
2019-07-19 11:12 UTC, Alessio
no flags Details
/tmp/dbus.log (2.42 KB, text/plain)
2019-07-19 11:12 UTC, Alessio
no flags Details
journalctl dump (156.05 KB, text/plain)
2019-07-19 11:17 UTC, Alessio
no flags Details

Description Alessio 2019-07-19 11:11:39 UTC
Created attachment 1591946 [details]
/tmp/anaconda.log

Fedora-Minimal-armhfp-Rawhide-20190717.n.0-sda.raw.xz as well as 20190711 compose.

Using serial console as well as a screen and a keyboard.

Raspberry Pi 3 start ok.

Initial setup appears. All the spokes work as expected, but selecting "3) Network configuration", nothing happens and the setup stay stuck in this phase.

Comment 1 Alessio 2019-07-19 11:12:10 UTC
Created attachment 1591947 [details]
/tmp/program.log

Comment 2 Alessio 2019-07-19 11:12:41 UTC
Created attachment 1591948 [details]
/tmp/dbus.log

Comment 3 Alessio 2019-07-19 11:17:17 UTC
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.

Comment 4 Fedora Blocker Bugs Application 2019-07-19 11:21:54 UTC
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.

Comment 5 satellitgo 2019-07-27 23:23:25 UTC
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"

Comment 6 Geoffrey Marr 2019-07-29 18:25:08 UTC
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

Comment 7 Martin Kolman 2019-07-30 13:00:32 UTC
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.

Comment 8 Alessio 2019-07-30 16:12:25 UTC
(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.

Comment 9 Geoffrey Marr 2019-07-30 16:31:47 UTC
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.

Comment 10 Geoffrey Marr 2019-07-30 16:46:12 UTC
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.

Comment 11 Geoffrey Marr 2019-07-30 17:04:52 UTC
Alessio, can you confirm the latest rawhide release fixes your original issue? If not, can you provide us with more information regarding the error?

Comment 12 Alessio 2019-07-30 17:47:15 UTC
(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.

Comment 13 Alessio 2019-08-05 09:15:00 UTC
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.

Comment 14 Ben Cotton 2019-08-13 17:10:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 15 Ben Cotton 2019-08-13 18:33:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 16 Alessio 2019-09-06 13:55:01 UTC
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
...

Comment 17 Radek Vykydal 2019-09-09 07:42:11 UTC
The issue from comment #16 should be fixed by https://github.com/rhinstaller/anaconda/pull/2120

Comment 18 Fedora Blocker Bugs Application 2019-09-10 11:05:00 UTC
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)

Comment 19 Adam Williamson 2019-09-11 15:11:37 UTC
+1 FE, for me.

Comment 20 Fedora Update System 2019-09-17 00:36:52 UTC
FEDORA-2019-2cabc3f936 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2cabc3f936

Comment 21 Fedora Update System 2019-09-18 01:59:53 UTC
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

Comment 22 Alessio 2019-09-20 13:42:02 UTC
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.

Comment 23 Martin Kolman 2019-09-20 14:37:08 UTC
(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. :)

Comment 24 Alessio 2019-09-20 14:54:02 UTC
(In reply to Martin Kolman from comment #23)
> give it karma, so that it can go stable soon. :)

Done! :-)
Thank you.

Comment 25 Fedora Update System 2019-09-21 00:02:29 UTC
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.


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