Bug 17683

Hi Ben,

Thanks for the bug report.

Please attach /root/drakx/report.bug.xz from this install

(please do that always when reporting traditional (so non-Live) installer bugs)

I'm not sure it also contains information about what exactly you did when setting up the network, like allowing networkmanager or not, so please tell us as precisely as possible what you did when setting it up.

Please also attach the (as root) output of journalctl, but only the part from before reconfiguring the network.

Component: RPM Packages => Installer
Keywords: (none) => NEEDINFO
CC: (none) => marja11
Whiteboard: (none) => 6dev1
Assignee: bugsquad => thierry.vignaud
Source RPM: Mageia-6-dev1-i586-DVD.iso => drakx-installer-stage2

Same goes for Wifi. Installation settings are stored for wlan, but this does not work. Renamed ifwlan in /etc/sysconfig/network-scripts and then used MCC - New interface to setup wlp5s0.

CC: (none) => herman.viaene

Created attachment 7408 [details]
report from Mate DE install, but same outcome

(In reply to Marja van Waes from comment #1)
>
> 
> I'm not sure it also contains information about what exactly you did when
> setting up the network, like allowing networkmanager or not, so please tell
> us as precisely as possible what you did when setting it up.


at end of installation, set up user configuration =>network
choose wired =>
select the network interface to configure: eth0 =>
choose connection protocol : automatic IP =>
choose IP settings: : get DNS servers from DCHP =>
choose connection control: 
allow users to manage the connection- yes
start the connection at boot - yes
allow interface to be controlled by network manager: "automatic" =>
do you want to start the connection now: choose "yes" =>

("=>" = next)

Created attachment 7409 [details]
journalctl from XFCE install, same outcome

please advise if anything else required

Created attachment 7435 [details]
iptables before

CC: (none) => nic

Created attachment 7436 [details]
iptables after

I can reproduce this report
Install Mate DE using nonfree-boot.iso and cauldron mirror
reboot
from terminal ifconfig 192.168.3.20

ping router 192.168.3.1 - connect: Network is unreachable

iptables -L -n see attachment before

drakfirewall select 'Everything - no firewall'

ping router 192.168.3.1 responds normally

iptables -L -n see attachment after

still valid for

Mageia-6-dev1-x86_64-DVD.iso
DATE.txt: Mon Mar  7 23:20:36 CET 2016

Here with the x86-64 mga6 dev1 DVD on vbox, iptables interferes with the connection, and "service iptables stop" appears to do nothing. I had to disable iptables using this script, which I had to key in manually - https://bitbucket.org/shlomif/shlomif-computer-settings/src/c20df4b49667f1dbf88f04335e3a05603cd75c1a/shlomif-settings/home-bin-executables/bin/stop-iptables?at=default&fileviewer=file-view-default . Very annoying.

CC: (none) => shlomif

It would be helpful if the output of "route" and "route -n" could also be provided.

CC: (none) => doktor5000

I have just done a fresh install using
Mageia-6-dev1-i586-DVD.iso with date of Thu Mar 10 21:45:52 CET 2016

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.17  netmask 255.255.255.0  broadcast 192.168.3.255
        inet6 fe80::a00:27ff:fed4:fb28  prefixlen 64  scopeid 0x20<link>
        inet6 2001:44b8:411f:a300:a00:27ff:fed4:fb28  prefixlen 64  scopeid 0x0<global>
        ether 08:00:27:d4:fb:28  txqueuelen 1000  (Ethernet)
        RX packets 138  bytes 9571 (9.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 4455 (4.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 4078  bytes 448998 (438.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4078  bytes 448998 (438.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 enp0s3
link-local      0.0.0.0         255.255.0.0     U     1002   0        0 enp0s3
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    0      0        0 enp0s3
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 enp0s3
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3

I stopped shorewall using service shorewall stop and the network is OK. I have added a journal log that shows 

Mar 14 18:18:27 localhost kernel: Shorewall:OUTPUT:REJECT:IN= OUT=enp0s3 SRC=192.168.3.17 DST=192.168.3.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=30371 DF PROTO=ICMP TYPE=8 CODE=0 ID=2390 SEQ=1 

Why is Shorewall running? During the install I deselected the firewall from starting.

Created attachment 7569 [details]
journalctl log

Seeing the same behavior with Plasma 5 installs both on real hardware and in VBox, both i586 and x86_64.

CC: (none) => andrewsfarm

Adding a "6dev1" keyword and setting the platform as all.

Hardware: i586 => All
Keywords: (none) => 6dev1

I could reproduce it with Mageia-6-dev1-x86_64-DVD.iso in VirtualBox. Thanks to David Hodgins it seems to be related to /etc/shorewall/interfaces:

After the default installation the content looks like:

#ZONE           INTERFACE               OPTIONS
net     eth0  detect

changing it to 

#ZONE           INTERFACE               OPTIONS
net     enp0s3  detect

and restart shorewall.service fixes the internet connection

CC: (none) => marc.lattemann

(In reply to Marc Lattemann from comment #17)
> I could reproduce it with Mageia-6-dev1-x86_64-DVD.iso in VirtualBox. Thanks
> to David Hodgins it seems to be related to /etc/shorewall/interfaces:

Yup, but the problem is not with shorewall but can be traced back to bug 17651

CC: (none) => bittwister2

I don't think bug 17651 is relevant. The networking scripts and the network works fine. If shorewall is stopped then everything works. It is more about the default configuration of shorewall.
less /etc/shorewall/interfaces
#ZONE   INTERFACE  OPTIONS
net     eth0 detect
After running drakfirewall and enabling port 22 outbound traffic is allowed. 

less /etc/shorewall/interfaces 

#ZONE  INTERFACE  OPTIONS
net     eth0  detect
net    enp0s3  detect


How is the interfaces file populated?
Does it come preset or is there a detection method?

(In reply to Nic Baxter from comment #19)
> I don't think bug 17651 is relevant. The networking scripts and the network
> works fine. If shorewall is stopped then everything works. It is more about
> the default configuration of shorewall.
> less /etc/shorewall/interfaces
> #ZONE   INTERFACE  OPTIONS
> net     eth0 detect
> After running drakfirewall and enabling port 22 outbound traffic is allowed. 
> 
> less /etc/shorewall/interfaces 
> 
> #ZONE  INTERFACE  OPTIONS
> net     eth0  detect
> net    enp0s3  detect
> 
> 
> How is the interfaces file populated?
> Does it come preset or is there a detection method?

It does not come preset. when you went back through drakfirewall, your eth0 was detected with systemd normal naming convention and it became enp0s3.

Once that was placed in interfaces "shorewall" was working.
We never had the problem in mga5 because the network configuration tool asked the user to configure enpXsY instead of ethX as it did on mga6 install.

Going to guess sysemd networking software came up on boot, saw enp0s3 was not defined and created a dynamic configuration file enp0s3 for you and then brought it up. That software did not and should not add an entry in interfaces.

So are suggesting this is an installer bug?

(In reply to Nic Baxter from comment #21)
> So are suggesting this is an installer bug?

Yes, and if you look at Source RPM: box top of this bug report, that is the current suggest culprit.

I have just installed Mageia-6-dev1-x86_64-DVD (Wed Mar 16 23:02:20 CET 2016) and when I try to configure the network from the installer summary screen the only interface available is eth0 so now I understand. Thanks Bit Twister. This is no doubt when eth0 is written to /etc/shorewall/interfaces. 

I renamed eth0 to enp0s3 during the installation and then from the summary windows was able to configure shorewall to use enp0s3 and when the installation was over the network worked.

> 3.attempt browse web via firefox
> 4. net_applet indicates network is connected.
> 5. disconnect network and reconfigure network again.
> 6. reconnect and check web browser operation - ok

Same here on real nVidia h/w, 64-bit classical .iso of 16/3.

CC: (none) => maurice

*** Bug 17893 has been marked as a duplicate of this bug. ***

CC: (none) => paiiou

*** Bug 18171 has been marked as a duplicate of this bug. ***

CC: (none) => juergen.harms

I had missed that there was already an existing bug about this issue, when this bug was filed.

Let's use first bug report.

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

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE