Since we agreed in bug 919472 and bug 1101045 to just move these defaults from one static file to another static file, I'm inclined to stick with that solution here, too. And as with that pair of bugs, this would require a new RHEL-7 bug to move the settings out of /usr/lib/sysctl.d/00-system.conf, which is still owned by initscripts. Sound good?

eeeegad, that's the ugliest solution I've seen so far, but I guess it'd *work*. from that perspective it seems fine, but really, stuffing sysctl calls into a modprobe.d file? well, if you're okay with it, i guess i am...:P it seems icky to me, but hey.

I would go with:

SYSCTL#1: create a udev rule ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/bridge"

as a short term solution.

Long term, we should probably add a modinfo alias like we did for devname.

# modinfo loop
filename:       /lib/modules/3.16.0-1.fc22.x86_64/kernel/drivers/block/loop.ko.xz
alias:          devname:loop-control
alias:          char-major-10-237
alias:          block-major-7-*
....


So, I could imagine:

alias: sysctl:/proc/sys/net/bridge

Note that the Fedora version of this bug (Bug 634736) has been resolved with a downstream-only patch to the systemd package. It would be *very* useful for that patch to also be in RHEL7.1, as it prevents surprises with bridge-connected virtual guests.

I *think* this BZ should be moved to systemd and the flags set to rhel-7.1.0, but am not comfortable doing that myself on a bug where I'm not the reporter or assignee for change between two packages I don't work on :-)

Adam, am I asking for the right thing?

The re-assignment seems reasonable to me. I'm not gonna touch any flags as I'm way too rusty on RHEL workflows to touch things. Note this bug is phrased to cover the general case as it may theoretically apply to *any* module; I haven't looked at the systemd fix yet, if it only covers the bridge module case specifically, arguably the general case still remains unaddressed, and we should handle that somehow (by splitting off a new bug report which covers only the bridge case and marking that as fixed, or closing this but filing a new one, or something).

Short term solution will be fixed as #1182105. As per general case, I don't think systemd is a component where fix for this should be introduced.

This was posted to the original of this BZ (filed against Fedora) last week:

(Scott Shambarger from comment #43 of Bug 634736)
> Just noticed the boot message:
> 
> bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update
> your scripts to load br_netfilter if you need this.
> 
> The new module appears to export the bridge sysctl values, but the udev rule
> in /lib/udev/rules.d/99-bridge.rules still refers to the bridge module (not
> the br_netfilter module), and so the bridge netfilter values after loading
> br_netfilter are:
> 
> net.bridge.bridge-nf-call-arptables = 1
> net.bridge.bridge-nf-call-ip6tables = 1
> net.bridge.bridge-nf-call-iptables = 1
> 
> Granted, if you load br_netfilter explicitly, you probably want to use it,
> but then /usr/sysctl.d/50-bridge.conf should probably be removed as it is no
> longer needed to disable bridge netfilter (by default) anymore.

Here is my comment on that, lifted from the same BZ:

(Laine Stump from comment #44 of Bug 634736)
> After all these years of asking for the default of bridge filtering to be
> "disabled" and the change being refused by the kernel maintainers, now the
> filtering has been moved into a separate module that isn't loaded (by
> default) when the bridge module is loaded, effectively making the default
> "disabled". Yay!
> 
> I *think* this is in the kernel as of 3.17 (It definitely is in kernel
> 3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4")
> 
> So again the problem has disappeared for our case, so we're happy, but the
> general problem (as in the latest version of this bug's summary) is still
> there. What is the proper action for this BZ then? Do we leave it around
> (knowing that, based on the experience up to now, the general problem will
> likely never be fixed), close it as WONTFIX, or close it with one or another
> of the "resolved" reasons, since our particular problem has been fixed by
> the addition of the new module?

There is a similar question for RHEL - when RHEL7 moves up to a new enough kernel (or backports the br_netfilter module) should this BZ be closed as a result, or do we leave it open in the likely fruitless hope that a general purpose solution for setting non-compiled-in defaults of kernel module settings at module load time will be implemented?

Marking as a duplicate per comment 7, and since the proposed long-term solutions don't involve kmod changes.

*** This bug has been marked as a duplicate of bug 1182105 ***

Help, after upgrading to fedora 21 boot stops after the message "bridge: automatic filtering via arp/ip/ip6table has been deprecated."  After reading these bugs and the sysctl.d manpage I believe I can fix this by using a rescue disk to implement the changes that Adam lists as SYSCTL#1 or SYSCTL#2 above.

Adam or other experts, can you clarify the edit I should make to which file with a rescue disk?

No, the problem detailed in this bug has nothing to do with a hanging boot. It only affects whether or not packets will be forwarded across a bridge device without iptables processing; that would not cause the boot to hang. It's just a coincidence that the above message just happened to be the last message logged before it hung (as a matter of fact, that message is indicating that your host would *not* have the problem that all the discussion in this bug has been trying to eliminate).

You'll need to look elsewhere for the source of your hang.