Hide Forgot
+++ 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.
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This isn't a bug, its just an informative message indicating that no user space stp daemon was found, so the kernel is using its internal stp mechanism (which is the default). The only way to suppress the message is to: 1) Remove the warning entirely 2) Change the message to something more detailed 3) Install a user space stp daemon, that the kernel can start. In fedora the request was resolved by packaging and installing rstp. We can make this an RFE to package the same daemon for RHEL if you like, but theres really no advantage to running stp in user space over kernel space
It is just confusing to see, not a real problem. Now that I know it does not matter, I am fine with it as it is.