Hmm, strange, I also tried this, but after making the directory "ethernet" and "build" and running ./autorun.sh all I got, was this:

Check old driver and unload it.
Build the module and install
make[2]: *** No rule to make target `clean'. Stop.
make[1]: *** [clean] Error 2
make: *** [clean] Error 2

Thank you for the links, I will take a look for the BM, and see if I can do something.

I've just tried it. You can create the folder, but then you get:

[root@ClearOS6_x-h r8125-9.005.01]# mkdir -p /lib/modules/2.6.32-754.6.3.v6.x86_64/kernel/drivers/net/ethernet

[root@ClearOS6_x-h r8125-9.005.01]# ./autorun.sh



Check old driver and unload it.

Build the module and install

In file included from /usr/src/r8125-9.005.01/src/r8125.h:44,

                 from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125_ptp.h:39:31: error: linux/timecounter.h: No such file or directory

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:63: error: redefinition of ‘ether_addr_copy’

include/linux/etherdevice.h:224: note: previous definition of ‘ether_addr_copy’ was here

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:99:1: warning: "netif_printk" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2897:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:105:1: warning: "netif_emerg" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2903:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:107:1: warning: "netif_alert" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2905:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:109:1: warning: "netif_crit" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2907:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:111:1: warning: "netif_err" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2909:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:113:1: warning: "netif_warn" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2911:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:115:1: warning: "netif_notice" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2913:1: warning: this is the location of the previous definition

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:83:

/usr/src/r8125-9.005.01/src/r8125.h:117:1: warning: "netif_info" redefined

In file included from /usr/src/r8125-9.005.01/src/r8125_n.c:42:

include/linux/netdevice.h:2915:1: warning: this is the location of the previous definition

/usr/src/r8125-9.005.01/src/r8125_n.c:368: error: redefinition of ‘eth_hw_addr_random’

include/linux/etherdevice.h:211: note: previous definition of ‘eth_hw_addr_random’ was here

/usr/src/r8125-9.005.01/src/r8125_n.c: In function ‘proc_get_driver_variable’:

/usr/src/r8125-9.005.01/src/r8125_n.c:1170: error: ‘struct rtl8125_private’ has no member named ‘tot_rx_rings’

/usr/src/r8125-9.005.01/src/r8125_n.c:1171: error: ‘struct rtl8125_private’ has no member named ‘tot_tx_rings’

/usr/src/r8125-9.005.01/src/r8125_n.c: In function ‘proc_get_extended_registers’:

/usr/src/r8125-9.005.01/src/r8125_n.c:1417: warning: label ‘out’ defined but not used

/usr/src/r8125-9.005.01/src/r8125_n.c: In function ‘rtl8125_vlan_rx_register’:

/usr/src/r8125-9.005.01/src/r8125_n.c:4327: error: expected ‘;’ before ‘}’ token

/usr/src/r8125-9.005.01/src/r8125_n.c:4330: error: expected ‘;’ before ‘}’ token

/usr/src/r8125-9.005.01/src/r8125_n.c: In function ‘rtl8125_poll_msix_other’:

/usr/src/r8125-9.005.01/src/r8125_n.c:11388: warning: unused variable ‘work_to_do’

/usr/src/r8125-9.005.01/src/r8125_n.c: In function ‘rtl8125_set_real_num_queue’:

/usr/src/r8125-9.005.01/src/r8125_n.c:11877: error: void value not ignored as it ought to be

make[3]: *** [/usr/src/r8125-9.005.01/src/r8125_n.o] Error 1

make[2]: *** [_module_/usr/src/r8125-9.005.01/src] Error 2

make[1]: *** [modules] Error 2

make: *** [modules] Error 2

I have no idea how to fix this.

With respect to the Bandwidth Manager, the IMQ device no longer exists, so all references to it need to ba changed to IFB in /usr/clearos/apps/firewall/deploy/firewall.lua. There are some very minor changes also to make sure there was no attempt to invoke IMQ, Have a look in https://gitlab.com/clearos/clearfoundation/app-firewall/-/commits/master/ for the commits https://gitlab.com/clearos/clearfoundation/app-firewall/-/commit/0b4d5ea4107e28ad52d3357cd88347509f3f7df2 and https://gitlab.com/clearos/clearfoundation/app-firewall/-/commit/d87fd1454cadbc297fbf2131e8a6ae02e969c2d1. Ultimaly there are another couple of changes needed to app-qos to remove the bit which says it obsoletes app-bandwidth and to the app-configuration-backup which will no longer restore an app-bandwidth configuration. When testing you may need to manually install app-bandwidth and app-bandwidth-core then block updates to app-qos.

When I type ./autorun.sh this is what I get:

find: `/lib/modules/2.6.32-754.6.3.v6.x86_64/kernel/drivers/net/ethernet': No such file or directory

