Bug 1703152
Summary: | initial-setup fails with no network - AttributeError: 'NoneType' object has no attribute 'upper' | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Whalen <pwhalen> |
Component: | initial-setup | Assignee: | Martin Kolman <mkolman> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 30 | CC: | awilliam, bcotton, dyaffe, jan.public, julen, lbrabec, mkolman, robatino, v.podzimek+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | aarch64 | ||
OS: | Unspecified | ||
Whiteboard: | AcceptedFreezeException | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-04-26 22:33:23 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, 1574716 |
Description
Paul Whalen
2019-04-25 16:08:33 UTC
Nominating for dicussion as a possible blocker for F30 final. Seems this would happen if device.get_hw_address or device.get_permanent_hw_address returned None. The code that actually crashes here has not changed since Feb 2018, but the path we reach it on - specifically the call to network_proxy.CreateDeviceConfigurations() - was added in initial-setup 0.3.67 in March 2019, as part of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1685992 , an earlier blocker in this cycle. anaconda itself also calls CreateDeviceConfigurations during network init, so in theory it could hit this too. I do wonder if something anaconda does *before* that filters out devices which would trigger this, but initial-setup doesn't do the same. I don't see anything *obvious* that does that, but there's some non-obvious stuff in there... The obvious fix here is very simple, btw, it's just: -if address.upper() == hwaddr.upper(): +if address and address.upper() == hwaddr.upper(): but the more important question for right now is "why is this happening and how often is it likely to happen", since we need to know if we can ship RC1. That's what I'm trying to figure out. anaconda-30.25.6-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7184d9d0c0 Discussed in the Fedora 30 Go/No-Go meeting blocker review: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-25/f30-final-go_no_go-meeting.2019-04-25-17.01.log.html#l-562 This appears to hit a narrow case, but can't be fixed in an update. We defer a decision on blocker status initial-setup works on kde with 30-1.2 x86_64 I don't have Pine 64 Plus, but on Raspberry Pi 3 the initial-setup works both with and without ethernet cable connected on images Fedora-{Minimal,Xfce}-armhfp-30-1.2 I hit this when trying to do a netinstall of F30 on my 2013 Macbook Pro, as there is no physical ethernet interface on the system, and the wireless card was not detected. I resolved the problem using a Wi-Pi usb adapter to get the install going. I can redownload the latest image and retest if required. anaconda-30.25.6-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. |