unregister_netdevice: waiting for bond0 to become free.

[travism]

Hello, all.

I'm getting the following error when I reboot or halt my Gentoo server:

unregister_netdevice: waiting for bond0 to become free. Usage count=-1

If I manually stop the VMs and unload the vbox kernel modules, I can reboot without issue. I have tried adding a custom stop script which waits for a graceful shutdown and unloads the modules. The script completes and other

This error loops endlessly, and I have to pull power to the machine in order to continue. This results in filesystem corruption. I have attached the log file as requested on the webform, and also my shutdown script (/etc/local.d/vboxtool.stop)

[travism]

VBox.log

[travism]

VBox Shutdown script

[travism]

Correction: Shutting down machines manually and unloading modules used to fix the problem but no longer does. Loop still occurs.

[travism]

Update: worked on this all day. Tried adding updated overlay from development tree: ​http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/virtualbox/?sortby=date#dirlist

Could not upgrade version.

[Frank Mehnert]

First, you will not be able to unload the VBox modules as long as there are any VMs around. So before doing anything else, check if

/sbin/lsmod | grep vbox

shows you any entries and if so, if the last count after vboxnetflt and vboxnetadp is zero. If

/etc/init.d/vboxdrv stop

does not work because some module is busy then execute the lsmod line again and look what is blocking the removal. Do

/bin/ps aux | grep VBox

to look for any active VirtualBox clients.

And I would really suggest you to upgrade to VirtualBox 4.1.20 although this should not make any difference for your problem.

[travism]

Replying to frank:

First, you will not be able to unload the VBox modules as long as there are any VMs around. So before doing anything else, check if

/sbin/lsmod | grep vbox

shows you any entries and if so, if the last count after vboxnetflt and vboxnetadp is zero. If

/etc/init.d/vboxdrv stop

does not work because some module is busy then execute the lsmod line again and look what is blocking the removal. Do

/bin/ps aux | grep VBox

to look for any active VirtualBox clients.

And I would really suggest you to upgrade to VirtualBox 4.1.20 although this should not make any difference for your problem.

Thanks for taking the time to respond to this frank.

I actually just posted the resolution. In my shutdown script, I was gracefully saving the machine state and shutting down the VMs before unloading the modules. The verbose output from the shutdown script confirmed to me that the machines were completely shut down, and the modules were successfully unloaded from the kernel before it proceeded to shutdown and get stuck in this loop.

Since I'm using a package manager, I was at the mercy of the maintainers' whim for what version of VirtualBox was available to me. I managed to find a development project that was working on working out the bugs for versions above 4.1.12. I wasn't able to update the main vbox package with it, but it updated the drivers, which resolved the issue.

I have read about this problem in previous versions of VirtualBox, and an update was the only solution I read about time and time again. I was lucky enough to find a non-mainline development project on the Gentoo development site for v4.1.20 (which I linked to in a previous comment.) Hopefully somebody else stumbles upon this and benefits from my struggles.

[Valery Ushakov]

Sounds like a duplicate of #10624. Since reported fixed in comment:4, closing it as such.