Ich habe gerade 13.10 auf einem Dell-Laptop installiert. Während des Installationsvorgangs wurde eine Verbindung zum Ethernet hergestellt. Nachdem die Installation abgeschlossen war und ich mich zum ersten Mal anmeldete, hatte ich kein Ethernet.
Es verfügt über den Broadcom BCM4401-B0 100Base-TX Ethernet-Controller.
Beim Ausführen von ifconfig sehe ich kein eth0.
Antwort1
Ich hatte genau dasselbe Problem mit einem Broadcom 440x-Adapter in einem Dell Vostro 1000 (64-Bit-AMD-Installation).
Das CD-Installationsprogramm zeigte nach dem Booten von der CD die Erfüllung der drei Anforderungen/Empfehlungen an (der Dell 1390-WLAN-Adapter war vor, während und nach der Installation ein FEHLER, also musste ich ihn anschließen, um die dritte Empfehlung für den Internetzugang zu erfüllen). Ich habe 12.04.3 problemlos installiert und nach dem Neustart nach der Installation wird mir sogar angezeigt, dass ich 202 Updates habe.
Dann beginnt der wahre Wahnsinn. Der Versuch, irgendetwas anderes zu tun (einschließlich der Updates), ist nicht möglich, da entweder der kabelgebundene Adapter jetzt MIA ist oder jede Verwendung desselben dazu führt, dass die kabelgebundene Verbindung abbricht (sei es, um die Updates tatsächlich durchzuführen oder vielleicht Firefox zu starten). Ich sehe, dass die Broadcom-Netzwerkadapter (kabelgebunden und auch für das Dell 1390 WiFi) seit JAHREN mit Ubuntu (und so ziemlich jeder anderen Distribution) ein TOTALER ALBTRAUM sind, und anscheinend konnte auch niemand dies in der 13er Beta beheben.
Der oben von chili555 vorgeschlagene Befehl ergab auf meinem speziellen System Folgendes:
05:00.0 Network controller [0280]: Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)
08:00.0 Ethernet controller [0200]: Broadcom Corporation BCM4401-B0 100Base-TX [14e4:170c] (rev 02)
Außerdem zeigt das AirPort-Symbol in der Menüleiste an, dass „keine Netzwerkgeräte verfügbar“ sind, was rätselhaft ist, da wired die Updates, die angeblich verfügbar sind, nicht gefunden hat. Vielleicht kann die Brillanz der LiveCD beibehalten werden, um zu verhindern, dass die endgültige Installation nach dem ersten Booten abstürzt, sodass wir das Problem tatsächlich beheben können, ohne einen anderen Computer zu benötigen, nur um eine Ubuntu-Installation zum Laufen zu bringen?
HINWEIS: Sowohl die kabelgebundene als auch die kabellose Verbindung funktionieren unter Windows mit den Dell-Treibern einwandfrei (vor und zwischen den Ubuntu-Installationsversuchen, und ich habe in jedem Fall das aktuelle Betriebssystem überschrieben), es lag also nicht an einer Hardwarefehlfunktion oder sonstigem Unsinn.
Ich habe bei diesen späteren Installationstests jedes bisschen der Installation angepriesen, und anscheinend bricht die kabelgebundene Verbindung während der Installation deutlich ab, nachdem ich auf dem zweiten Installationsbildschirm (mit den drei Empfehlungen plus Update-Downloads und Installationsoptionen für proprietäre Software – beides in meinen Fällen aktiviert) auf „Fortfahren“ geklickt habe (ich war jedes Mal zuvor weggegangen und habe dies nicht bemerkt). Sie wird auf dem dritten Bildschirm wieder aktiviert (oder nachdem ich auf „Zurück“ geklickt habe, nur um nach erneutem Klicken auf „Fortfahren“ wieder auszusteigen, bis der dritte Bildschirm erneut geladen wird und die kabelgebundene Verbindung zurückkommt). Dies passiert später während der Installation erneut, während „System installiert“ wird. Jedes Deaktivieren/Aktivieren erhöht die Schnittstelle, sodass sie als eth# zugewiesen wird, wobei # die Anzahl der Male ist, die sie aus- und wieder eingeschaltet wird), wobei eth3 die niedrigste mögliche Zahl ist. Der verwendete Treiber ist b44.
Abgesehen davon konnte ich die kabelgebundene Netzwerkverbindung aufrechterhalten und sogar die drahtlose Verbindung wie folgt zum Laufen bringen (nachdem ich die Installation abgeschlossen und einen Neustart durchgeführt hatte):
1) Löschen Sie die doppelten eth#-Einträge über /etc/udev/rules.d/70-persistent-net.rules und schalten Sie die Netzwerkverbindung ein und aus (jetzt wird eth0 verwendet).
2) Gehen Sie zum Tool „Zusätzliche Treiber“ (manchmal erscheint es von selbst, andernfalls das Zahnradsymbol oben rechts -> Systemeinstellungen... -> Zusätzliche Treiber). Nachdem es nach Treibern gesucht hat (trinken Sie einen Kaffee oder zwei, so schnell es sucht), wird es Broadcom STA finden und Sie auffordern, es zu aktivieren. Klicken Sie auf die Schaltfläche „Aktivieren“, und obwohl die Aktivierung fehlschlägt (aufgrund des Eintrags /etc/modprobe.d/blacklist.conf für „bcm43xx“, der durch das im Fehler referenzierte /var/log/jockey.log bekannt gemacht wird), wird die Kabelverbindung hergestellt und bleibt bestehen (zumindest für die kritischen Zwecke von apt-get, next)!
3) Führen Sie die folgenden Befehle aus:
sudo apt-get remove bcmwl-kernel-source
sudo apt-get install firmware-b43-installer
sudo modprobe b43
HINWEIS: Obwohl einige sagen, man solle sowohl b43-fwcutter als auch das Obige installieren, wurde b43-fwcutter nach dem Obigen auf meinem System als installiert angezeigt ( sudo dpkg --get-selections | grep b43), also habe ich das Obige einfach so verwendet, wie es war.
Die ersten beiden Befehle oben habe ich über den folgenden Befehl gefundenINSEKTBericht (ja, wirklich schlechte Konfigurationen/Änderungen durch Autoupdates oder NeuinstallationenSindBugs, entgegen der Schließung dieses hier, da sonst!):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1113779
4) HALLELUJA! Wenn Sie auf das Airport-Symbol klicken, werden Ihnen nun sowohl kabelgebundene als auch kabellose Optionen angezeigt. Wenn der WiFi-Schalter ausgeschaltet ist, können Sie ihn mit den Tasten fn+F2 (oder einem beliebigen Schalter auf Ihrem eigenen System) einschalten, um alle verfügbaren APs anzuzeigen und eine Verbindung (wlan0) zu ihnen herzustellen (siehe die Kommentare unten).Wirklichnah, also physisch innerhalb von 10 Fuß, an allen APs!). Die Kabelverbindung sollte bereits aktiv sein, wenn nicht, wählen Sie „Auto Ethernet“ oder „Kabelverbindung 1“ dafür/davon und voilà (es ist sogar noch eth0)!
Leider bleiben WLAN-Verbindungen zwischen Neustarts nicht dauerhaft bestehen (WLAN wird nicht über den „Schalter“ deaktiviert – es scheint einfach inaktiv zu werden). WLAN kennt meine APs, stellt aber einfach keine Verbindung her, bis ich mich über die kabelgebundene Schnittstelle einstecke. WLAN findet dann sofort einen bekannten WLAN-AP und stellt eine Verbindung zu ihm her, ähnlich wie beim Starten des Tools „Zusätzliche Treiber“ … habe ich schon „Bug“ erwähnt?!
Hoffentlich habe ich das Schlimmste dieser Saga hinter mir und diese ausführliche Erklärung hilft der nächsten Person, ähnliche Frustrationen zu vermeiden, zumindest bis (es sei denn?) dieses Chaos richtig behoben wird. Ich sehe Beiträge zu Broadcom-Problemen, die mehrere Versionen zurückreichen, obwohl 12.04 (nur mein Glück/Timing!) problematischer zu sein scheint als die meisten anderen. Ich verwende es, weil es die aktuelle LTS-Version ist.
AKTUALISIEREN
Siehe die Kommentare, aber...
Ein weiteres damit zusammenhängendes Rätsel: Warum möchte das Tool „Zusätzliche Treiber“ ständig, dass ich die drahtlose Verbindung Broadcom STA aktiviere?! Wenn ich das tue, schlägt der Download sofort fehl (Fehler „jockey.log“, obwohl ich vorher problemlos verbunden war) und die drahtlose Verbindung verschwindet vollständig aus dem Airport-Symbol in der Menüleiste, bis ich ein . ausführe sudo modprobe b43, aber dann muss ich bis auf 10 Fuß an den AP herangehen, damit er sich (wieder) verbindet.
Nur zur Bestätigung, dies ist kein Hardwareproblem - mit Windows (XP oder Vista) und den Dell-Treibern kann ich im Hinterhof sein und mich auch nach jedem (Neu-)Start mit meinem AP (wieder) verbinden, aber diesen fehlerhaften Broadcom-Treibern für Linux fehlt anscheinend etwas Wichtiges bei der Suche nach einem AP und der (Wieder-)Verbindung mit ihm aus einem getrennten Zustand (Deaktivieren, Neustart usw.). Vielleicht ist es ein Problem zwischen ab und g oder vielleicht ist das Radio im Energiesparmodus oder irgendein anderer ähnlicher Unsinn??
Zum Glück handelt es sich hierbei um einen WLAN-Laptop und nicht um einen Desktop-PC, sodass ich ihn zurück zum AP bringen kann, um die Verbindung (wieder) herzustellen und dann überall hingehen kann, wo auch meine anderen Geräte hingehen können, aber es ist trotzdem ein riesiges PiTA-Problem.