Bug 1695967
| Summary: | initial-setup crashes with "ImportError: cannot import name 'setup_ifcfg_log' from 'pyanaconda.network'" (function was removed from anaconda) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||||
| Component: | initial-setup | Assignee: | Radek Vykydal <rvykydal> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 30 | CC: | mkolman, pwhalen, robatino, v.podzimek+fedora, vponcova | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | openqa AcceptedBlocker | ||||||||
| Fixed In Version: | initial-setup-0.3.69-1 initial-setup-0.3.69-1.fc30 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-04-11 02:13:55 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: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1574715 | ||||||||
| Attachments: |
|
||||||||
initial-setup-0.3.69-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ade3788aac initial-setup-0.3.69-1.fc30 has been pushed to the Fedora 30 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-ade3788aac Testing initial-setup-0.3.69-1.fc30, i-s starts but no spokes are visible. From the logs:
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: return get_variant(self.type_hint, self.get_data(obj))
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: File "/usr/lib/python3.7/site-packages/pyanaconda/dbus/typing.py", line 87, in get_variant
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: return Variant(get_dbus_type(type_hint), value)
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: File "/usr/lib/python3.7/site-packages/gi/overrides/GLib.py", line 172, in __new__
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: v = creator._create(format_string, value)
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: File "/usr/lib/python3.7/site-packages/gi/overrides/GLib.py", line 118, in _create
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: return self._LEAF_CONSTRUCTORS[format](value)
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: TypeError: Argument 0 does not allow None as a value
Apr 08 14:04:09 bpro org.fedoraproject.Anaconda.Modules.Network[851]: INFO:pydbus.registration:name is not registered
Apr 08 14:04:09 bpro initial-setup[694]: 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 265, in _draw_screen
active_screen.ui_screen.show_all()
File "/usr/lib/python3.7/site-packages/simpleline/render/screen/__init__.py", line 260, in show_all
self.window.render(App.get_configuration().width)
File "/usr/lib/python3.7/site-packages/simpleline/render/containers.py", line 210, in render
widget.render(width)
File "/usr/lib/python3.7/site-packages/simpleline/render/containers.py", line 280, in render
lines_per_rows = self._lines_per_every_row(ordered_map)
File "/usr/lib/python3.7/site-packages/simpleline/render/containers.py", line 309, in _lines_per_every_row
self._render_all_items()
File "/usr/lib/python3.7/site-packages/simpleline/render/containers.py", line 344, in _render_all_items
item.widget.render(item_width)
File "/usr/lib/python3.7/site-packages/pyanaconda/ui/tui/spokes/__init__.py", line 88, in render
title=_(self.title), text=self.status)
File "/usr/lib/python3.7/site-packages/pyanaconda/ui/tui/spokes/network.py", line 256, in status
return network.status_message(self.nm_client)
File "/usr/lib/python3.7/site-packages/pyanaconda/network.py", line 543, in status_message
if not get_supported_devices():
File "/usr/lib/python3.7/site-packages/pyanaconda/network.py", line 557, in get_supported_devices
for device in network_proxy.GetSupportedDevices()]
File "/usr/lib/python3.7/site-packages/pydbus/proxy_method.py", line 102, in __call__
raise error
pyanaconda.modules.common.errors.DBusError: Argument 0 does not allow None as a value
[root@bpro ~]# rpm -q initial-setup
initial-setup-0.3.69-1.fc30.armv7hl
[root@bpro ~]# rpm -qa|grep anaconda
anaconda-tui-30.25.4-1.fc30.armv7hl
anaconda-core-30.25.4-1.fc30.armv7hl
libreport-anaconda-2.10.0-1.fc30.armv7hl
Trying this on another system, it worked as expected (same disk image - Fedora-Minimal-armhfp-30-20190408.n.0-sda.raw.xz ):
1) [x] Language settings 2) [x] Time settings
(English (United States)) (America/New_York timezone)
3) [x] Network configuration 4) [x] Root password
(Wired (eth0) connected) (Password is set.)
5) [x] User creation
(Administrator pwhalen will be
created)
Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to
refresh]:
c
Fedora 30 (Thirty)
Kernel 5.0.5-300.fc30.armv7hl on an armv7l (ttyS1)
rpi3-1 login: root
Password:
Last login: Mon Apr 8 15:33:42 from 192.168.0.11
[root@rpi3-1 ~]# rpm -q initial-setup
initial-setup-0.3.69-1.fc30.armv7hl
(In reply to Paul Whalen from comment #5) > Trying this on another system, it worked as expected (same disk image - > Fedora-Minimal-armhfp-30-20190408.n.0-sda.raw.xz ): > > 1) [x] Language settings 2) [x] Time settings > (English (United States)) (America/New_York timezone) > 3) [x] Network configuration 4) [x] Root password > (Wired (eth0) connected) (Password is set.) > 5) [x] User creation > (Administrator pwhalen will be > created) > > Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to > refresh]: > c > > Fedora 30 (Thirty) > Kernel 5.0.5-300.fc30.armv7hl on an armv7l (ttyS1) > > rpi3-1 login: root > Password: > Last login: Mon Apr 8 15:33:42 from 192.168.0.11 > [root@rpi3-1 ~]# rpm -q initial-setup > initial-setup-0.3.69-1.fc30.armv7hl Is the Anaconda version the same on both systems ? (In reply to Martin Kolman from comment #6) > (In reply to Paul Whalen from comment #5) > > Is the Anaconda version the same on both systems ? Yes, using the same media and moving it between systems I can reproduce the crash on one sbc but not the other. Full logs attached (one log file as the media was moved, successful hostname is rpi3-1, failing hostname is bpro) Created attachment 1553741 [details]
journalctl
Discussed at 2019-04-08 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2019-04-08/ . Accepted as a release blocker as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for the ARM Xfce disk image (which is release blocking). As for the issue in comment #4 it seems we are getting None value from NM device object method which we pass to our data holder without checking. This patch should fix that: https://github.com/rvykydal/anaconda/commit/5e288d307c3397d391359b149f359103cf2e77d4 Interesting question is also what is the device causing the issue and why. I am not able to reproduce the issue so I am adding also logging to the patch to see which is the method returning None. Paul, Would you be able to try to reproduce with the change and attach the journal? I think you could just replace the /usr/lib/python3.7/site-packages/pyanaconda/modules/common/structures/network.py /usr/lib/python3.7/site-packages/pyanaconda/modules/network/network.py with respective files from the git branch (https://github.com/rvykydal/anaconda/commits/f30-release-nm-device-none) and re-run the initial-setup ? (In case i-s has already been run successfully enabling the inital-setup.service and removing /root/initial-setup-ks.cfg should be enough to re-run it after reboot.) Also having output of nmcli dev show can be useful to learn why we are not getting the info we expect from libnm device object. Thank you Replacing those files i-s starts as expected now on the problem hardware. From the logs (full journalctl attached): Apr 09 09:20:22 bpro org.fedoraproject.Anaconda.Modules.Network[848]: DEBUG:anaconda.modules.network.network:Setting NetworkDeviceInfo from NM device eth0 <enum NM_DEVICE_TYPE_ETHERNET of type NM.DeviceType> 02:86:04:02:AE:22 # nmcli dev show GENERAL.DEVICE: eth0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 02:86:04:02:AE:22 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: Wired connection 1 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 192.168.0.56/24 IP4.GATEWAY: 192.168.0.1 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.0.1, mt = 100 IP4.ROUTE[2]: dst = 192.168.0.0/24, nh = 0.0.0.0, mt = 100 IP4.DNS[1]: 8.8.8.8 IP4.DNS[2]: 8.8.4.4 IP6.ADDRESS[1]: fd00:9050:cac0:f272:f837:14e9:1496:5231/64 IP6.ADDRESS[2]: fe80::b1f4:636e:7d5a:396a/64 IP6.GATEWAY: -- IP6.ROUTE[1]: dst = fc00::/7, nh = fe80::9250:caff:fec0:f272, mt = 100 IP6.ROUTE[2]: dst = fd00:9050:cac0:f272::/64, nh = ::, mt = 100 IP6.ROUTE[3]: dst = ff00::/8, nh = ::, mt = 256, table=255 IP6.ROUTE[4]: dst = fe80::/64, nh = ::, mt = 100 GENERAL.DEVICE: lo GENERAL.TYPE: loopback GENERAL.HWADDR: 00:00:00:00:00:00 GENERAL.MTU: 65536 GENERAL.STATE: 10 (unmanaged) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- IP4.ADDRESS[1]: 127.0.0.1/8 IP4.GATEWAY: -- IP6.ADDRESS[1]: ::1/128 IP6.GATEWAY: -- IP6.ROUTE[1]: dst = ::1/128, nh = ::, mt = 256 Created attachment 1553852 [details]
updated journalctl
I am glad the i-s worked, but from the logs it seems that this time the condition causing the crash didn't actually occur. Nevertheless, I created a PR with a slightly modified patch: https://github.com/rhinstaller/anaconda/pull/1941 Random guess: does the bug only happen if i-s tries to set up the loopback device for some reason? Perhaps if the real network device is not yet active or something? Looopback device should be (based on its type) filtered out - ie not reach the code causing the traceback. Moreover, all the methods in play should return non-None value for lo. initial-setup-0.3.69-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. anaconda-30.25.6-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6ae44e47fb anaconda-30.25.6-1.fc30 has been pushed to the Fedora 30 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-6ae44e47fb anaconda-30.25.6-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. |
In recent Rawhide, after a KDE live install without creating a user, initial-setup fails to run because of this crash: Apr 03 13:38:01 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com initial-setup[949]: Initial Setup crashed due to unhandled exception: Traceback (most recent call last): File "/usr/libexec/initial-setup/initial-setup-graphical", line 7, in <module> is_instance = InitialSetup(gui_mode=True) File "/usr/lib/python3.7/site-packages/initial_setup/__init__.py", line 146, in __init__ from pyanaconda.network import setup_ifcfg_log ImportError: cannot import name 'setup_ifcfg_log' from 'pyanaconda.network' (/usr/lib64/python3.7/site-packages/pyanaconda/network.py) This is because the function was indeed removed from anaconda, in this commit: https://github.com/rhinstaller/anaconda/commit/ba2ab17e7ff3e5db1030ed1a709056c2142329fc part of this PR: https://github.com/rhinstaller/anaconda/pull/1864 Obviously initial-setup must be adjusted somehow. In general, we have seen this failure pattern multiple times at this point; I'd suggest some kind of test or at least process is needed upstream to ensure initial-setup gets checked whenever code is removed from anaconda... Note this commit seems to have gone to f30 too - looking at the anaconda-30.25.4-1 git tag, I see it in the commit history...so this needs fixing there too. Unfortunately the anaconda update just went stable, so that makes this a Final blocker, per "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" - initial-setup being broken always violates that for the ARM disk images, as there is no installation user creation step for those images, they rely on user account creation and/or root password setting via initial-setup.