Description of problem: Depreciated command in some start up file. journalctl | grep depr snippet follows: kernel: bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. clean install of -x86_64-DVD.iso Pick Custom install for all package groups and just Gnome and Kde DE'S 2. install all updates 3. as root, journalctl | grep deprecated Reproducible: Steps to Reproduce:
Could you try to identify the services that trigger this message? Adding our systemd maintainer in CC for opinion.
CC: (none) => mageia
(In reply to Samuel VERSCHELDE from comment #1) > Could you try to identify the services that trigger this message? When I open a bug report I do try to figure out the src rpm. Guess I need to learn to use google. > Adding our systemd maintainer in CC for opinion. Good call. Problem supposedly fixed in systemd-219 https://bugzilla.redhat.com/show_bug.cgi?id=634736 I am dead in the water as far as testing mga5->cauldron upgrade (see bug 16647) since systemd 217 was installed on Mga5
Just to be sure, what version of systemd are you currently running?
Assignee: bugsquad => mageia
(In reply to Samuel VERSCHELDE from comment #3) > Just to be sure, what version of systemd are you currently running? $ systemd --version systemd 217 $ cat /etc/product.id vendor=Mageia.Org,distribution=Mageia,type=Basic,version=5,branch=Official,release=5,arch=x86_64,product=Default
So this isn't a cauldron bug but rather a Mageia 5 bug? Or is it a cauldron with an old systemd because of bug 16647? If it's Mageia 5, set the bug to Mageia 5. If it's cauldron, then it's probably fixed, but we need to wait for an update so that you can test, if I understood correctly.
(In reply to Samuel VERSCHELDE from comment #5) > So this isn't a cauldron bug but rather a Mageia 5 bug? Or is it a cauldron > with an old systemd because of bug 16647? Problem showed up in Mageia 5 but since I thought it a minor problem, I thought I would report it on Cauldron. > If it's Mageia 5, set the bug to Mageia 5. If it's cauldron, then it's > probably fixed, Nope, problem still in cauldron now that it has been updated to to 217 same as Mageia 5. > but we need to wait for an update so that you can test, if I understood > correctly. Keep in mind I am testing upgrading mga5 to cauldron and systemd is hanging forever using systemd 217 which now on mga5.
Whiteboard: (none) => MGA5TOOSummary: mga6: automatic filtering via arp/ip/ip6tables has been deprecated => Error messages with systemd 217: automatic filtering via arp/ip/ip6tables has been deprecatedSource RPM: (none) => systemd
Note that the fedora bug is still open and the hack used to "fix" it was removed. See https://bugzilla.redhat.com/show_bug.cgi?id=634736#c39 As per your comments, it doens't seem too serious besides an annoying warning.
(In reply to Colin Guthrie from comment #7) > Note that the fedora bug is still open and the hack used to "fix" it was > removed. See https://bugzilla.redhat.com/show_bug.cgi?id=634736#c39 Per the redhat comment 39, I'll move it to bridge-utils > As per your comments, it doens't seem too serious besides an annoying > warning. 1. if any application reports "deprecated" I suggest the deprecated activity/cmd should be fixed in the next release cycle to prevent a possible hard failure upon new release without the command. 2. System admins do not need any "annoying warning". In my stupid opinion, the journal should be free of anything besides "info" messages before the alpha1 is created. :) 3. When I googled automatic filtering via arp/ip/ip6tables has been deprecated I saw all sorts of problems being introduced about bridging and that networkmanager/network.service was not managing it well and there were comments about firewall setting. I also thought I had seen something somewhere where the latest systemd release fixed it. Currently loosing a lot of spare Cauldron testing time waiting on new systemd. :-D I have an automated desktop checker scrip to run a go/no go on all apps in the task bar menu which I would like to run before the alpha1 iso is built.
Source RPM: systemd => bridge-utils
Summary: Error messages with systemd 217: automatic filtering via arp/ip/ip6tables has been deprecated => 6_s1: automatic filtering via arp/ip/ip6tables has been deprecated
Source RPM: bridge-utils => bridge-utils-1.6-1.mga6.src.rpmStatus comment: (none) => 6_s2Summary: 6_s1: automatic filtering via arp/ip/ip6tables has been deprecated => automatic filtering via arp/ip/ip6tables has been deprecated
Keywords: (none) => 6sta2Status comment: 6_s2 => (none)
Whiteboard: MGA5TOO => (none)
(In reply to Bit Twister from comment #8) > (In reply to Colin Guthrie from comment #7) > > Note that the fedora bug is still open and the hack used to "fix" it was > > removed. See https://bugzilla.redhat.com/show_bug.cgi?id=634736#c39 > > Per the redhat comment 39, I'll move it to bridge-utils > bridge-utils has a different maintainer (at least now it does), so reassigning to him.
Whiteboard: (none) => MGA6TOOCC: (none) => marja11Assignee: mageia => shlomifKeywords: 6sta2 => (none)
This bug is old, and in my test did not show the fault on Mageia 7: bridge-utils-1.6-2.mga7 # journalctl -b -0 | grep deprecated | grep -v plasma-discover Tach 28 09:26:05 localhost.localdomain klauncher[19432]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Tach 28 09:26:25 localhost.localdomain plasmashell[19490]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) # [plasma-discover is superfluous] For the rest - nothing. So can Bit Twister confirm whether the problem still exists or not? TIA. Hopefully we can close the bug.
CC: (none) => lewyssmith
I no longer use plasma and only installing xfce as my DE and have disabled ipv6. # journalctl | grep depr returns nothing, so I'll go ahead and close it resolved/fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED