My setup consists of the following 2 network adapters: Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Device-2: Realtek USB 10/100/1G/2.5G LAN type: USB driver: r8152 both cards work as expected, however the networkcard settings about the metrics are not applied if they are set in mageia's drakconf. If setting the metric values by hand using ifmetric everything works as expected.
CC: (none) => cyril.levet0780
Thank you for the report. I reduced the severity because of the workaround: > If setting the metric values by hand using ifmetric > everything works as expected To clarify the point where things are not taken into account, could you please attach a screenshot of the relevant "networkcard settings about the metrics". Also, do you know whether if you do just one device at a time in MCC, does that get applied or not? This is to ascertain whether the problem is due to doing two devices at a time; or perhaps whether the mere presence of two devices is the reason.
Severity: major => normalCC: (none) => lewyssmithSource RPM: (none) => drakconf-13.27-1.mga8.src.rpm
The attached screens should make it clear:
I have only one device and have the same problem.
Created attachment 13162 [details] routing table after if settings
Created attachment 13163 [details] draknet_usb25gbit adapter
Created attachment 13164 [details] draknet_usb25gbit_2
Created attachment 13165 [details] draknet_pci
Created attachment 13166 [details] draknet_pci_2
Created attachment 13167 [details] Metric entries in etc interface config after draknet
when i set metric and a route using cmdline manually everything works as expected, used commands: sudo ifmetric enp34s0 10 sudo ifmetric enp3s0f0u2 5 sudo route add -net 192.168.170.161 netmask 255.255.255.255 metric 0 dev enp34s0 result: Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.170.2 0.0.0.0 UG 5 0 0 enp3s0f0u2 169.254.0.0 0.0.0.0 255.255.0.0 U 5 0 0 enp3s0f0u2 169.254.0.0 0.0.0.0 255.255.0.0 U 10 0 0 enp34s0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 192.168.170.0 0.0.0.0 255.255.255.0 U 5 0 0 enp3s0f0u2 192.168.170.0 0.0.0.0 255.255.255.0 U 10 0 0 enp34s0 192.168.170.161 0.0.0.0 255.255.255.255 UH 0 0 0 enp34s0
Thank you for all the attachments; I had not anticipated so many... They certainly make the problem clear. (In reply to Cyril Levet from comment #3) > I have only one device and have the same problem. This is worth noting; thank you. Assigning to MageiaTools, upping the priority.
CC: lewyssmith => (none)Priority: Normal => HighAssignee: bugsquad => mageiatools
(In reply to Lewis Smith from comment #11) > Thank you for all the attachments; I had not anticipated so many... > They certainly make the problem clear. lol, after 20+ years Linux and also Mandrake/Mandriva/Mageia and after being a Linux System Engineer for the same period you know how to "fill" bugreports :D :D > > (In reply to Cyril Levet from comment #3) > > I have only one device and have the same problem. > This is worth noting; thank you. Lol first i was reading "this is woth nothing" :D my bad :D have a good night. > > Assigning to MageiaTools, upping the priority.
Severity: normal => majorPriority: High => Normal
fixing prio and severity i changed by accident
Priority: Normal => HighSeverity: major => normal
Shouldn't this get some more attention? I mean it's a basic network feature that's just missing. For me of course i fixed it temporary with a .sh script i run when needed. Btw the bug should at least get changed in to confirmed, as Cyril Levet confirmed it already regards Mike
i verified this on mga 9 and it is also the case there.
Version: 8 => Cauldron
Severity: normal => major
I am trying to get a better understanding of the issue and to begin to work on a fix, can somebody explain me, what exactly does read and intepret those files in /etc/sysconfig/network-scripts/... ? is it systemd ?
manually doing ip route replace default metric 50 dev $devicename works in my test-setup maybe somebody can confirm?
systemd-sysv-generator runs the scripts in /etc/init.d/*. /etc/init.d/network runs scripts from /etc/sysconfig/network-scripts for each file in /etc/sysconfig/network-scripts/ifcfg-*
CC: (none) => davidwhodgins
I checked the scripts and was unable to find a possible error so far.
tested this on mga9 beta, still the same issue
Priority: High => release_blocker
I'm not sure, it should be considered as a release blocker. We have to add it in Mageia tools TODO list, and it could be fixed during Mageia 9 life cycle.
The network tools are on the iso images, so they can not be updated once released.
You mean on the installer. Because there are plenty of software on the ISO images. What can we do ? Network metrics code has not been checking for a long time. So there is a few chance that someone can fix quickly the bug. Do we decrease bug severity ? Because, there is a workaround using command line and Network Metric is not mandatory for installation and will not crash other network tools.
Simply having a package on the classical iso images doesn't make it a blocker unless it's actually used by the installer which this one is. Bugs on the live iso images can be considered to be a blocker depending on the severity of the bug and whether or not there is a workaround, as they are intended to be usable even without any network access. This bug affects using the installer itself, so is automatically a release blocker. As it's not a new bug, we may choose to downgrade the priority and release the iso images anyway, especially since most people do not have multiple network interfaces. We may choose to release the RC iso images, but still have this as a blocker for the final iso images. The decision to downgrade the priority will be up to the council when we are ready to discuss releasing the final iso images.
nothing release critical about it, it does not prevent installing mga9 (or prevnt distro upgrade)
Priority: release_blocker => Normal
I agree with it, however this should really be looked at after release, as it is a basic-networking function.