Description of problem: The networking here does not work at start if I boot with the new Cauldron kernel kernel-desktop-4.2.2-1.mga6 . If I boot with the old kernel ( 4.1.8-desktop-1.mga6 ) everything is fine. My machine's specs are: <QUOTE> My primary machine is a desktop machine with a: An Intel Core i3 CPU (x86-64). 8 GB of RAM. Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) A 2 TB hard-disk. A 21â³ Wide LCD Screen by LG. Intel Corporation Cougar Point High Definition Audio Controller. Intel Corporation 82579V Gigabit Network Connection. </QUOTE> Please let me know if you need more information. Version-Release number of selected component (if applicable): Cauldron. How reproducible: Always - tried twice. Steps to Reproduce: 1. Boot with kernel 4.2.2 2. Login. 3. Type "ping www.google.com" in the shell prompt. Reproducible: Steps to Reproduce:
An update - with the vanilla kernel 4.2.2 from kernel.org as built from source, the networking is working fine (but other stuff is broken, possibly due to missing modules that I have not built). Now I'm on kernel 4.1.8-desktop-1.mga6 and everything seems to be working fine there.
You could simply have tested kernel-linus as it's a clean kernel.org kernel built with same defconfigs as core kernel. So I guess there is a bug in the -stable net patches heading for 4.2.3 Anything in the logs ?
CC: (none) => tmb
(In reply to Thomas Backlund from comment #2) > You could simply have tested kernel-linus as it's a clean kernel.org kernel > built with same defconfigs as core kernel. > > So I guess there is a bug in the -stable net patches heading for 4.2.3 > > Anything in the logs ? Which logs are you interested in?
(In reply to Thomas Backlund from comment #2) > You could simply have tested kernel-linus as it's a clean kernel.org kernel > built with same defconfigs as core kernel. > I now tested the kernel-linus-latest of Mageia and I don't have a functional networking there either (while I did in my own 4.2.2 kernel but with a custom .config "make olfconfig" configuration). So now what do we do?
Can you attach journalctl -b from both booting working selfbuilt 4.2.2 kernel and non-working kernel-linus 4.2.2
oh, and please attach the defconfig for your selfbuilt kernel
(In reply to Thomas Backlund from comment #5) > Can you attach journalctl -b from both booting working selfbuilt 4.2.2 > kernel and non-working kernel-linus 4.2.2 Sure , stay tuned.
Created attachment 7074 [details] My config for the self-compiled kernel.
Created attachment 7076 [details] The journalctl -b output in the linus-from-make kernel where networking is fine. Here the networking is OK. It's the kernel.org kernel with the previously attached config.
Created attachment 7077 [details] The output of "journalctl -b" after booting the latest kernel-linus-4.2.2 Mageia kernel
Could this be a shorewall issue ? In your working config you have iptables/nftables support disabled so the firewall cant start... there is also something weir in your system setup... I see stuff like: /etc/sysconfig/network-scripts/ifup-eth[1212]: Device enp0s29u1u5 does not seem to be present, delaying initialization. /etc/sysconfig/network-scripts/ifup-eth[1315]: Device enp3s0u2 does not seem to be present, delaying initialization. And the physical network seems to be working as I in both logs see: dhclient[1432]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 dhclient[1432]: DHCPACK from 10.0.0.138 so you should apparently have working eth0: you could check what ifconfig and "route -n" says
(In reply to Thomas Backlund from comment #11) > Could this be a shorewall issue ? > Thanks for the lead! Good call! After I ran these commands as root and rebooted , I now have networking in 4.2.2-desktop-1.mga6 : systemctl disable iptables.service systemctl disable shorewall6.service systemctl disable shorewall.service Whenever I did <<ping 127.0.0.1>> in the mal-functioning sesssion , I got this warning: Oct 02 01:23:28 telaviv1.shlomifish.org kernel: nf_conntrack: table full, dropping packet . Regards, -- Shlomi Fish
(adding myself to the CC because I don't have wlan with kernel-desktop-4.2.2-1.mga6-1-1.mga6 on thinkpad SL510 old kernel = no problem didn't try lan, yet will read this report later)
CC: (none) => marja11
Created attachment 7079 [details] jornalctl -b output with mageia cauldron kernel-server-4.1.8 i586
CC: (none) => jyri2000
Created attachment 7080 [details] jornalctl -b output with mageia cauldron kernel-server-4.2.2 i586
Can confirm with i586 (Thinkpad X200). I can reach network at the same settings with kernel-server-4.1.8 but not with kernel-server-4.2.2. Also the boot screen with 4.2.2 says: Failed to find cpu0 device node Attached journalctl -b logs for both kernels.
Sorry, forgot to mention, that with kernel 4.2.2 the network is reachable neither with ethernet nor wifi nor mobile broadband connections.
ok, seems iptables / conntrack has problems with the new kernel that would explain shorewall getting in trouble... for now you can either boot older kernel or disable firewall...
ok, pushed: libmnl-1.0.3-7.mga6 libnfnetlink-1.0.1-6.mga6 libnetfilter_conntrack-1.0.5-1.mga6 iptables-1.4.21-4.mga6 iproute2-4.2.0-1.mga6 shorewall-4.6.13.1-1.mga6 Let me know if it works any better...
Seems to be no difference for 4.2.2... 4.1.8 still works with these updated packages OK
after installing iproute2 4.2.0 1.mga6 x86_64 iptables 1.4.21 4.mga6 x86_64 lib64ip4tc0 1.4.21 4.mga6 x86_64 lib64ip6tc0 1.4.21 4.mga6 x86_64 lib64iptables10 1.4.21 4.mga6 x86_64 lib64mnl0 1.0.3 7.mga6 x86_64 lib64netfilter_conntrack3 1.0.5 1.mga6 x86_64 lib64nfnetlink0 1.0.1 6.mga6 x86_64 shorewall 4.6.13.1 1.mga6 noarch shorewall-core 4.6.13.1 1.mga6 noarch shorewall-ipv6 4.6.13.1 1.mga6 noarch and rebooting into the new kernel: still no working network. After then doing systemctl disable iptables.service systemctl disable shorewall6.service systemctl disable shorewall.service and rebooting into the new kernel, the network works fine.
As it turns out, it really is a kernel-side regression. I will build a new one tonight with the needed fix
(In reply to Thomas Backlund from comment #22) > As it turns out, it really is a kernel-side regression. > > I will build a new one tonight with the needed fix Thx, i'll remember to systemctl enable iptables.service systemctl enable shorewall6.service systemctl enable shorewall.service before testing it :-) Changing the summary, bacause wlan and ipv6 are also affected
Summary: Networking (Ethernet IPv4) Does not work with new Cauldron kernel 4.2.2 => Networking does not work with new Cauldron kernel 4.2.2
Well, network is working, it's the firewall that is borked :)
Summary: Networking does not work with new Cauldron kernel 4.2.2 => firewall does not work with new Cauldron kernel 4.2.2
A new kernel-4.2.2-2.mga6 which should hopefully fix this is now building
(In reply to Thomas Backlund from comment #25) > A new kernel-4.2.2-2.mga6 which should hopefully fix this is now building I installed the kernel and enabled those services again, and rebooted. Now the problem is gone, I only don't know whether "dead" instead of "exited" for iptables is ok. [marja@cauldron64bit ~]$ uname -r 4.2.2-desktop-2.mga6 [marja@cauldron64bit ~]$ [root@cauldron64bit marja]# systemctl -a | grep shorewall shorewall.service loaded active exited Shorewall IPv4 firewall shorewall6.service loaded active exited Shorewall IPv6 firewall [root@cauldron64bit marja]# systemctl -a | grep iptables iptables.service loaded inactive dead iptables Firewall for IPv4 [root@cauldron64bit marja]#
ah, and "inactive" for the same instead of "active"
To check a specific service: systemctl status iptables.service also try systemctl restart iptables.service and check again systemctl status iptables.service -x and you can check if iptables is properly loaded with iptables -L
after booting this morning it was still inactive/dead restarting it brought it up. "systemctl status iptables.service -x" gave a message that x isn't a valid option. [root@cauldron64bit marja]# systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: inactive (dead) [root@cauldron64bit marja]# systemctl restart iptables.service [root@cauldron64bit marja]# systemctl status iptables.service -x systemctl: ongeldige optie -- 'x' [root@cauldron64bit marja]# systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: active (exited) since za 2015-10-03 08:05:32 CEST; 3s ago Process: 14105 ExecStart=/usr/libexec/iptables.init start (code=exited, status=0/SUCCESS) Main PID: 14105 (code=exited, status=0/SUCCESS) okt 03 08:05:32 cauldron64bit systemd[1]: Stopped iptables Firewall for IPv4. okt 03 08:05:32 cauldron64bit systemd[1]: Starting iptables Firewall for IPv4... okt 03 08:05:32 cauldron64bit systemd[1]: Started iptables Firewall for IPv4. [root@cauldron64bit marja]# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@cauldron64bit marja]# Searching journalctl to see whether there was a problem with iptables before, doesn't work well atm on this machine I'll update another cauldron, which still has the 4.1.8 kernel and where iptables is active.
Created attachment 7083 [details] journalctl -b iptables lines attaching the result of journalctl -b | grep iptables > journalctl-b_iptables
Created attachment 7084 [details] journalctl iptable lines on September 30 doing journalctl --since="2015-09-30" --until="2015-10-01" | grep iptables did give a useful output from before updating to last two kernels, attaching it.
In the other cauldron, where iptables.service was "active exited" yesterday and before updating this morning, it is "inactive dead" now. too restarting it brings it up [root@localhost marja]# uname -r 4.2.2-desktop-2.mga6 [root@localhost marja]# systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: inactive (dead) [root@localhost marja]# systemctl restart iptables.service [root@localhost marja]# systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: active (exited) since Sat 2015-10-03 08:48:11 CEST; 9s ago Process: 4468 ExecStart=/usr/libexec/iptables.init start (code=exited, status=0/SUCCESS) Main PID: 4468 (code=exited, status=0/SUCCESS) Oct 03 08:48:11 localhost systemd[1]: Stopped iptables Firewall for IPv4. Oct 03 08:48:11 localhost systemd[1]: Starting iptables Firewall for IPv4... Oct 03 08:48:11 localhost systemd[1]: Started iptables Firewall for IPv4. [root@localhost marja]# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@localhost marja]#
With the new kernel and after enabling the three services and rebooting, networking is working fine. Thanks! Regards, -- Shlomi Fish
Created attachment 7085 [details] iptables -L output after another reboot iptables service status is again: â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: inactive (dead) attaching iptables -L output from *before* restarting iptables.service
@ Shlomi with iptables.service dead, networking works fine here, too. Is your iptables.service automatically active after booting up?
(In reply to Marja van Waes from comment #35) > @ Shlomi > > with iptables.service dead, networking works fine here, too. > Is your iptables.service automatically active after booting up? I am getting: root@telaviv1:~$ systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: inactive (dead) root@telaviv1:~$ But iptables -L shows a lot of stuff.
(In reply to Shlomi Fish from comment #36) > > I am getting: > > root@telaviv1:~$ systemctl status iptables.service > â iptables.service - iptables Firewall for IPv4 > Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor > preset: enabled) > Active: inactive (dead) > root@telaviv1:~$ Thanks, Shlomi So this happens with kernel-4.2.2-2.mga6 on 3 out of 3 tested systems, so far. > > But iptables -L shows a lot of stuff. probably similar to attachment 7085 [details] Changing the summary
Summary: firewall does not work with new Cauldron kernel 4.2.2 => iptables.service is dead after booting kernel-4.2.2-2.mga6
Any news on the topic? Here fresh network install of Cauldron + Plasma5 desktop # uname -r 4.2.3-server-1.mga6 # systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: inactive (dead) # systemctl restart iptables.service # systemctl status iptables.service â iptables.service - iptables Firewall for IPv4 Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: enabled) Active: active (exited) since N 2015-10-22 12:31:43 EEST; 2s ago Process: 3225 ExecStart=/usr/libexec/iptables.init start (code=exited, status=0/SUCCESS) Main PID: 3225 (code=exited, status=0/SUCCESS) okt 22 12:31:43 tpkrom systemd[1]: Starting iptables Firewall for IPv4... okt 22 12:31:43 tpkrom systemd[1]: Started iptables Firewall for IPv4.
(In reply to Jüri Ivask from comment #38) > Any news on the topic? > > Here fresh network install of Cauldron + Plasma5 desktop > > # uname -r > 4.2.3-server-1.mga6 > Does it happen if you disable the three services and reboot? And what are the symptoms of the problem? Regards, -- Shlomi Fish
No, network is coming up OK. I mean that the iptables service is inactive (dead) after boot...
(In reply to Jüri Ivask from comment #40) > No, network is coming up OK. > > I mean that the iptables service is inactive (dead) after boot... I see.
Nothing happened to this report since October last year, and this is already the 42nd comment. Closing as OLD, since cauldron now doesn't resemble cauldron from back then. Besides, I started to doubt that iptables.service being dead is a problem at all. If the ip tables and their rules got loaded fine, then why would the service need to stay alive after that? Maybe for when a rule gets changed? But that is nearly never!
Status: NEW => RESOLVEDResolution: (none) => OLD