wl missing after Karmic -> Lucid upgrade

[Scott Kitterman]

From a working 9.10 Kubuntu Netbook system I upgraded to Lucid during the Alpha 2 freeze. After the upgrade, I had no wireless. Purging bcmwl-kernel-source and reinstalling fixed the problem. Installation of the package during the upgrade doesn't appear to have had any problems:

Setting up dkms (2.1.1.0-0ubuntu8) ...^M
Installing new version of config file /etc/kernel/postinst.d/dkms ...^M
Installing new version of config file /etc/kernel/header_postinst.d/dkms ...^M
^M
Setting up linux-headers-2.6.32-10 (2.6.32-10.14) ...^M
Setting up linux-headers-2.6.32-10-generic (2.6.32-10.14) ...^M
Examining /etc/kernel/header_postinst.d.^M
run-parts: executing /etc/kernel/header_postinst.d/dkms 2.6.32-10-generic /boot/vmlinuz-2.6.32-10-generic^M
 * Running DKMS auto installation service for kernel 2.6.32-10-generic ^[[143G ^M^[[137G[ OK ]^M
run-parts: executing /etc/kernel/header_postinst.d/nvidia-common 2.6.32-10-generic /boot/vmlinuz-2.6.32-10-generic^M
^M
Setting up linux-headers-generic (2.6.32.10.10) ...^M
Setting up bcmwl-kernel-source (5.10.91.9+bdcom-0ubuntu5) ...^M
Adding Module to DKMS build system^M
Doing initial module build^M
Installing initial module^M
Done.^M
update-initramfs: deferring update (trigger activated)^M
^M
Setting up bcmwl-modaliases (5.10.91.9+bdcom-0ubuntu5) ...^M

Manually running Jockey after the upgrade indicated no proprietary drivers in use, but did not offer WL. Jockey log attached.

System is a Dell Mini 10v, Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)

[savasten (savasten)]

I have noticed the UNR live cd jockey sees the wireless card while running live. After install the hardware is not seen.

[savasten (savasten)]

UNR CD was 1-25-2010 Daily build.

[Scott Kitterman (kitterman)]

That's not this issue. This bug is for a system that had wl installed and lost it on upgrade from Karmic to Lucid.

[savasten (savasten)]

I understand I have duplicated it both ways.

[Martin Pitt (pitti)]

What did "dkms status" say after the upgrade? It actually looked just fine, was it correctly built/installed? WHat did "modinfo wl" say?

[Martin Pitt (pitti)]

bcmwl itself works fine here, and for you as well after reinstall apparently, so I suppose this is rather a problem in the dkms integration. Tentatively reassigning for now.

[Scott Kitterman (kitterman)]

Unfortunately since I fixed it manually already, I don't have a good way to answer that question.

[Mario Limonciello (superm1)]

Without having further information to debug with after that upgrade, there's no way we can see what's going on here. I'm going to close this bug as Invalid, but if someone does reproduce this and can provide the output of

$ dkms status

as well as the upgrade logs, then please reopen and set the bug to "New".

[Martin Pitt (pitti)]

This was confirmed by two more persons (Ivanka, Jos) during the sprint. After the upgrade, "dkms status" said that the module was installed for the karmic kernel (2.6.31-17), i. e. for the kernel that was running at the time when the upgrade was done. Apparently it only rebuilt the module for the current kernel, but not for the "latest" one as well.

Does DKMS usually attempt to install for a newly appeared kernel as well?

[Martin Pitt (pitti)]

I attach Ivanka's dist-upgrade term.log. Interesting bits:

Selecting previously deselected package linux-image-2.6.32-12-generic.
Unpacking linux-image-2.6.32-12-generic (from .../linux-image-2.6.32-12-generic_2.6.32-12.16_i386.deb) ...
Done.
[...]
Selecting previously deselected package linux-headers-2.6.32-12.
Unpacking linux-headers-2.6.32-12 (from .../linux-headers-2.6.32-12_2.6.32-12.16_all.deb) ...
0.6.25-1ubuntu6_i386.deb) ...
Selecting previously deselected package linux-headers-2.6.32-12-generic.
Unpacking linux-headers-2.6.32-12-generic (from .../linux-headers-2.6.32-12-generic_2.6.32-12.16_i386.deb) ...
Preparing to replace linux-headers-generic 2.6.31.17.30 (using .../linux-headers-generic_2.6.32.12.12_i386.deb) ...
Unpacking replacement linux-headers-generic ...
.deb) ...

-> so it seems that all necessary bits for the new kernel were in place at that time.

Preparing to replace bcmwl-kernel-source 5.10.91.9+bdcom-0ubuntu4 (using .../bcmwl-kernel-source_5.10.91.9+bdcom-0ubuntu5_i386.deb) ...
Removing all DKMS Modules
Done.
Unpacking replacement bcmwl-kernel-source ...
Preparing to replace bcmwl-modaliases 5.10.91.9+bdcom-0ubuntu4 (using .../bcmwl-modaliases_5.10.91.9+bdcom-0ubuntu5_i386.deb) ...
all.deb) ...
[...]

Later on, we get to configuring the new kernel:

Setting up linux-image-2.6.32-12-generic (2.6.32-12.16) ...
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.32-12-generic
Running postinst hook script /usr/sbin/update-grub.
head: cannot open `/boot/grub/video.lst' for reading: No such file or directory
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-12-generic
Found initrd image: /boot/initrd.img-2.6.32-12-generic
Found linux image: /boot/vmlinuz-2.6.31-17-generic
Found initrd image: /boot/initrd.img-2.6.31-17-generic
Found linux image: /boot/vmlinuz-2.6.31-16-generic
Found initrd image: /boot/initrd.img-2.6.31-16-generic
Found linux image: /boot/vmlinuz-2.6.31-15-generic
Found initrd image: /boot/initrd.img-2.6.31-15-generic
Found linux image: /boot/vmlinuz-2.6.31-14-generic
Found initrd image: /boot/initrd.img-2.6.31-14-generic
Found linux image: /boot/vmlinuz-2.6.31-13-generic
Found initrd image: /boot/initrd.img-2.6.31-13-generic
Found linux image: /boot/vmlinuz-2.6.31-12-generic
Found initrd image: /boot/initrd.img-2.6.31-12-generic
Found linux image: /boot/vmlinuz-2.6.31-11-generic
Found initrd image: /boot/initrd.img-2.6.31-11-generic
Found linux image: /boot/vmlinuz-2.6.31-10-generic
Found initrd image: /boot/initrd.img-2.6.31-10-generic
Found memtest86+ image: /boot/memtest86+.bin
Found Windows Vista (loader) on /dev/sda1
Found Windows Vista (loader) on /dev/sda3
done
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 2.6.32-12-generic /boot/vmlinuz-2.6.32-12-generic
run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.32-12-generic /boot/vmlinuz-2.6.32-12-generic
run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.32-12-generic /boot/vmlinuz-2.6.32-12-generic

-> Shouldn't the postinst.d/dkms run have built the bcmwl module here?

Anyway, it has another chance later on:

Setting up dkms (2.1.1.1-0ubuntu3) ...
Installing new vers...

[Mario Limonciello (superm1)]

Has this behavior changed in the arguments provided to the /etc/kernel/*
scripts? It looks like it's being called with
'/boot/vmlinux-2.6.32-12-generic' rather than '2.6.32-12-generic', where the
later is what is expected (and what was used in previous distro iterations).

On Fri, Feb 5, 2010 at 13:39, Martin Pitt <email address hidden> wrote:

> I attach Ivanka's dist-upgrade term.log. Interesting bits:
>
> Selecting previously deselected package linux-image-2.6.32-12-generic.
> Unpacking linux-image-2.6.32-12-generic (from
> .../linux-image-2.6.32-12-generic_2.6.32-12.16_i386.deb) ...
> Done.
> [...]
> Selecting previously deselected package linux-headers-2.6.32-12.
> Unpacking linux-headers-2.6.32-12 (from
> .../linux-headers-2.6.32-12_2.6.32-12.16_all.deb) ...
> 0.6.25-1ubuntu6_i386.deb) ...
> Selecting previously deselected package linux-headers-2.6.32-12-generic.
> Unpacking linux-headers-2.6.32-12-generic (from
> .../linux-headers-2.6.32-12-generic_2.6.32-12.16_i386.deb) ...
> Preparing to replace linux-headers-generic 2.6.31.17.30 (using
> .../linux-headers-generic_2.6.32.12.12_i386.deb) ...
> Unpacking replacement linux-headers-generic ...
> .deb) ...
>
>
> -> so it seems that all necessary bits for the new kernel were in place at
> that time.
>
> Preparing to replace bcmwl-kernel-source 5.10.91.9+bdcom-0ubuntu4 (using
> .../bcmwl-kernel-source_5.10.91.9+bdcom-0ubuntu5_i386.deb) ...
> Removing all DKMS Modules
> Done.
> Unpacking replacement bcmwl-kernel-source ...
> Preparing to replace bcmwl-modaliases 5.10.91.9+bdcom-0ubuntu4 (using
> .../bcmwl-modaliases_5.10.91.9+bdcom-0ubuntu5_i386.deb) ...
> all.deb) ...
> [...]
>
> Later on, we get to configuring the new kernel:
>
> Setting up linux-image-2.6.32-12-generic (2.6.32-12.16) ...
> Running depmod.
> update-initramfs: Generating /boot/initrd.img-2.6.32-12-generic
> Running postinst hook script /usr/sbin/update-grub.
> head: cannot open `/boot/grub/video.lst' for reading: No such file or
> directory
> Generating grub.cfg ...
> Found linux image: /boot/vmlinuz-2.6.32-12-generic
> Found initrd image: /boot/initrd.img-2.6.32-12-generic
> Found linux image: /boot/vmlinuz-2.6.31-17-generic
> Found initrd image: /boot/initrd.img-2.6.31-17-generic
> Found linux image: /boot/vmlinuz-2.6.31-16-generic
> Found initrd image: /boot/initrd.img-2.6.31-16-generic
> Found linux image: /boot/vmlinuz-2.6.31-15-generic
> Found initrd image: /boot/initrd.img-2.6.31-15-generic
> Found linux image: /boot/vmlinuz-2.6.31-14-generic
> Found initrd image: /boot/initrd.img-2.6.31-14-generic
> Found linux image: /boot/vmlinuz-2.6.31-13-generic
> Found initrd image: /boot/initrd.img-2.6.31-13-generic
> Found linux image: /boot/vmlinuz-2.6.31-12-generic
> Found initrd image: /boot/initrd.img-2.6.31-12-generic
> Found linux image: /boot/vmlinuz-2.6.31-11-generic
> Found initrd image: /boot/initrd.img-2.6.31-11-generic
> Found linux image: /boot/vmlinuz-2.6.31-10-generic
> Found initrd image: /boot/initrd.img-2.6.31-10-generic
> Found memtest86+ image: /boot/memtest86+.bin
> Found Windows Vista (loader) on /dev/sda1
> Found Windows Vista (loader) on /dev/sda3
> done
> Examining /etc/kernel/postinst.d.
> run-par...

