| Summary: | no network interfaces found on boot after HTTP installation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Felix Miata <mrmazda> | ||||||
| Component: | biosdevname | Assignee: | Matt Domsch <matt_domsch> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rawhide | CC: | awilliam, harald, jlaska, jonathan, mattdm, matt_domsch, mebrown, redhat-bugzilla, scottt.tw, vanmeeuwen+fedora | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | AcceptedNTH | ||||||||
| Fixed In Version: | biosdevname-0.3.7-1.fc15 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-02-19 03:50:38 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 657617 | ||||||||
| Attachments: |
|
||||||||
|
Description
Felix Miata
2011-02-04 02:44:59 UTC
Created attachment 477069 [details]
lspci output and tail -n1000 /var/log/messages
I've since installed several more times, always with similar results - very long boot times, lots of trace messages, and anything network related failing. On the last attempt I eventually got to a login, logged in as root, and did 'ifconfig -a'. The result of that doesn't seem ever to have occurred. Something must be in an endless loop.
Created attachment 477071 [details]
/var/log/anaconda/anaconda.ifcfg.log
I'm not sure, why the reporter selected "ethtool" as component, because our ethtool shouldn't be responsible for the described result. Reassigning to the anaconda team, because I feel this is more anaconda than ethtool related... biosdevname needs to be updated to not use # in the device name. biosdevname-0.3.7-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/biosdevname-0.3.7-1.fc15 That URL is refusing me access. this definitely looks like a +1 nth to me. If it affects enough people it's arguably a blocker, as it breaks "The installed system must be able to download and install updates with yum and PackageKit" - can't install updates with no networking. biosdevname-0.3.7-1.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update biosdevname'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/biosdevname-0.3.7-1.fc15 From the 2011-02-18 Alpha blocker review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-02-18/f15-alpha-bug-review.2011-02-18-17.00.html) AGREED: 675048 - AcceptedNTH, updated koji build available biosdevname-0.3.7-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. eth0 now found in 15alphaRC1, except it's been immemorably renamed to pci11p1 :-( (In reply to comment #11) > eth0 now found in 15alphaRC1, except it's been immemorably renamed to pci11p1 > :-( See https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming Yi yi yi yi yi yi yi, so complicated! So now one need find the back of the machine to see whether onboard or slot, and if slot guess which slot the NIC is in to predict what the name should be, and if onboard has more than one, guess which is/are which. :-( The new names should alias to legacy names. (In reply to comment #13) > Yi yi yi yi yi yi yi, so complicated! So now one need find the back of the > machine to see whether onboard or slot, and if slot guess which slot the NIC is > in to predict what the name should be, and if onboard has more than one, guess > which is/are which. :-( The new names should alias to legacy names. See the link I previously noted for ways to get involved with the feature, and to voice concerns. This bug report isn't the proper place for feedback on the feature to be heard. (In reply to comment #13) > The new names should alias to legacy names. There is no such thing as a network "alias/symlink"! |