Bug 743584

+++ This bug was initially created as a clone of Bug #555400 +++

At the end of the boot process, I always see the following:

Bridge firewalling registered
virbr0: starting userspace STP failed, starting kernel STP

I am not sure if this indicates any real problem (would be nice to know). However, having the line flash up between boot splash and GDM startup is simply not that nice...

--- Additional comment from berrange on 2010-03-02 10:25:29 EST ---

THis isn't a libvirt problem it happens even with brctl

# brctl addbr foo
# brctl stp foo on

# dmesg  | tail -1
foo: starting userspace STP failed, starting kernel STP

The kernel appears to print this message everytime, not matter what you do. IMHO this message should be removed from the kernel, unless there's actually a clear explanation of why this is a real error.

--- Additional comment from nhorman on 2010-03-02 14:21:19 EST ---

It shouldn't be removed from the kernel, its an accurate message in response to a legitimate failure.  The kernel is trying to fork a user space to exec /sbin/bridge-stp, which is built (normally) from these sources:
http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary

But fedora hasn't packaged it, or any other rstp userspace implementation yet, so the exec fails, and the kernel backs off to the in-kernel implementation

--- Additional comment from berrange on 2010-03-03 04:09:21 EST ---

So is there any benefit to the userspace STP helper, and if so, shouldn't it be included by the bridge-utils package so its available ?  If we don't plan to include the userspace helper in Fedora, then I still think this error message should be hidden/downgraded to look less like a problem, since this bug keeps getting re-reported by people who think something is broken with libvirt+STP.

--- Additional comment from nhorman on 2010-03-03 07:26:34 EST ---

yes, theres an advantage in that STP is really an approrpiate task for userspace, and things that are can be done in user space, generally should be.

As such, yes, we should likely package it, but no one has yet

As for the warning, I don't see how it could be softened any, nor really why it should be (setting aside the odd complaints.  Its an accurate message detailing exactly what happened, and its reported at KERN_INFO level.

The right solution is to either do nothing (understand that the message is informative, but not dangerous), or package the rstp daemon.  I definately think the latter is the wisest choice.  I can try find some time to package it shortly.

--- Additional comment from berrange on 2010-03-03 07:35:38 EST ---

Ok, that plan sounds fine to me.

--- Additional comment from nhorman on 2010-03-03 09:18:40 EST ---

I'lve opened up a review request to package rstp.  I'll close this once its in, as installing the rstp package will make this warning go away.

--- Additional comment from nhorman on 2010-04-09 13:02:45 EDT ---

so, I've pushed an rstp daemon to rawhide and F-13, so we should be good to go here.


================================================================================

Seeing the same Error when booting RHEL-6.1 on a Dell M4500 laptop with libvirt installed and VMs present on the machine.