Check old driver and unload it.
Build the module and install
find: `/lib/modules/2.6.32-754.6.3.v6.x86_64/kernel/drivers/net/ethernet': No such file or directory
make: *** /lib/modules/2.6.32-754.6.3.v6.x86_64/build: No such file or directory. Stop.
make[1]: *** [clean] Error 2
make: *** [clean] Error 2


Regarding the second question. Is there anything I can do/help with the old Bandwidth Manager?
What has to be changed, so it can work in ClearOS 7.x version? Maybe I can help?

.... and it is unlikely I'll ever get time to look at the old Bandwidth Manager, but who knows?

See the legacy ClearOS6 instructions at https://www.clearos.com/clearfoundation/development/clearos/content:en_us:dev_development_environment for installing the development environment.
Thinking about it, since the kernel in 6.x is never going to change, there is no need to go down the ElRepo route. Download the drivers from https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software and follow the instructions in the README.

Thanks for the answer.
How can I compile it?

If I may ask here, did you maybe had any time yet to see, if you can make the old bandwidth manager for ClearOS 7?

No chance with 6.x. Centos6/El6 went End of Life last November so Elrepo won't touch it now. In any case the 6.x kernel is not ABI compatible with Centos/EL6 so, you'd need to try to compile it yourself whatever and see if you can get it to compile.

Hello

I would like to give an update also on this matter.
I tried the RTL8125 2.5 Gbit LAN card on ClearOS 6.10.0, but it doesn't work.

First I downloaded the rpm like Tony said with this: wget https://mirror.rackspace.com/elrepo/elrepo/el7/x86_64/RPMS/kmod-r8125-9.003.05-1.el7_8.elrepo.x86_64.rpm
Then I tried to install it with: yum install kmod-r8125-9.003.05-1.el7_8.elrepo.x86_64.rpm
But I get a lot of errors...
I guess this rpm is only for ClearOS 7.x?

When I type lspci I can see the card listed:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8125
02:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet (rev c0)
03:00.0 PCI bridge: Integrated Technology Express, Inc. IT8892E PCIe to PCI Bridge (rev 30)
04:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)

Is there anything I can do, to make it work in ClearOS 6.10.0?

Thank you

Never heard for LUA before
I did check this file, firewall.lua. It's little to much for me

It is mainly LUA, not PHP. I know virtually nothing about LUA and all I've done is virtually copying and pasting and cribbing bits of code. I think nearly all the coding is in /usr/clearos/apps/firewall/deploy/firewall.lua.

If I knew how to code in PHP I would do it But I only know a little bit in C#...

Neither are pre-installed. It would be relatively easy to make enabling one disable the other transparently but that would not be a good user experience. Really trying to enabe one when the other one is enabled should trigger a warning that it will disable the other and give you the option to continue or cancel. That is more coding than just flipping the other one off and it has to be put into both the app-qos and app-bandwidth code.

Thank you for responding.
It's a bit expensive, especially, if this would take 2, 3 or even more hours.
Thank you anyway.
I will wait, if maybe someday they will implement the old bandwidth manager back in the new versions of ClearOS.
Maybe they could make it so, that non of the manager would be preinstalled, not Bandwidth and not QoS, and you could choose later in market place, which one to install. Or it doesn't work like that?

I have responded to you ticket, but not your e-mail. I'm also posting here as public information.

The developer who would normally do this does not have and free cycles so could not take on the work. If it is going to work, the approach I outlined is the correct approach. In terms of the number of hours required, it was pretty indeterminate:

It's one of those things that might take an hour-ish in a best case scenario (review code, switch out IFB, run a bunch of tests, everything works). Or, it could take 10+ hours of going down a rabbit hole.

The hourly rate is between US$80-US$150.
I would have thought an hour is a bit tight as it needs to undo a bit of what I've done to deprecate the program (the current app-firewall and app-qos both forcibly uninstall app-bandwidth and the configuration-restore program refuses to restore it) and it may also need a mechanism adding so you can't enable both the Bandwidth Manager and QoS Manager at the same time.

I wrote to support@clearcenter.com if they can please implement the old bandwidth manager in the new versions of ClearOS. I hope that they will do it
Sponsor the app myself... how much do you have in mind?

AFAIK, a strategic decision was made a few years ago to go to the new style QoS manager. Your voice will be listened to, but in the short term, the only way to get a change such as you want, if it is technically possible, is to sponsor the app development yourself (if we can find a find a taker to do the development).

I'm sorry Nick, I didn't mean anything bad. I didn't mean "you" as a person, but "you" as ClearOS. I thought that you are a developer at ClearOS, I'm sorry, my mistake.
Do you maybe know any developer at ClearOS that I can write and ask, if they would implement the old bandwidth manager?

Flash wrote:
@Nick - So, old bandwidth manager can be implemented in ClearOS 7.x, but you won't do it? If I understand this correctly? Can I ask why not? I'm not an expert in Linux, so that "tc" that you mentioned... I don't know how to do this.

Please don't over-estimate my abilities! I am not a PHP programmer or Lua, but I can tweak both sometimes. I understand some of the background of how things are done but don't know the details. I also don't understand the tc command and I have no reasonable programming debugging tools. Yes, I have been updating things a bit and tweaking things. I don't have a test environment for something like the bandwidth monitor. In short I am not a real developer. Others do that. I'm afraid I also don't steer the direction of the apps. I also don't have any time to do it. Anyone can give it a go, but, in this case, it is too big for me.

I'm sorry for my late response, I was away.

@Tony - Not yet, because managed 2.5 Gbit/s switches are still very expensive and rare.

@Nick - So, old bandwidth manager can be implemented in ClearOS 7.x, but you won't do it? If I understand this correctly? Can I ask why not? I'm not an expert in Linux, so that "tc" that you mentioned... I don't know how to do this. This is why I chose ClarkConnect back in the day and later ClearOS 5.x and then 6.x, because of "user friendly" bandwidth manager, where you can set al the settings only by putting in numbers Because of that easy setting I don't understand, why this great feature isn't implemented anymore...?

Flash wrote:
So, if I understand correctly, the old bandwidth manager is difficult to implement in the new kernels and there is no way, that it will be implemented in the new version of ClearOS?
Do you know, if there is a Linux distribution that has the old bandwidth manager implemented in the new versions?

I have a feeling the old Bandwidth manager can be implemented, possibly relatively easily, in v7. It used to work until we switched to an upstream kernel a year ago and now, iirc, both app-qos and app-firewall forcibly remove it because the firewall now panics if you try to use it.

The underlying code is still there for the back-end in /usr/clearos/apps/firewall/deploy/firewall.lua and, perhaps, /usr/clearos/apps/qos/deploy/libqos.lua. I am not sure is app-bandwidth had its own lua script as well. The problem is that all the coding used the IMQ interface and firewall module but IMQ is longer used. Now it is IFB. Perhaps it can nearly all be resurrected by changing any IMQ references to IFB, but I don't know. You are welcome to have a look. There is a big but. While finishing off app-qos it was realised there was a big logic problem with the QoS firewall rules which, I believe, also affected app-bandwidth in that packet marking was (and still is) used to for different packets, but the marks overwrote marks from different apps such as MultiWAN, ibVPN and I think there was one other. To get round it all the QoS marks were changed to to a logical and to any existing marks and it was made sure each app used a different few bits of the available marking space. This logic may be needed to be backported from the IFB code to the IMQ code.

You can even implement something manually if you really want using references to tc that I mentioned earlier.

I am afraid there is no intention to revisit the app for now but the community is welcome to have a look.

I also don't know of any other distro which implements what you want, but you could try some of the classic firewall ones.

Have you considered using managed switch(es) for per port bandwidth control?

Hi Nick

Yes, in your scenario I understand that the new bandwidth manager is great, but for me, it isn't. I don't need that. I want to limit the speed of the devices, I don't care if one device can't use full bandwidth, it still has a big amount.
So, if I understand correctly, the old bandwidth manager is difficult to implement in the new kernels and there is no way, that it will be implemented in the new version of ClearOS?
Do you know, if there is a Linux distribution that has the old bandwidth manager implemented in the new versions?

Thank you

The old bandwidth manager requires us to patch the kernel which was becoming increasingly difficult and onerous to keep up with the upstream minor releases. There is a thread on the forum somewhere about using "tc" to achieve what you want. This is what ClearOS used to do under the skin, and it should still be possible with the current kernel. Google "tc bandwidth limit".

The old bandwidth manager was a simple limiter. The newer one is much cleverer and allows any device the full bandwidth if no one else is using it which does not waste you bandwidth. At the moment I am doing a huge amount upload testing for some decentralised storage for the ClearPHONE but I only have a 50/15 line. Using the new QoS manager (with a custom rule, albeit), I have set all devices on my LAN to priority 4 except for the server doing the upload testing. If I watch the traffic, as soon as I push a file out from another PC to the internet or do some video chatting, I can see the bandwidth manager immediately cut back the traffic from the upload testing and my call quality remains good. As soon as my call finishes, I see the bandwidth being used by the upload test increase. This is great. It could not have been done with the old bandwidth limiter.

Because RTL8125 is 2.5Gbit/s and I would like to have higher data transfer over my LAN.

In old Bandwidth Manager you can limit dl/ul speed to a single IP or IP range, I need this.

Why ClearOS fears to implement the old Bandwidth Manager into never versions? Does it take up terabytes of space or what?

Do you know a different Linux distribution that has that kind of Bandwidth Manager implemented?

Flash, Why do you need support for the 8125 and why is the Old Bandwidth Manger so important ?

Or has ClearOS finally come to their senses and has implemented the old Bandwidth Manager in ClearOS 7?

Not going to happen as you appear to have already accepted... As newer hardware gets introduced you will find it increasingly difficult to run an old OS that lacks the necessary support and be stuck with your old hardware.

Some choices for you...

1) Run a more modern OS on the bare hardware that has support for the 8125 and your ClearOS 6.x in a VM
2) Choose something different to the 8125 that your ClearOS 6.x does support
and better
3) Forget the Old Bandwidth Manger and find something else to replace it - even if it is running something other than ClearOS

Hello Tony, thanks for your answer.

Yes, I know that ClearOS 6 went EOL, but, ClearOS 6 has the old (and the best ) Bandwidth Manager and I need it.

Or has ClearOS finally come to their senses and has implemented the old Bandwidth Manager in ClearOS 7?

Flash - doubt it out of the box. Read this thread here you posted in to see what was necessary to gain support for 7. Since EOL for CentOS 6 is November 30, 2020 would think it unlikely that elrepo would be interested in producing a driver for CentOS verison 6. You realize don't you that ClearOS 6 went EOL 1 Sep 2019 and is no longer supported. That is over a year ago. As time goes by becomes more and more a liability on the internet. Get yourself a copy of ClearOS 7.x and use the kmod discussed here...

Hello

Can somebody please tell me, if ClearOS 6.9 or 6.10.0 supports the Realtek RTL8125 2.5Gbit LAN card?

Thank you

Glad you've succeeded. Please remember to post back to the ElRepo mailing list. They will then release the driver in their repos and will generally keep it updated if it needs recompiling for kernel upgrades.

Looks like we've made some progress.
I haven't passed any real traffic through it, but it's working.
Gonna stress it a bit to be sure it's stable then gonna reload it and put it in production.
I'll post back here as I make progress.

I chose this board as a COVID tinkering project.
It's got everything I was looking for.
Inexpensive, compact, quiet, runs pretty cool, dual NIC, NVMe, SATA, up to 32gb DDR4, x86 SBC.
And... I learned a little bit thanks to you guys
Gonna replace my old COS gateway / minecraft server.
Only down side so far is the 3 LEDs are extremely bright... so, not ideal in a bedroom... as my wife has pointed out.
Gonna have to get creative with the electrical tape to fix those LEDs.

Can't thank you guys enough.

enp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        inet 192.168.25.1  netmask 255.255.255.0  broadcast 192.168.25.255

        ether 00:1e:06:45:3d:68  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 92  



enp3s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        ether 00:1e:06:45:3d:69  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 93  



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 1000  (Local Loopback)

        RX packets 150  bytes 13013 (12.7 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 150  bytes 13013 (12.7 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Thanks fellas... I understand now.
I plan to test this all out today and will report back.
I have a USB ethernet adapter that works fine and will go that route to test this all out.

I think you have s slight misunderstand on how things work. As a separate rpm it will never be included in the kernel. The driver you have installed will be compatible with and ClearOS 7.8 kernel. It could be compatible with prior kernels and may be compatible with 7.9+ kernels but this is unknown. It depends on what symbols are available in each kernel and that is up to Redhat. Many drivers survive an upgrade of minor Centos 7.x/EL7.x versions. My two favourites, the kmod-r8168 and kmod-r8169 did. My wifi NIC, the rtl8812au did not survive, but once ElRepo compile your modules then generally automatically recompile them as necessary.

ElRepo modules will not be put into the ClearOS repos for the moment. The exception is two that I compile independently of ElRepo and they need to remain there for historical reasons going back to when the ClearOS kernel was not the same as the Centos kernel.

You can add the ElRepo repo to ClearOS and they have a neat feature such that non-compatible drivers are not presented to yum if you kernel has not been updated. As an example, if I were running the rtl8816au driver and Redhat released El7.9 which happened to be incompatible with the 7.8 kernel, the 7.9 compatible modules would not be presented to Centos 7.8 and ClearOS 7.8 users until their O/S's had upgraded to 7.9 weeks or months later. Because of this it **may** be safe to leave the repo enabled but I have never tested it.

It does mean you have to watch upgrades whatever and if an upgrade breaks compatibility and stops your NIC from working, boot to an earlier kernel, upgrade the rpm and reboot. Personally if the ElRepo repo trick does not install, I'd always locally download the rpm before installing so I have a local copy. This means you can reboot to the newest kernel and, even without working NIC's, just install from your local copy.

I don't know about the secure boot side of things as I don't use it.

Please can I ask, that since ElRepo have kindly provided the rpm, you test it and give feedback to them. If it is good they will release it into their production repos.

Regarding item 2 in my list above...
Popped the r8125 rpm onto a test machine - then pulled the two ethernet cables and attempted an install using yum. It complained about not being able to reach the ClearCentre Marketplace, but continued. All depenencies were met and the rpm installed OK.

However it would not load - error regarding ELRepo Secure Boot key not available. Looking at Import the ELRepo key would probably solve this problem, but you would need to do the "wget" mentioned when you fetch the kmod rpm and then copy both to the newly installed ClearOS - then ensure both are loaded. I have not tried this...

The simplest solution is to use a USB ethernet NIC as mentioned before. Pity this board doesn't have a PCI or PCIe slot and use of an old PCI(e) NIC would be possible...

Really appreciate the help on this.
So, does that mean that in 2+ weeks the kernel that includes this driver will be available in ClearOS?
If so, are there particular repos I'd need to enable to install this kernel?

I responded to the mailing list. It is not just a compatible kernel. It is the kernel from Centos unchanged (and is probably a vanilla RHEL kernel).Clearcenter updates their kernels about a week behind Centos for Community systems and 2 weeks for Business systems.

Looks like they compiled it.
Is ClearOS 100% binary compatible with RHEL?
And, how does this kernel make it's way to my ClearOS box?
What's the sequence of events?

Message: 5



Date: Tue, 11 Aug 2020 20:09:55 +0100



> OK, we could try it. One potential issue is that the ClearOS kernel is

> not 100% binary compatible with RHEL. So the package will have to be

> rebuilt for ClearOS.

>





We have built a kmod-r8125 package and released it to the main elrepo

repository. Packages are syncing to the mirrors and should be available

shortly:



kmod-r8125-9.003.05-1.el7_8.elrepo.x86_64.rpm

r8125-kmod-9.003.05-1.el7_8.elrepo.src.rpm



Please would you test and let us know how you get on.



Thanks,





------------------------------



Message: 6



Announcing the release of the kernel-ml-5.8.1-1.el7.elrepo package set

into the EL7 elrepo-kernel repository:



https://elrepo.org/tiki/kernel-ml



The upstream changelog:



https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.8.1



The following files are currently synchronising to our mirror sites:



x86_64

kernel-ml-5.8.1-1.el7.elrepo.x86_64.rpm

kernel-ml-devel-5.8.1-1.el7.elrepo.x86_64.rpm

kernel-ml-doc-5.8.1-1.el7.elrepo.noarch.rpm

kernel-ml-headers-5.8.1-1.el7.elrepo.x86_64.rpm

kernel-ml-tools-5.8.1-1.el7.elrepo.x86_64.rpm

kernel-ml-tools-libs-5.8.1-1.el7.elrepo.x86_64.rpm

kernel-ml-tools-libs-devel-5.8.1-1.el7.elrepo.x86_64.rpm

perf-5.8.1-1.el7.elrepo.x86_64.rpm

python-perf-5.8.1-1.el7.elrepo.x86_64.rpm



nosrc

kernel-ml-5.8.1-1.el7.elrepo.nosrc.rpm



Note: As a consequence of the upstream decision [1] to raise the

minimum required version of gcc to 4.9, the distribution compiler can

no longer be used in the kernel build process. We now use gcc-9, which

is available from the devtoolset-9 package.



We provide these kernels for hardware testing in an effort to identify

new/updated drivers which can then be targeted for backporting as kmod

packages. Meanwhile, these kernels may provide interim relief to

people with non-functional hardware. We stress that we consider such

kernels as a last resort for those who are unable to get their

hardware working using the RHEL-7 kernel with supplementary kmod

packages.



These packages are provided "As-Is" with no implied warranty or

support. Using the kernel-ml may expose your system to security,

performance and/or data corruption issues. Since timely updates may

not be available from the ELRepo Project, the end user has the

ultimate responsibility for deciding whether to continue using the

kernel-ml packages in regular service.



The packages are intentionally named kernel-ml so as not to conflict

with the RHEL-7 kernels and, as such, they may be installed and

updated alongside the regular kernel. The kernel configuration is

based upon a default RHEL-7 configuration with added functionality

enabled as appropriate.



If a bug is found when using these kernels, the end user is encouraged

to report it upstream to the Linux Kernel Bug Tracker [2] and, for our

reference, to the ELRepo bug tracker [3]. By taking such action, the

reporter will be assisting the kernel developers, Red Hat and the Open

Source Community as a whole.

Well, in ClearOS what made me think it compiled correctly is because it didn't give any errors that I saw when I followed these instructions:
https://wiki.odroid.com/odroid-h2/hardware/install_r8125_dkms
But, it didn't work... and what REALLY made me think it was working is my ignorance

But, in Fedora 32, it complied just fine. I'm actually posting here from this machine.
I'm going to use this machine as my workstation for a while to be sure things are working ok, then I'll reach out to the people at elrepo and see what happens.

[[bryan@localhost ~]$ lspci

00:00.0 Host bridge: Intel Corporation Gemini Lake Host Bridge (rev 03)

00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 605 (rev 03)

00:0e.0 Audio device: Intel Corporation Celeron/Pentium Silver Processor High Definition Audio (rev 03)

00:0f.0 Communication controller: Intel Corporation Celeron/Pentium Silver Processor Trusted Execution Engine Interface (rev 03)

00:12.0 SATA controller: Intel Corporation Device 31e3 (rev 03)

00:13.0 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)

00:14.0 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)

00:14.1 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)

00:15.0 USB controller: Intel Corporation Device 31a8 (rev 03)

00:17.0 Signal processing controller: Intel Corporation Device 31b4 (rev 03)

00:17.1 Signal processing controller: Intel Corporation Device 31b6 (rev 03)

00:17.2 Signal processing controller: Intel Corporation Device 31b8 (rev 03)

00:17.3 Signal processing controller: Intel Corporation Device 31ba (rev 03)

00:1c.0 SD Host controller: Intel Corporation Celeron/Pentium Silver Processor SDA Standard Compliant SD Host Controller (rev 03)

00:1f.0 ISA bridge: Intel Corporation Device 31e8 (rev 03)

00:1f.1 SMBus: Intel Corporation Celeron/Pentium Silver Processor Gaussian Mixture Model (rev 03)

01:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 04)

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 04)





[bryan@localhost ~]$ lshw -class network

WARNING: you should run this program as super-user.

  *-network                 

       description: Ethernet interface

       product: RTL8125 2.5GbE Controller

       vendor: Realtek Semiconductor Co., Ltd.

       physical id: 0

       bus info: pci@0000:02:00.0

       logical name: enp2s0

       version: 04

       serial: 00:1e:06:45:3d:68

       capacity: 1Gbit/s

       width: 64 bits

       clock: 33MHz

       capabilities: bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation

       configuration: autonegotiation=on broadcast=yes driver=r8125 driverversion=9.003.05-NAPI latency=0 link=no multicast=yes port=twisted pair

       resources: irq:133 ioport:e000(size=256) memory:a1200000-a120ffff memory:a1210000-a1213fff

  *-network

       description: Ethernet interface

       product: RTL8125 2.5GbE Controller

       vendor: Realtek Semiconductor Co., Ltd.

       physical id: 0

       bus info: pci@0000:03:00.0

       logical name: enp3s0

       version: 04

       serial: 00:1e:06:45:3d:69

       size: 1Gbit/s

       capacity: 1Gbit/s

       width: 64 bits

       clock: 33MHz

       capabilities: bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation

       configuration: autonegotiation=on broadcast=yes driver=r8125 driverversion=9.003.05-NAPI duplex=full ip=192.168.55.139 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s

       resources: irq:135 ioport:d000(size=256) memory:a1100000-a110ffff memory:a1110000-a1113fff

WARNING: output may be incomplete or inaccurate, you should run this program as super-user.





[bryan@localhost ~]$ ifconfig

enp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        ether 00:1e:06:45:3d:68  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 133  



enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.55.139  netmask 255.255.255.0  broadcast 192.168.55.255

        inet6 fe80::833f:c741:1d2d:cc02  prefixlen 64  scopeid 0x20<link>

        ether 00:1e:06:45:3d:69  txqueuelen 1000  (Ethernet)

        RX packets 62393  bytes 74013230 (70.5 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 34814  bytes 3725715 (3.5 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 135  



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 1000  (Local Loopback)

        RX packets 91  bytes 5813 (5.6 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 91  bytes 5813 (5.6 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255

        ether 52:54:00:f4:c0:e0  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



[bryan@localhost ~]$ lsmod | egrep 'r8125|Module' 

Module                  Size  Used by

r8125                 184320  0

[bryan@localhost ~]$ 

I've just tried an ElRepo kernel-ml and it does not have the r8125 in it, so it has not yet been incorporated into any kernel. This means your most hopeful route is to ask if the people at ElRepo can compile it for you. Often they like to know from you it will compile OK.

What makes you think it compiled correctly when you did it? Did you try loading manually it with "modprobe r8168"?

Thanks for the suggestion.
Compiled just fine in Fedora 32 and working great.
Being this is just a board for me to tinker with, I'm going to dig into the elrepo kernel.
And, I'm going to create an RFE.
It's a neat little inexpensive board that would be great for this application.

As an alternative but also outside you comfort zone, you could try using a full ElRepo kernel (kernel-ml) which probably has it built in. Elrepo kernels should be compatible with ClearOS but I have never tried them.