I have seen a few posts on this but have not been able to find any definitive information. I am trying to reinstall the forcedeth drivers which I understand where removed from the CentOS distributions COS is based on. I have tried a couple of RPMs but have run into dependency issues when attempting to install.
The primary install I used is one from Tim's repo(ftp://timburgess.net/repo/clearos/7/testing/x86_64/kmod-forcedeth-0.64-1.clearos.v7.x86_64.rpm) I have also included some of my system info, if anything else is needed let me know.
Thanks,
[root@clearos ~]# uname -r
3.10.0-327.10.1.v7.x86_64
[root@clearos ~]# lspci -nnv | egrep "Eth|driver"
Kernel driver in use: nForce2_smbus
Kernel driver in use: ohci-pci
Kernel driver in use: ehci-pci
Kernel driver in use: pata_amd
Kernel driver in use: sata_nv
Kernel driver in use: sata_nv
Kernel driver in use: sata_nv
00:08.0 Bridge [0680]: NVIDIA Corporation MCP55 Ethernet [10de:0373] (rev a3)
00:09.0 Bridge [0680]: NVIDIA Corporation MCP55 Ethernet [10de:0373] (rev a3)
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
01:07.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller [10ec:8169] (rev 10)
Kernel driver in use: r8169
The primary install I used is one from Tim's repo(ftp://timburgess.net/repo/clearos/7/testing/x86_64/kmod-forcedeth-0.64-1.clearos.v7.x86_64.rpm) I have also included some of my system info, if anything else is needed let me know.
Thanks,
[root@clearos ~]# uname -r
3.10.0-327.10.1.v7.x86_64
[root@clearos ~]# lspci -nnv | egrep "Eth|driver"
Kernel driver in use: nForce2_smbus
Kernel driver in use: ohci-pci
Kernel driver in use: ehci-pci
Kernel driver in use: pata_amd
Kernel driver in use: sata_nv
Kernel driver in use: sata_nv
Kernel driver in use: sata_nv
00:08.0 Bridge [0680]: NVIDIA Corporation MCP55 Ethernet [10de:0373] (rev a3)
00:09.0 Bridge [0680]: NVIDIA Corporation MCP55 Ethernet [10de:0373] (rev a3)
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
01:07.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller [10ec:8169] (rev 10)
Kernel driver in use: r8169
In Hardware
Share this post:
Accepted Answer
@ Josh http://danda.poweredbyclear.com/kmod-clearos7/kmod-forcedeth-0.64-1.v7.x86_64.rpm
Let us know how you go... If there are any errors please give exact details as best possible...
Good Luck
Edit: later "-2" version now available
http://danda.poweredbyclear.com/kmod-clearos7/kmod-forcedeth-0.64-2.v7.x86_64.rpm
Let us know how you go... If there are any errors please give exact details as best possible...
Good Luck
Edit: later "-2" version now available
http://danda.poweredbyclear.com/kmod-clearos7/kmod-forcedeth-0.64-2.v7.x86_64.rpm
Responses (25)
-
Accepted Answer
Tony Ellis wrote:
OT - but an update on the 4 port 3ware SATA controller + cables that I ordered. Received a 2-port 3ware and no cables Replied with detailed photos. Vendor refunded my money and provided a return address. When I pointed out it was his mistake and he should also pay for the shipping cost to return it, he replied telling me NOT to return it. So a free controller... Suppose not getting negative feedback on eBay is more important to him for business than this particular loss...
Buy a 2nd card and I think you can do a 4 drive RAID with 2 cards. I will give it a go on one of my computers and get back here. -
Accepted Answer
OT - but an update on the 4 port 3ware SATA controller + cables that I ordered. Received a 2-port 3ware and no cables Replied with detailed photos. Vendor refunded my money and provided a return address. When I pointed out it was his mistake and he should also pay for the shipping cost to return it, he replied telling me NOT to return it. So a free controller... Suppose not getting negative feedback on eBay is more important to him for business than this particular loss... -
Accepted Answer
-
Accepted Answer
The RTL8111/8168/8411 issue has been around since I started with ClarkConnect 4.3. The stock driver is the r8169. For some reason the r8168 has never been included in the kernel. The r8169 driver on that card can work OK, but on these forums I've seen it give big throughput issues, DNS errors, random slowing and freezing and others. Just search the forum. With the correct driver it works fine and is a good card (my m/b has it and I use it for my WAN, as I did with my previous m/b). The kmod-r8169 driver is only needed to remove compatibility with the RTL8111/8168/8411 card. It serves no other purpose. To my knowledge, I've never had problems with the kmod-r8168 driver and kernel updates.
Note this is not just a ClearOS issue. It affects all the Fedora/RHEL/CentOS stream and probably the rest of Linux as well.
I don't think I'd block all ClearOS updates. That is a bit draconian. At most, I'd just block kernel updates. At least then you'll get fixes for the rest of the O/S. -
Accepted Answer
Nick I am building servers for other people. I have been using ClearOS since V5 and the servers have been very long lived and reliable, I only replace the last V5 last month. Blocking kernel updates to protect the nvidia driver could cause another update to break. Now you tell me I need to be careful about the RTL8111/8168/8411 cards. So when these work with ClearOS7 they might not be working well? Rather worrying. Microsoft did a similar thing with Windows 10 the other week. They broke DHCP so next time the computer booted there was no networking so no way for Microsoft to send out the correction to those people.
I am wondering if it might be best to turn off all updates for this particular server which has an onboard NVIDIA NIC. -
Accepted Answer
Wayland Sothcott wrote:
At the moment there is no indication that the forcedeth driver is going to break with the upgrade to 7.3, but I am not sure of the best way of protecting yourself. Note the breakage would only happen on restart of ClearOS as the new kernel does not take effect until then.
Nick if forcedeth-kmod is going to break when ClearOS7 does an automatic update at some stage then I will need to protect against that. Or I could just use a plug in Ethernet card and not the motherboard NVIDIA one.
There are things you could possibly do:
- Block kernel updates - add "exclude=kernel*" to the end of /etc/yum.conf, but I don't know at which point you will need to update the kernel in the case that updates require a later kernel.
- In theory you could never reboot the server so it stays on the original kernel
- Check the ElRepo mirrors to see if a later version has been released but later versions may not be for kernel compatibility reasons. They could be for feature updates or bug fixes.
You could use a different NIC which is currently supported natively. I would not expect NIC support to change on anything but a major RHEL release e.g. 7.x -> 8.x.
FWIW, I also have a mickey mouse ClearOS 7 VM running in VirtualBox on my desktop. I always have the ability to compile the files there if I don't/can't do it on my production box, and a 6.x VM is now the only way I can compile drivers for 6.x.
As an aside, talking about compatible NIC's, if you ever install an RTL8111/8168/8411NIC, please install the kmod-r8168 and kmod-r8169 drivers and do not use the stock r8169 one. It may appear to work but can give you no end of problems. - Block kernel updates - add "exclude=kernel*" to the end of /etc/yum.conf, but I don't know at which point you will need to update the kernel in the case that updates require a later kernel.
-
Accepted Answer
Nick Howitt wrote:
Wayland Sothcott wrote:
Generally they survive kernel updates but there is a change between the 7.2 and 7.3 kernel that a few of them won't survive - so much so that recompiling won't help either. You need a later source rpm (which won't work with the 7.2 kernel). I have listed the ones I know about in the README file on my webserver. I've picked up the info as I follow the ElRepo mailing list.
These kmods modify the kernel I think. Do they survive updates from ClearOS OK or will we lose the network driver?
Nick if forcedeth-kmod is going to break when ClearOS7 does an automatic update at some stage then I will need to protect against that. Or I could just use a plug in Ethernet card and not the motherboard NVIDIA one. -
Accepted Answer
Tony Ellis wrote:
Nick - thanks for pointing out the newer "-2" version - have updated
Wayland - thanks for the Raid Controller tip. Just bought a LSI 3ware 9650SE-2LP 4-Ports PCIe x4 SATA RAID Controller + SATA Cable for US$21.70 inc postage
Tony, that RAID controller will work wonderfully in ClearOS7. However it was better in ClearOS5 as there was a monitoring system built into ClearOS which emailed every time RAID was being rebuilt and every time it was clean again. There is something called tw_cli from 3ware which gives some command line tools but generally you don't know if the RAID has a broken drive unless you reboot and watch the screen. This is something I will get sorted so I can keep an eye on it.
Another tip with the AMCC LSI 3Ware (or whatever they call it) RAID card is you can move the drive array to another card which has enough ports and it will just work without you having to do anything. You can even plug them in to the wrong ports and it does not matter. The only trick is that sometimes an array from a newer firmware card won't run on an older firmware card. You have to update the card's firmware. PCI card arrays are compatible with PCIe card arrays. Keep a spare card in case one blows.
A ClearOS drive or RAID array can be unplugged from one motherboard and plugged into another. All you have to do is enable the new network card from the graphical console. -
Accepted Answer
Nick - thanks for pointing out the newer "-2" version - have updated
Wayland - thanks for the Raid Controller tip. Just bought a LSI 3ware 9650SE-2LP 4-Ports PCIe x4 SATA RAID Controller + SATA Cable for US$21.70 inc postage -
Accepted Answer
Wayland Sothcott wrote:
Generally they survive kernel updates but there is a change between the 7.2 and 7.3 kernel that a few of them won't survive - so much so that recompiling won't help either. You need a later source rpm (which won't work with the 7.2 kernel). I have listed the ones I know about in the README file on my webserver. I've picked up the info as I follow the ElRepo mailing list.
These kmods modify the kernel I think. Do they survive updates from ClearOS OK or will we lose the network driver? -
Accepted Answer
-
Accepted Answer
I've added a HowTo_compile_kmod_drivers here. If we used stickies on the forum, I'd add it here as well, but we don't seem to. -
Accepted Answer
Nick Howitt wrote:
If you want to give compiling a go yourself, just let me know.
I only use AMCC 3ware RAID cards because they do well in ClearOS and are very easy to use. There are times I've had to use other cards and hunt for drivers. I dunno if I am ready for compiling but if it could help me use old hardware I should take you up on that offer. -
Accepted Answer
That is no problem. If you find any other missing drivers (NIC, RAID etc) post back. If they are available from ElRepo they are easy to compile. Note not all mirrors have archived files which can be needed for some drivers e.g. ath10k which has been removed from the main file listing.
If you want to give compiling a go yourself, just let me know. -
Accepted Answer
Nick Howitt wrote:
Thanks for the feedback. The decision to remove the driver came from RHEL which impacted CentOS then ClearOS. Fortunately some people at ElRepo still maintain some of the older drivers.
FWIW, ElRepo more recently released a -2 version of the driver which compiles cleanly in ClearOS and I've made it available here.
Nick, many thanks for that. It's a strategy of mine to get small businesses using a server. It's like making stone soup. I tell them I can build them an amazing server and all I need is an old PC. The one they give me is usually very obsolete. I build them something then say they ought to have a RAID array. I add that and suggest they need more of something else, and so on until they have the latest hardware and using their server for everything. I drag them into the late 20th Century. -
Accepted Answer
Thanks for the feedback. The decision to remove the driver came from RHEL which impacted CentOS then ClearOS. Fortunately some people at ElRepo still maintain some of the older drivers.
FWIW, ElRepo more recently released a -2 version of the driver which compiles cleanly in ClearOS and I've made it available here. -
Accepted Answer
Tony Ellis wrote:
@ Josh http://danda.poweredbyclear.com/kmod-clearos7/kmod-forcedeth-0.64-1.v7.x86_64.rpm
Let us know how you go... If there are any errors please give exact details as best possible...
Good Luck
Yes this RPM installed fine for me. Here is my procedure.
1. Get the server online using a realtek PCI card setup as normal (external role and static IP)
2. from the shell prompt as root download the above file using; wget http://danda.poweredbyclear.com/kmod-clearos7/kmod-forcedeth-0.64-1.v7.x86_64.rpm
3. install the file using; rpm -Uvh kmod-forcedeth-0.64-1.v7.x86_64.rpm
4. exit out of the shell and select Graphical console
5. Now you see the new NIC listed along with the PCI one that's linked
6. Connect the network cable to the newly appeared NIC and delete the PCI one as not needed
7. Set it as External Role and static IP as required
8. If it is the same IP as before then the network has to catch up with the new MAC address. You may need to reboot your hub.
I tried the Tim Burgess version but too many dependencies in the kernal. This one was perfect.
It's a bit of a pain that they removed NVIDIA from ClearOS7 because there are some nice cheap 64 bit boxes out there that are perfect for home ClearOS servers. I am using an HP ASUS M2N68-LA board out of an HP Compaq Desktop dx2450 PC Microtower. AMD Athlon 64 CPU in these things and they are only about £20+postage on ebay. I got some 3Ware 9650SE-2LP RAID cards cheap as well. -
Accepted Answer
@ Josh - thanks for letting me know - I will leave it available if some-body else needs to use it...
Best of luck with setting up the system.
Was an interesting yet minor exercise as I know absolutely nothing about C or its derivatives...
just used the concepts learned from other programming languages. -
Accepted Answer
-
Accepted Answer
From the ElRepo mailing list:The forcedeth-kmod source will build against RHEL 7.0 & 7.1 but not
I'd have to jump through a few steps to downgrade the kernel and its associated packages (if they are still available in the repos) before I could compile it again and that is not going to happen any time soon. Please try Tony's version. If it does not work I'll have to have a bit of a think.
against RHEL 7.2
However the kmod package built against RHEL 7.1 will install and
weak-link with all released RHEL 7.2 kernels. Example --
[ajb@Chroot64R7 ~]$ rpm -q kmod-forcedeth
kmod-forcedeth-0.64-1.el7.elrepo.x86_64
[ajb@Chroot64R7 ~]$ find /lib/modules -name forcedeth.ko | grep -E
'extra|weak' | sort
/lib/modules/3.10.0-229.el7.x86_64/extra/forcedeth/forcedeth.ko
/lib/modules/3.10.0-327.10.1.el7.x86_64/weak-updates/forcedeth/forcedeth.ko
/lib/modules/3.10.0-327.4.5.el7.x86_64/weak-updates/forcedeth/forcedeth.ko
/lib/modules/3.10.0-327.el7.x86_64/weak-updates/forcedeth/forcedeth.ko
[ajb@Chroot64R7 ~]$
If your ClearOS 7 kernels are not "way off" from the RHEL 7 kernels,
then I would suggest that you build the foredeth kmod package against
(say) kernel-3.10.0-229.el7.x86_64 (your equivalent thereof). Check if
the kmod package weak-links for the ClearOS 7.2 kernels. If yes, then
check if the driver works. -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
@ Nick - you probably got the same four errors I did just now... (against latest kernel)
The problem occurs because two header files have changed
In /usr/src/kernels/3.10.0-327.10.1.v7.x86_64/include/linux/if_vlan.h two declared functions have changed names
1 #define vlan_tx_tag_present(__skb) ((__skb)->vlan_tci & VLAN_TAG_PRESENT)
> #define skb_vlan_tag_present(__skb) ((__skb)->vlan_tci & VLAN_TAG_PRESENT)
and
2 #define vlan_tx_tag_get(__skb) ((__skb)->vlan_tci & ~VLAN_TAG_PRESENT)
> #define skb_vlan_tag_get(__skb) ((__skb)->vlan_tci & ~VLAN_TAG_PRESENT)
I added the old version names to "if_vlan.h"
In header file /usr/src/kernels/3.10.0-327.10.1.v7.x86_64/include/linux/u64_stats_sync.h two declared functions have been removed. I do not know why.
They are :-
u64_stats_fetch_begin_bh
u64_stats_fetch_retry_bh
Retrieved these from an older header file and included them in "u64_stats_sync.h"
The driver now compiles cleanly - but there is a problem - I have no means of testing the created kmod-forcedeth-0.64-1.v7.x86_64.rpm.
I am comfortable with "if_vlan.h", but not knowing why the "_bh" functions were removed worries me a bit. If it only because they thought they were of no use any more and just a spring clean, then OK, but....
It loads OK
/usr/lib/modules/3.10.0-327.10.1.v7.x86_64/extra/forcedeth/forcedeth.ko
[root@sandra ~]# modinfo /usr/lib/modules/3.10.0-327.10.1.v7.x86_64/extra/forcedeth/forcedeth.ko
filename: /usr/lib/modules/3.10.0-327.10.1.v7.x86_64/extra/forcedeth/forcedeth.ko
license: GPL
description: Reverse Engineered nForce ethernet driver
author: Manfred Spraul <[email protected]>
rhelversion: 7.2
srcversion: C8999D7105EEC214256EAD0
.... (snipped)
depends:
vermagic: 3.10.0-327.10.1.v7.x86_64 SMP mod_unload modversions
parm: max_interrupt_work:forcedeth maximum events handled per interrupt (int)
parm: optimization_mode:In throughput mode (0), every tx & rx packet will generate an interrupt.
In CPU mode (1), interrupts are controlled by a timer. In dynamic mode
(2), the mode toggles between throughput and CPU mode based on network load. (int)
parm: poll_interval:Interval determines how frequent timer interrupt is generated by [(time_in_micro_secs * 100) / (2^10)]. Min is 0 and Max is 65535. (int)
parm: msi:MSI interrupts are enabled by setting to 1 and disabled by setting to 0. (int)
parm: msix:MSIX interrupts are enabled by setting to 1 and disabled by setting to 0. (int)
parm: dma_64bit:High DMA is enabled by setting to 1 and disabled by setting to 0. (int)
parm: phy_cross:Phy crossover detection for Realtek 8201 phy is enabled by setting to 1 and disabled by setting to 0. (int)
parm: phy_power_down:Power down phy and disable link when interface is down (1), or leave phy powered up (0). (int)
parm: debug_tx_timeoutump tx related registers and ring when tx_timeout happens (bool)
[root@sandra ~]#
@Josh I can make the driver available on the understanding your system may release all the magic smoke that keeps it going :-) But. seriously it might work fine, it might completely corrupt your system and require a complete re-install... -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »