kernel: unregister_netdevice: waiting for vboxnet1 to ...

[Nightshade]

Anyone remember which release of Vbox first had this bug?

Not VirtualBox but the kernel has changed something. The last 3.2.x vanilla
kernel without problems is 3.2.17.

Ubunutu seems to have fixed the problem. Therefore I downloaded
"virtualbox-dkms_4.1.16-dfsg-2_all.deb", unpacked it and replaced
the original VBoxNetFltInternal.h and linux/VBoxNetFlt-linux.c with those from Ubunutu.
Recompiling the VB modules, reboot and since 2 days it is working for me with a 3.2.20.

[4x5n]

Anyone remember which release of Vbox first had this bug?

Not VirtualBox but the kernel has changed something. The last 3.2.x vanilla
kernel without problems is 3.2.17.

Ubunutu seems to have fixed the problem. Therefore I downloaded
"virtualbox-dkms_4.1.16-dfsg-2_all.deb", unpacked it and replaced
the original VBoxNetFltInternal.h and linux/VBoxNetFlt-linux.c with those from Ubunutu.
Recompiling the VB modules, reboot and since 2 days it is working for me with a 3.2.20.

I'm currently running Fedora and am wondering where you got that virtualbox package from.

[Nightshade]

I'm currently running Fedora and am wondering where you got that virtualbox package from.

http://launchpadlibrarian.net/107417651 ... -2_all.deb

(Working with Fedora you need something like dpkg installed to unpack the *.deb file
for example in /tmp and then "steal" the 2 files from there. I'm working with Gentoo
and do not know much about Fedora.)

[Perryg]

Fedora doesn't normally use deb files they use rpm file.
Please don't mix and match these packages. It will haunt you sooner or later and support will be impossible.

[Nightshade]

Fedora doesn't normally use deb files they use rpm file.
Please don't mix and match these packages. It will haunt you sooner or later and support will be impossible.

Of course. Don't install the packet. As I wrote, only (!!) unpack it in /tmp with dpkg or use
mc to extract the needed files and then steal only those 2 files.

[Perryg]

Same thing. The structure from the Ubuntu repo and the one from Fedora will be different. They have different dependencies and these (from the repo) are not the same as the one from VirtualBox.org. So you are still mixing the code. The different distros take the source code and revise it to what they want it to do. Its your system but I have seen a lot of people having issues that were inflicted upon themselves when it could have been averted.

[Nightshade]

Same thing. The structure from the Ubuntu repo and the one from Fedora will be different. They have different dependencies and these (from the repo) are not the same as the one from VirtualBox.org. So you are still mixing the code.

Yes. It' s not a perfect solution. I know. The perfect solution would be a new release of VB.
While we wait for this release, the workaround works for me with the actual longterm stable.
It should only be a hint what can be tried (with all risks of course) in the meantime if
you need the actual kernel and VB until the new VB release is out.

[4x5n]

Yes. It' s not a perfect solution. I know. The perfect solution would be a new release of VB.
While we wait for this release, the workaround works for me with the actual longterm stable.
It should only be a hint what can be tried (with all risks of course) in the meantime if
you need the actual kernel and VB until the new VB release is out.

I've found the package and copied those two files to the source for the modules and for now it seems to work. It's not the best of solutions but it's better then having to simply powering off my machine. It'll have to do until it's fixed in VB.

[4x5n]

Same thing. The structure from the Ubuntu repo and the one from Fedora will be different. They have different dependencies and these (from the repo) are not the same as the one from VirtualBox org. So you are still mixing the code. The different distros take the source code and revise it to what they want it to do. Its your system but I have seen a lot of people having issues that were inflicted upon themselves when it could have been averted.

I took a header file and C source file for the voxdrv module and copied it from the debian package onto my harddrive and replaced files of the same name that were installed when I installed vbox. I then recompiled the module. I of course made a back up of the original files. For what it's worth I haven't had any more trouble with unloading the module. This includes a number of tests that forced a power cycle everytime prior. Is it ideal? Of course not. The "real" solution is for Oracle to fix the bug and provide a working release. Until then I'm going to stick with this "patch".

[macachuto]

I did the same for my Fedora. Downloaded deb package, extracted two files and recompiled kernel modules. Now it works.

Thanks for solution.