I had the same exact issue with a Broadcom 440x adapter in a Dell Vostro 1000 (64-bit AMD install).
The CD installer showed satisfaction of the three requirements/recommendations after booting from the CD (the Dell 1390 wireless adapter was a BUST before, during and after the install, so I had to plug-in to pass the third recommendation of internet access). I installed 12.04.3 just fine and then after the post-install reboot, it even tells me I have 202 updates.
Then the real insanity begins. Trying to do anything else (including the updates) cannot happen b/c either the wired adapter is now MIA or any use of same causes the wired connection to drop (be it to actually perform the updates, or maybe launching Firefox). I see that the Broadcom (wired and also for the Dell 1390 WiFi) network adapters have been a TOTAL NIGHTMARE for YEARS now with Ubuntu (and just about every other distro), and apparently no one has been able to fix this in the 13 beta either.
chili555's suggested command, above, yielded the following on my particular system:
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)
In addition, the AirPort wanna-be icon in the menubar says that "No network devices are available" which is puzzling, since wired worked to find the updates it says are available. Maybe the LiveCD brilliance can be maintained to stop the final install from breaking itself after first boot, so we can actually remedy the issue without needing another computer just to get an Ubuntu install working?
NOTE: Both wired and wireless work flawlessly in Windows using the Dell drivers (before and between Ubuntu installation attempts, and I overwrote any current OS in each case), so this was not malfunctioning hardware or any other nonsense.
I hawked every bit of the install in these later install tests, and, apparently, during installation, the wired connection drops well after (I had walked away each time prior and did not notice this) hitting "Continue" on the 2nd installation screen (with the three recommendations, plus update downloads and proprietary software install options - both checked in my cases). It is re-enabled on the 3rd screen (or after hitting "Back", only to go back out after hitting Continue again, until the 3rd screen is again loaded, and wired comes back). It does this again late in the install while "Installing system". Each disabling/enabling increments the interface, such that it is assigned as eth#, where # is the number of times it goes out and comes back on), with the lowest possible being eth3. The driver in use is b44.
That aside, I was able to get wired networking to persist, and even wireless working, as follows (after finishing the installation and rebooting):
1) Delete the duplicative eth# entries, via /etc/udev/rules.d/70-persistent-net.rules, and toggle networking off and on (now it's using eth0).
2) Go to the Additional Drivers tool (it sometimes pops-up on its own; otherwise, top right corner gear icon-->System Settings...-->Additional Drivers) and after it searches for drivers (get a coffee or two at the rate it searches), it'll find and want you to activate Broadcom STA. Click the "Activate" button, and although the activation fails (due to the /etc/modprobe.d/blacklist.conf entry for "bcm43xx", which is made known by the /var/log/jockey.log referenced in the error) the wired connection comes on and stays on (at least for the critical purposes of apt-get, next)!
3) Run the following commands:
sudo apt-get remove bcmwl-kernel-source
sudo apt-get install firmware-b43-installer
sudo modprobe b43
NOTE: Although some say to install both b43-fwcutter and the above, b43-fwcutter showed as installed on my system after the above (sudo dpkg --get-selections | grep b43
), so I just used the above as-is.
I discovered the first two commands, above, via the following BUG report (yes, really bad configs/changes from autoupdates or clean installs are bugs, contrary to the closing of this one as otherwise!):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1113779
4) HALLELUJAH! Clicking the Airport-looking icon now shows both wired and wireless options. If it reports the WiFi switch being set to off, the fn+F2 keys (or whatever switch you have on your own system should) work to turn it on to see and connect (wlan0) to any available APs (as per the comments, below, get really close, as in physically within 10', to any APs!). Wired should already be up, but if not, then select "Auto Ethernet" or "Wired connection 1" for/from same and voila (it's even still eth0)!
Sadly, WiFi connections are not persistent between reboots (WiFI is not disabled via "switch" - it just seems to go dormant). WiFi knows of my APs, but simply will not connect until I plug-in via the wired interface. WiFI then immediately finds and connects to a known WiFI AP, similar to firing-up the Additional Drivers tool...did I mention "bug" yet?!
Hopefully I'm through the worst of this saga, and this detailed explanation helps the next person avoid similar frustrations, at least until (unless?) this mess gets fixed properly. I see posts on Broadcom issues going back quite a few releases, although 12.04 (just my luck/timing!) seems to be more problematic than most. I'm using it b/c it is the current LTS release.
UPDATE
See the comments, but...
Another related mystery - why does the Additional Drivers tool keep wanting me to activate Broadcom STA wireless?! If I do, it fails as soon as it tries to download (jockey.log error, even though I was connected fine prior) and that knocks wireless completely out of the menu bar Airport icon, until I do a sudo modprobe b43
, but then I have to walk back within 10' of the AP to get it to (re)connect.
Just to confirm, this is not a hardware issue - with Windows (XP or Vista) and the Dell driver(s) I can be in the backyard and (re)connect to my AP even after any (re)boot, but these flaky Broadcom drivers for Linux are apparently missing something significant in terms of its searching for and (re)connecting to an AP from a disconnected state (disable, reboot, etc.). Perhaps it's a b vs. g issue or maybe the radio is on low-power state or some other related nonsense??
Thankfully this is a WiFi laptop and not a desktop, so I can walk it back towards the AP to let it (re)connect and then go anywhere any of my other devices can go, but it's still a major PiTA of an issue.