[Martin Pitt (pitti)]

Mario Limonciello [2010-02-07 18:07 -0000]:
> Has this behavior changed in the arguments provided to the /etc/kernel/*
> scripts? It looks like it's being called with
> '/boot/vmlinux-2.6.32-12-generic' rather than '2.6.32-12-generic', where the
> later is what is expected (and what was used in previous distro iterations).

I can't tell whether it changed, but perhaps dkms should run the
argumment through basename for more robustness?

[Mario Limonciello (superm1)]

Well that's not the problem from what I can tell. There weren't any changes
there, just misrereading that debug output.

Reconfiguring linux-image-2.6.32-12-generic appears to make things work
(dpkg-reconfigure linux-image-2.6.32-12-generic) in a VM for me on a fresh
install, so on someone who has a broken upgrade, can we please see the
make.log in /var/lib/dkms/ for the failed kernel?

On Mon, Feb 8, 2010 at 02:09, Martin Pitt <email address hidden> wrote:

> Mario Limonciello [2010-02-07 18:07 -0000]:
> > Has this behavior changed in the arguments provided to the /etc/kernel/*
> > scripts? It looks like it's being called with
> > '/boot/vmlinux-2.6.32-12-generic' rather than '2.6.32-12-generic', where
> the
> > later is what is expected (and what was used in previous distro
> iterations).
>
> I can't tell whether it changed, but perhaps dkms should run the
> argumment through basename for more robustness?
>
> --
> wl missing after Karmic -> Lucid upgrade
> https://bugs.launchpad.net/bugs/506816
> You received this bug notification because you are subscribed to dkms in
> ubuntu.
>

--
Mario Limonciello
<email address hidden>

[LaserJock (laserjock)]

I ran into this upgrading from Karmic last night. I had no wifi and Jockey gave an error when I tried to activate the Broadcom STA driver. I ran dpkg-reconfigure linux-image-2.6.32-13-generic and then was able to activate the driver and wifi now works. I am attaching the /var/lib/dkms/bcmwl/ dir from before the dpkg-reconfigure. The only kernel directory was for the kernel I was running during upgrade. Additionally, I ran modinfo on the driver and got:

vermagic: 2.6.31-19-generic SMP mod_unload modversions 586

Hope this helps.

[Mario Limonciello (superm1)]

Can someone who has had a failed upgrade investigate if they have a /etc/kernel/header_postinst.d/dkms ? If not, what was your starting point?

My suspicions are that fresh karmic installs that are upgraded won't encounter this, but people upgrading from earlier releases might based upon that file being missing.

[Dave Morley (davmor2)]

Mario I'll try on my HP lappy Give me a couple of hours

[Dave Morley (davmor2)]

Wounder it worked here, not sure if there is a fix in place. I would need to try on my netbook but I'm currently needing that so I'd rather not. Can someone affect try please

[dzidek23 (dzidek23)]

Hi, I've just upgrade from 9.10 to 10.04 and I found out that my wireless is not working any more. Network setting were still there, but gnome refused to connect saying that wireless is not available. When I used a USB wireless card NM showed two devices but both unavailable.

I have a hardware switch (to turn wireless on or off) which was working perfectly in Windows, Ubuntu 8.04 and later seem to forget about it and 10.04 recognize it. I've turned it ON and the network is working.

Curiosity is that hardware switch turned off/on not only build-in network card but the USB stick as well.

[Scott Kitterman (kitterman)]

If all you had to do was change the switch, you don't have this bug.

[Peter Silva (peter-bsqt)]

Confirmed on my Dell Mini10v also. the driver is still loading, but never works.
I can get an occasional iwconfig eth1 scan to give an answer, usually it says it is not
available, but sometimes it works. I initially thought it was knetworkmanager, but nm-applet doesn't work either. Neither does wpa_supplicant configured manually.
wpa_supplicant manages to see the ap, tries to associate, but the that never works (interfaces refuses to associate...) ... ok that was solid yesterday... today it associates,
but dhclient doesn't seem to grok things... but on the second or third try, it does!

today (after a week being connected via copper) it works (manually with wpa_client, have not tried full nm glory.)

[Drew Scott Daniels (drewdaniels)]

I wonder if there's conflicts due to the b43 driver supporting PCI ID 14e4:4315 with Linux Kernel 2.6.32 and later.
http://wireless.kernel.org/en/users/Drivers/b43

Some debugging techniques I might try if I decide to do the upgrade and have problems would be:
   * Get a list of the potentially relevant devices (using a terminal/console):
lspci -vnn | grep 14e4
   * do an "lsmod" and look for things like b43 and wl (again from a terminal/console)
   * Try to figure out the firmware cutter stuff mentioned at: http://wireless.kernel.org/en/users/Drivers/b43
   * Try enabling and disabling the wl driver with jockey-gtk or jockey-text (I like the new jockey-text), and trying a reboot inbetween each action.
...

Thanks,

     Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html

[Peter Silva (peter-bsqt)]

root@boule:~# lspci -vnn | grep -i bcm
^[03:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01)
root@boule:~#
root@boule:~# lsmod | grep b43
root@boule:~# lsmod | grep wl
wl 1959694 0
lib80211 5046 2 lib80211_crypt_tkip,wl
root@boule:~#

I tried b43 drivers, and eth1 would not even show up.

I did apt-get purge bcmwl-kernel-source...
then re-installed them. behaviour is exactly the same.

once in a very rare while, I can get it to associate, and then dhcp works
and I get an address. but that never works with network-manager,
and even manually if I shutdown and restart the interface, I don't get it back,
it just decides never to associate again.

It almost never succeeds in associating (to a dlink DIR655 router with n+g enabled.) The weird thing is that it isn't quite never... just really rarely.

[Tim Gardner (timg-tpi)]

Scott - I did a full Gnome Karmic to Lucid update with no issues using 'sudo apt-get -u dist-upgrade'. wl was alive and well after rebooting to Lucid. Do you think this problem could be Kubuntu specific?

[Scott Kitterman (kitterman)]

The only KDE specific code involved is the KDE front end for Jockey, so I don't
see how.

This happened very early in the cycle so I wonder if some other change
resolved this?

[Tim Gardner (timg-tpi)]

Scott - OK, then I'll do the Karmic to Lucid Kubuntu upgrade dance just to make sure.

[Martin Pitt (pitti)]

Tim Gardner [2010-04-20 20:39 -0000]:
> Scott - I did a full Gnome Karmic to Lucid update with no issues using
> 'sudo apt-get -u dist-upgrade'. wl was alive and well after rebooting to
> Lucid. Do you think this problem could be Kubuntu specific?

During the distro sprint there were two or three people who had this,
and they were running Ubuntu. It seems to be a DKMS problem, way below
the desktop area.

The install logs looked like DKMS just didn't bother to build the kmod
for the new kernel during dist-upgrade while the old kernel was still
running.

[u-foka (ufooka)]

Martin, now the boot time module building is disabled in DKMS??
--
Eisenberger Tamás <email address hidden>

On Tue, 2010-04-20 at 22:44 +0000, Martin Pitt wrote:
> Tim Gardner [2010-04-20 20:39 -0000]:
> > Scott - I did a full Gnome Karmic to Lucid update with no issues using
> > 'sudo apt-get -u dist-upgrade'. wl was alive and well after rebooting to
> > Lucid. Do you think this problem could be Kubuntu specific?
>
> During the distro sprint there were two or three people who had this,
> and they were running Ubuntu. It seems to be a DKMS problem, way below
> the desktop area.
>
> The install logs looked like DKMS just didn't bother to build the kmod
> for the new kernel during dist-upgrade while the old kernel was still
> running.
>

[Alex Murray (alexmurray)]

Just wondering if anyone thinks this could be a bug in bcmwl-kernel-source's use of dkms - there are a bunch of bugs against this driver about it failing to build correctly - I am pretty sure its use of dkms is broken - see this comment I made against bcmwl in another bug:

https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/441492/comments/5

Basically last year the nvidia package for karmic was changed (in 185.18.36-0ubuntu5):

nvidia-graphics-drivers-180 (185.18.36-0ubuntu5) karmic; urgency=low

* debian/nvidia-185-kernel-source.postinst:
    - Re-use the smart buildd detection system that we already use in the
      bcmwl-kernel-source package so as to allow pre-compiled modules when
      the nvidia driver is included in a customised image. The old behaviour
      is preserved in any other case.

So it used the same build stuff from bcmwl. Unfortunately this was found to be broken and so was fixed for nvidia later:

nvidia-graphics-drivers-180 (185.18.36-0ubuntu6) karmic; urgency=low

  * debian/nvidia-185-kernel-source.postinst:
    - There were bugs of undefined variables in the smart buildd detection
      scripts. These should be upstream DKMS anyway, so reference them
      from there (LP: #450493)

But bcmwl has not been fixed in the same way - I really suspect this could be a cause or contributing factor to this (and the other bugs)...

[Martin Pitt (pitti)]

u-foka [2010-04-20 22:54 -0000]:
> Martin, now the boot time module building is disabled in DKMS??

It shouldn't be (that would be the last line of defense), but for some
reason it apparently didn't work.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Tim Gardner (timg-tpi)]

I've just completed a full Karmic to Lucid Kubuntu upgrade with no problems. wl upgraded just fine. Can we assume the issue has disappeared?

[C.J. Collier (cjcollier)]

repros here:
https://lists.ubuntu.com/archives/ubuntu-us-wa/2010-May/000337.html

[Scott Kitterman (kitterman)]

Different bug (also not accurate IME - but that's a different question) and so should be addressed in another bug report, not this one.

[Tim Gardner (timg-tpi)]

I'm thinking this bug has solved itself and am marking it fix released.

[Jean-Baptiste Lallement (jibel)]

Tim you've set the main task to 'Incomplete', is there still something that needs to be done in maverick or na natty or shall we close that task too ?

[Scott Kitterman (kitterman)]

AFAIK this was fixed before the Lucid release.

[Jean-Baptiste Lallement (jibel)]

Thanks for following up. I'm closing the dkms task then.