Version-Release number of selected component:
The following was filed automatically by anaconda:
anaconda 24.2-1 exception report
Traceback (most recent call first):
File "/usr/lib64/python3.4/site-packages/pyanaconda/ui/gui/spokes/network.py", line 1072, in _get_strongest_unique_aps
ssid = ap.get_ssid().get_data()
File "/usr/lib64/python3.4/site-packages/pyanaconda/ui/gui/spokes/network.py", line 894, in _refresh_ap
aps = self._get_strongest_unique_aps(dev_cfg.device.get_access_points())
File "/usr/lib64/python3.4/site-packages/pyanaconda/ui/gui/spokes/network.py", line 819, in refresh_ui
File "/usr/lib64/python3.4/site-packages/pyanaconda/ui/gui/spokes/network.py", line 450, in on_device_selection_changed
AttributeError: 'NoneType' object has no attribute 'get_data'
cmdline: /usr/bin/python3 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file: BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-rawhide-20 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
other involved packages: anaconda-gui-24.2-1.fc24.x86_64
release: Fedora release 24 (Rawhide)
Created attachment 1072729 [details]
Created attachment 1072730 [details]
Created attachment 1072731 [details]
Created attachment 1072732 [details]
Created attachment 1072733 [details]
Created attachment 1072734 [details]
Created attachment 1072735 [details]
Created attachment 1072736 [details]
Created attachment 1072737 [details]
Created attachment 1072738 [details]
Another user experienced a similar problem:
With the latest Rawhide snapshot I tried to install on a system which doesn't have Ethernet cable plugged in. After going to the network settings spoke I saw eth0 unplugged/off and wifi0. After clicking on wifi0 to eneble it I got this error.
Then plugged in eth0 to report the traceback.
cmdline: /usr/bin/python3 /sbin/anaconda
cmdline_file: inst.stage2=hd:sda1:/install.img repo=https://kojipkgs.fedoraproject.org/mash/rawhide-20151111/rawhide/x86_64/os sshd=1
reason: AttributeError: 'NoneType' object has no attribute 'get_data'
release: Cannot get release name.
In addition to this bug I'm also seeing bug #1280271, but they may not be related.
Same error for current Fedora development including packages:
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.
More information and reason for this action is here:
Pretty sure nm_access_point_get_ssid shouldn't be returning for what appears to be a valid NMAccessPoint object.
*** Bug 1321011 has been marked as a duplicate of this bug. ***
Note this was failure on entering networking spoke of 24.13- in Fedora-Everything-netinst-x86_64-24_Alpha-1.7.iso
could not detect wireless AP
DVD to HD bare metal install
Installs fine if use wired connection as detected on boot
(In reply to satellitgo from comment #17)
> Note this was failure on entering networking spoke of 24.13- in
> could not detect wireless AP
> DVD to HD bare metal install
> Installs fine if use wired connection as detected on boot
(In reply to Joachim Frieben from comment #13)
Wifi connection works well now for Fedora-Workstation-netinst-x86_64-24_Alpha-1.7 boot image.
I tested Fedora-Everything-netinst x86_64 Alpha 1.7 and hit this crash on reaching the hub screen - I didn't even have to go to the NETWORK spoke. Nominating as a Beta blocker as that impact is pretty bad for me. My test system was a third-gen Dell XPS 13 developer edition with wifi and no ethernet adapter.
Discussed at today's blocker review meeting . Voted as AcceptedBlocker (Beta) - testing indicates that this bug violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." (and other 'complete an install' criteria) for at least some affected systems, likely wifi-only installs from netinst / DVD
How reproducible is this? It would be useful if anybody could provide NM logs obtained after increasing log level by setting this:
in /etc/NetworkManager/NetworkManager.conf (the service must be restarted then).
Or in alternative:
# nmcli general logging domains DEFAULT,WIFI_SCAN
# nmcli general logging level DEBUG
(this doesn't require restart but changes are not persistent).
it's easily reproducible for me just by booting an installer image on a system with no ethernet, but it's difficult to get in and tweak the NM config before the crash happens. I'll try and do it one way or another, though.
oh, never mind, I forgot we can reproduce it on live. Then it should be easy.
Hmm, I tried with current nightly Workstation live and didn't hit the crash. I'll try it a couple more times with that image and the Everything netinst.
Are other reporters still hitting this with recent nightlies?
Aha, OK, in the live case, there's an overlap with https://bugzilla.redhat.com/show_bug.cgi?id=1146232 here: when the virbr0 interface / route is present, the crash doesn't happen. If you destroy it and run the installer, the crash happens.
Created attachment 1146604 [details]
journal after triggering the crash with requesting NM logging settings
(In reply to Adam Williamson from comment #27)
> Created attachment 1146604 [details]
> journal after triggering the crash with requesting NM logging settings
The 'ssid' field of an AP object can be NULL when the AP is not
broadcasting the SSID, so the client application must be prepared to
handle this situation. See for example:
I think this should be solved in anaconda.
Aha, thanks. So a better / more precise definition of this bug would be that it happens not 'whenever anaconda tries to do wifi scanning' (whether explicitly triggered, or done automatically because there's no wired connection and we need a network), but that it happens 'whenever anaconda tries to do wifi scanning *and there's an AP within range that is set not to broadcast its SSID*'?
(In reply to Adam Williamson from comment #29)
> Aha, thanks. So a better / more precise definition of this bug would be that
> it happens not 'whenever anaconda tries to do wifi scanning' (whether
> explicitly triggered, or done automatically because there's no wired
> connection and we need a network), but that it happens 'whenever anaconda
> tries to do wifi scanning *and there's an AP within range that is set not to
> broadcast its SSID*'?
I think you are right. My AP doesn't broadcast its SSID IIRC.
This was merged, should be in next anaconda build.
python-blivet-1.20.0-1.fc24 anaconda-24.13.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-45ca29d07c
anaconda-24.13.4-1.fc24, python-blivet-1.20.0-1.fc24 has been pushed to the Fedora 24 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-2016-45ca29d07c
anaconda-24.13.4-1.fc24, python-blivet-1.20.0-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.