Notice
ClearOS 7.4 Beta
ClearOS 7.4 is nearing its general release. We are happy to announce the Beta for ClearOS 7.4. This is an exciting update that includes a bunch of new features as well as some new apps in the ClearOS Marketplace. To participate in this beta you will update your existing ClearOS 7.3 system using the testing repositories. We recommend that you update your system before applying any Beta updates:
yum update
After you confirm this, upgrade by running:
yum --enablerepo=clearos-updates-testing upgrade app-base
yum upgrade
At this point, the following repositories have been enabled for the beta:
clearos-updates
clearos-updates-testing
clearos-centos
clearos-centos-updates
Once completed, you will be running ClearOS 7.4. You may experience certain usability issues with the Marketplace as you will be ahead of the release cycle.
Please note the following KNOWN issues with ClearOS 7.4:
- Currently some issues exist with the upstream packaging for Samba which can and will cause issues with the Active Directory Connector. These are actively being worked on both internally and upstream and a fix should be forthcoming soon.
The following roadmap of events can be expected for this release:
* ClearOS 7.4 Beta packages assembled in the testing repos (happening today)
* ClearOS 7.4 Community Release
* ClearOS 7.4 Home/Business Release
Timeline:
Typically we need to allow for a week of non-blocking bug fixes between each stage. If blocking issues occur in a stage, it will prevent entrance into the next stage of release. To release quickly we are calling on the ClearOS Community members to test various apps and features of ClearOS. Naturally, the apps and services most crucial to you deserve your special attention.
Known issues:
It is known that the upstream Samba packages cause issues with the Active Directory Connector. As such, we will be using the existing Samba packages from 7.3 with the initial release and will merge the upstream packages when they are more stable.
ClearOS Marketplace:
Microsoft SQL Server app
Wordpress (Beta) app
Kapano app (Zarafa Replacement) (https://www.clearos.com/resources/documentation/clearos/content:en_us:7_kb_zarafa_to_kopano_upgrade)
PHP Engine app
LetsEncrypt
Dynamic Firewall
2-Factor Authentication for Webconfig
ClearOS Platform Improvements:
Backend SSSD improvements
OpenLDAP improvements such as LMDB improvements
Samba updates disable NTLMv1
Improved backend Clustering support
SSL/TLS certificate verification for HTTP client by default in Python
Improvements to Perl modules
NFS server now support limited copy-offload. Settings consolidated in nfs.conf.
Improvements to support of Intel PCH devices
RAID chunk size support in Anaconda
Anaconda now support IPoIB interfaces
Improvements to Anaconda Kickstart parameters
NVMe driver updated
Better random number generation support in kernel
Improved kernel support for switch and virtual switch processes
Framework for ‘usbguard’ to prevent access to unauthorized USB devices
Improvements to openssh and openssl
Improvements to libreswan
LVM support for RAID level takeover and reshaping which allows for conversion between RAID types and RAID parameters
Backend Certificate improvements
Once the beta is over, users should run:
yum-config-manager --disable clearos-updates-testing
yum update
After you confirm this, upgrade by running:
yum --enablerepo=clearos-updates-testing upgrade app-base
yum upgrade
At this point, the following repositories have been enabled for the beta:
clearos-updates
clearos-updates-testing
clearos-centos
clearos-centos-updates
Once completed, you will be running ClearOS 7.4. You may experience certain usability issues with the Marketplace as you will be ahead of the release cycle.
Please note the following KNOWN issues with ClearOS 7.4:
- Currently some issues exist with the upstream packaging for Samba which can and will cause issues with the Active Directory Connector. These are actively being worked on both internally and upstream and a fix should be forthcoming soon.
The following roadmap of events can be expected for this release:
* ClearOS 7.4 Beta packages assembled in the testing repos (happening today)
* ClearOS 7.4 Community Release
* ClearOS 7.4 Home/Business Release
Timeline:
Typically we need to allow for a week of non-blocking bug fixes between each stage. If blocking issues occur in a stage, it will prevent entrance into the next stage of release. To release quickly we are calling on the ClearOS Community members to test various apps and features of ClearOS. Naturally, the apps and services most crucial to you deserve your special attention.
Known issues:
It is known that the upstream Samba packages cause issues with the Active Directory Connector. As such, we will be using the existing Samba packages from 7.3 with the initial release and will merge the upstream packages when they are more stable.
ClearOS Marketplace:
Microsoft SQL Server app
Wordpress (Beta) app
Kapano app (Zarafa Replacement) (https://www.clearos.com/resources/documentation/clearos/content:en_us:7_kb_zarafa_to_kopano_upgrade)
PHP Engine app
LetsEncrypt
Dynamic Firewall
2-Factor Authentication for Webconfig
ClearOS Platform Improvements:
Backend SSSD improvements
OpenLDAP improvements such as LMDB improvements
Samba updates disable NTLMv1
Improved backend Clustering support
SSL/TLS certificate verification for HTTP client by default in Python
Improvements to Perl modules
NFS server now support limited copy-offload. Settings consolidated in nfs.conf.
Improvements to support of Intel PCH devices
RAID chunk size support in Anaconda
Anaconda now support IPoIB interfaces
Improvements to Anaconda Kickstart parameters
NVMe driver updated
Better random number generation support in kernel
Improved kernel support for switch and virtual switch processes
Framework for ‘usbguard’ to prevent access to unauthorized USB devices
Improvements to openssh and openssl
Improvements to libreswan
LVM support for RAID level takeover and reshaping which allows for conversion between RAID types and RAID parameters
Backend Certificate improvements
Once the beta is over, users should run:
yum-config-manager --disable clearos-updates-testing
Share this post:
Responses (32)
-
Accepted Answer
Thanks Nick - have added the comment. The machine hasn't been rebooted since the upgrade and has been running rock solid at 100% for all 4 CPUs ever since; doing medical research...
details at http://www.sraellis.tk/frame.php?number=27&monitor=violetta_sysconfig -
Accepted Answer
Hi Tony,
I've found the issue with the r8168/r8169 combination. It looks like the kmod-r8168 driver blacklists the r8169 (/usr/lib/modprobe.d/blacklist-r8169.conf). I do not understand this as it is not necessary. It is avoidable by making the kmod-r8169 a dependency of the the kmod-r8168 as the kmod-r8169 is not compatible with the r8168 anyway. I have posted to the ElRepo mailing list to that effect and await their response. There method precludes both cards in the same machine which you and I have. The effect can be negated by using /etc/sysconfig/modules/r8169.modules, but why bother. I suggest deleting or commenting out the /usr/lib/modprobe.d/blacklist-r8169.conf.
Also, using /etc/sysconfig/modules/r8169.modules method will fail in the case that you install the kmod-r8168 driver only, I think, as the r8169 driver will probably load against the r8168 card.
FWIW, I think the kmod-r8101 should also be a dependency of the kmod-r8168 or at lease related as it provides the driver for the 8136 type cards, but I've never been asked for it. -
Accepted Answer
Thanks, again, Tony. I've now found the lines in /var/log/system:
That makes me think that the update to samba went OK (perhaps restarting smb/nmb), but it is the app-samba app which may have the issue.Oct 3 20:49:07 server installer: app-flexshare-core - installing
Oct 3 20:49:10 server installer: app-samba-common-core - installing
Oct 3 20:49:10 server installer: app-samba-core - installing
Oct 3 20:49:11 server engine: exception: error: /usr/clearos/apps/base/libraries/Shell.php (227): /usr/bin/net: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.4.4' not found (required by /lib64/libwbclient.so.0)
Oct 3 20:49:11 server engine: exception: debug backtrace: /usr/clearos/apps/samba_common/libraries/Samba.php (444): execute
Oct 3 20:49:11 server engine: exception: debug backtrace: /usr/clearos/apps/samba/libraries/OpenLDAP_Driver.php (1023): get_domain_sid
Oct 3 20:49:11 server engine: exception: debug backtrace: /usr/sbin/add-windows-group-info (66): update_group_mappings
It triggered further down the installation as well:Oct 3 20:51:16 server installer: app-clearcenter - installing
Oct 3 20:51:45 server events: openldap_online - event occurred
Oct 3 20:51:45 server events: openldap_online - triggered hook: mail
Oct 3 20:51:50 server events: openldap_online - triggered hook: samba
Oct 3 20:51:50 server engine: exception: error: /usr/clearos/apps/base/libraries/Shell.php (227): /usr/bin/net: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.4.4' not found (required by /lib64/libwbclient.so.0)
Oct 3 20:51:50 server engine: exception: debug backtrace: /usr/clearos/apps/samba_common/libraries/Samba.php (444): execute
Oct 3 20:51:50 server engine: exception: debug backtrace: /usr/clearos/apps/samba/libraries/OpenLDAP_Driver.php (1023): get_domain_sid
Oct 3 20:51:50 server engine: exception: debug backtrace: /usr/sbin/add-windows-group-info (66): update_group_mappings
Oct 3 20:51:55 server samba: LDAP is offline.
Oct 3 20:52:08 server events: openldap_online - event occurred
Oct 3 20:52:08 server events: openldap_online - triggered hook: mail
Oct 3 20:52:08 server events: openldap_online - triggered hook: samba
Oct 3 20:52:54 server events: openldap_online - event occurred
Oct 3 20:52:54 server events: openldap_online - triggered hook: mail
Oct 3 20:52:59 server events: openldap_online - triggered hook: samba
Oct 3 20:53:04 server samba: LDAP is offline.
Oct 3 20:53:10 server events: openldap_online - event occurred
Oct 3 20:53:10 server events: openldap_online - triggered hook: mail
Oct 3 20:53:10 server events: openldap_online - triggered hook: samba
Oct 3 20:53:31 server events: system_database - event occurred
Oct 3 20:53:31 server events: system_database - triggered hook: system_database
Oct 3 20:53:36 server events: system_database - event occurred
Oct 3 20:53:36 server events: system_database - triggered hook: system_database
Oct 3 20:54:00 -
Accepted Answer
Hmm - in the case of an update personally doubt that much testing is carried out in the situation where replaced libs are used by programs freshly restarted, and old libs are still used for programs that continue running as they were without a restart. A reboot might not be strictly required - but think the conservative approach to reboot is safer. If you do need to reboot back to an older kernel owing to kernel issues - at the least the other components of your system are then at a consistent level...
As for your shares failure - just looked in my logs and interestingly found right at the end of the upgrade (which were all samba as they were done last owing to dependency problems as noted earlier) /usr/sbin/smbd complaining while trying to access some samba libraries. Complaining they were not "SAMBA_4.4.4" - of course they weren't - they had just been updated to "4.6.2"! So my shares may have failed as well, but since the system was rebooted so soon after the upgrade finished - "shutdown -r now" issued seconds after the upgrade finished - will never know... This would seem to indicate smb did not restart as you surmised... -
Accepted Answer
Agreed, but the EL methodology should allow you not to reboot and keep your old kernel running. This is an odd issue with samba which was a major upgrade. I believe it should restart itself when upgrading, but either it did not or it needed to restart after another package upgraded. Restarting smb and nmb fixed the shares and also stopped Win10 falling back to WebDav when trying to map in its shares. I rebooted last night when all was quiet and the server came straight back up and all is working.
Unfortunately once it is working there is no way back to try to identify the root cause of the issue. -
Accepted Answer
Nick wrote...
I have not rebooted since upgrading
The upgrade installed a new kernel. Would seem that you were running some of the latest packages with an older kernel? - sshd, httpd and some applications reload themselves on update, others don't, so their in-memory version is then different to that on the disk. You end up with a mish-mash of levels running on your system after an upgrade and all still using the older kernel - if you don't reboot.
Extract from https://access.redhat.com/discussions/1238193
Furthermore, in many situations, security updates won't actually take affect until processes are restarted (e.g., when libraries are updated). That means you can update all you want, but until you reboot or go through a manual process of identifying and restarting the relevant processes, you're still vulnerable.
On the other side of the coin, some packages that provide services (like Apache httpd) actually restart their service as part of the rpm script...
-
Accepted Answer
-
Accepted Answer
https://github.com/owncloud/core/issues/8536 is older, and it looks like the packaging is wildly different on EL7 compared to Ubuntu so I am not sure where to look. More google fu. -
Accepted Answer
Yup! I did a search earlier of PROPFIND and came up with a couple of references:
https://stackoverflow.com/questions/12488121/getting-propfind-in-apache-access-logs
https://serverfault.com/questions/72683/how-to-block-propfind-or-any-other-method-on-apache
One is 2016, one earlier which makes me wonder if it is a 7.4 thing or Windoze. They 405 anyway, but on the LAN I get stacks of them when a machine starts. Really I don't want to see them at all. -
Accepted Answer
-
Accepted Answer
I'm seeing another issue since I upgraded my production server. Each time a PC connects to the network I am seeing stacks of entries in my virtual server access logs:
This is one LAN PC and one connecting in by OpenVPN and relates to samba shares they automatically log into but the error is going into /var/log/httpd/server.howitts.co.uk_access_log.172.17.3.38 - - [04/Oct/2017:08:57:49 +0100] "OPTIONS /family HTTP/1.1" 200 - "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:57:52 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:57:55 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:57:59 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:58:11 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:59:37 +0100] "OPTIONS /family HTTP/1.1" 200 - "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:59:39 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:59:43 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:59:46 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:08:59:49 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.3.38 - - [04/Oct/2017:09:00:02 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:01 +0100] "OPTIONS / HTTP/1.1" 200 - "-" "DavClnt"
172.17.2.118 - - [04/Oct/2017:09:21:01 +0100] "OPTIONS / HTTP/1.1" 200 - "-" "DavClnt"
172.17.2.118 - - [04/Oct/2017:09:21:01 +0100] "OPTIONS / HTTP/1.1" 200 - "-" "DavClnt"
172.17.2.118 - - [04/Oct/2017:09:21:04 +0100] "OPTIONS /private HTTP/1.1" 200 - "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:04 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:04 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:04 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:05 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:05 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:05 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:08 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:08 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:08 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:11 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:11 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:11 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:12 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:12 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:12 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:13 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:13 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:13 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:14 +0100] "PROPFIND /videos HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:14 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:14 +0100] "PROPFIND /private HTTP/1.1" 405 233 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
172.17.2.118 - - [04/Oct/2017:09:21:16 +0100] "PROPFIND /shared HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"
Is this a feature of the upgrade or total coincidence? -
Accepted Answer
Thanks for testing. I tried testing last night and made a mess of it as I was too tired. I ended up upgrading my production ClearOS Business box to Community 7.4 beta rather than my test box! After that it was damage limitation.
The production box has a native r8168 card used on its WAN and I also saw no driver for it in the new kernel when I did a "find /lib/modules/ -name r8168.ko". I could only see the old kernels with symlinks to the old r8168 module.
At this point I realised how tired I was and, for damage limitation, I just installed the 7_4 version of the kmod-r8168 driver, so everything would work in the (very rare) case of forced reboot. The other down side is that when I installed the updated r8168 driver, the old one was removed as were the symlinks into the old kernels. This means there is no way of booting the old kernel and ending up with a running r8168 NIC. Potentially this is not a disaster as, on a new installation, there aren't any old kernels anyway.
So, like you, I am finding this upgrade is probably going to be very bad for anyone running an r8168 card. I have asked the devs if they could consider putting the 7_4 ElRepo drivers in their updates repo so the 7.4 upgrade will automatically pull in the updated drivers if necessary.
If I can get the time/energy I may recommission my old box to test with both r8168 and r8169 cards simultaneously.
re your other issue with the r8169, I last used my old box to set up a 7.x disk prior to putting it in my current server. One thing I noticed was the reluctance of the kmod-r8169 to load on boot up. Like you I had to modprobe it. To get round it I stuck a file in /etc/sysconfig/modules:
This worked after every boot.echo "modprobe r8169" > /etc/sysconfig/modules/r8169.modules
chmod +x /etc/sysconfig/modules/r8169.modules -
Accepted Answer
Strange - was able to get the r8189 NIC up very easily
[root@violetta ~]# updatedb && locate r8169.ko
/usr/lib/modules/3.10.0-514.26.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko
/usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/r8169/r8169.ko
/usr/lib/modules/3.10.0-693.2.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
[root@violetta ~]# insmod /usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/r8169/r8169.ko
[root@violetta ~]# ifup enp4s0
[root@violetta ~]# ifconfig enp4s0
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.27 netmask 255.255.255.0 broadcast 192.168.3.255
inet6 fe80::214:6cff:fe2e:21fe prefixlen 64 scopeid 0x20<link>
ether 00:14:6c:2e:21:fe txqueuelen 1000 (Ethernet)
RX packets 9 bytes 806 (806.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11 bytes 774 (774.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 21 base 0xa000
lspci now shows
Kernel driver in use: r8169
Kernel modules: r8169
Will need to keep an eye on this... -
Accepted Answer
Nick - just wanted to show that was successful (though not without some hastle - but that is another story) installing 7.3 on the Atom 330 and everything was set-up correctly for the upgrade to 7.4 testing. Was waiting on the 7.4 version of the r8169 source so could compile 7.4 versions of both r8168 and r8169. That is now done and upgrade to 7.4 (see separate append of more bother
Well it didn't go too well - the r8168 didn't come up - only the r8169... missing driver for r8168...
[root@violetta ~]# uname -r && lspci -vk | grep -A 16 "Ethernet"
3.10.0-693.2.2.v7.x86_64
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
Subsystem: Device 8680:0100
Flags: bus master, fast devsel, latency 0, IRQ 11
-- snipped
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
Subsystem: Netgear GA311
--snipped
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Kernel driver in use: r8169
Kernel modules: r8169
The r8169 driver that loaded...
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/weak-updates/r8169/r8169.ko
vermagic: 3.10.0-327.3.1.el7.x86_64 SMP mod_unload modversions
r8168 driver will not load...
[root@violetta ~]# updatedb && locate r8168.ko
/usr/lib/modules/3.10.0-327.36.1.v7.x86_64/extra/r8168/r8168.ko
/usr/lib/modules/3.10.0-514.26.2.v7.x86_64/weak-updates/r8168/r8168.ko
[root@violetta ~]# insmod /usr/lib/modules/3.10.0-514.26.2.v7.x86_64/weak-updates/r8168/r8168.ko
insmod: ERROR: could not insert module /usr/lib/modules/3.10.0-514.26.2.v7.x86_64/weak-updates/r8168/r8168.ko: Invalid parameters
Installed the 7.4 versions of r8168 and r8169 that were compiled on one of my other 7.4 test machines in readiness... rebooted...
[root@violetta ~]# uname -r && lspci -vk | grep -A 16 "Ethernet"
3.10.0-693.2.2.v7.x86_64
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
Subsystem: Device 8680:0100
-- snipped
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Kernel driver in use: r8168
Kernel modules: r8168
--
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
Subsystem: Netgear GA311
-- snipped
Capabilities: [dc] Power Management version 2
Kernel modules: r8169
Note - the r8169 did not come up - to be continued... no "in use"
and the relevant driver info
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/extra/r8168/r8168.ko
vermagic: 3.10.0-693.2.2.v7.x86_64 SMP mod_unload modversions
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/extra/r8169/r8169.ko
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/extra/r8169/r8169.ko
-
Accepted Answer
Performed an upgrade from 7.3 to 7.4 on the machine that will be used for Realtek NIC testing...
Had something wierd with samba and dependency failures...
Ended up excluding everything to do with samba and ran the upgrade
# yum upgrade -x samba* -x app-samba* -x libwbc* -x libwinb* -x libsmb*
This was successful - so just for the hell of it issued "yum upgrade"
To my surprise ( Really shouldn't be ) - no problems and samba updated OK - to end result all good... -
Accepted Answer
-
Accepted Answer
Well the ancient Intel Atom 330 machine in question is back up running medical research...
A few details..
[root@violetta ~]# cat /etc/clearos-release
ClearOS release 7.3.0 (Final)
[root@violetta ~]# lspci -vk | grep -A 16 "Ethernet"
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
Subsystem: Device 8680:0100
-- snipped
Kernel driver in use: r8168
Kernel modules: r8168
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
Subsystem: Netgear GA311
--snipped
Kernel driver in use: r8169
Kernel modules: r8169
drivers...
[root@violetta ~]# modinfo r8168
filename: /lib/modules/3.10.0-514.26.2.v7.x86_64/weak-updates/r8168/r8168.ko
version: 8.043.01-NAPI
license: GPL
description: RealTek RTL-8168 Gigabit Ethernet driver
author: Realtek and the Linux r8168 crew <netdev@vger.kernel.org>
rhelversion: 7.2
srcversion: E0A4050EE4484BDDA83D730
alias: pci:v00001186d00004300sv00001186sd00004B10bc*sc*i*
alias: pci:v000010ECd00008161sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
depends:
vermagic: 3.10.0-327.36.1.v7.x86_64 SMP mod_unload modversions
-- snipped
[root@violetta ~]# modinfo r8169
filename: /lib/modules/3.10.0-514.26.2.v7.x86_64/weak-updates/r8169/r8169.ko
version: 6.020.00-NAPI
license: GPL
rhelversion: 7.2
srcversion: C85F8CB4C87D7E8F04DF0AF
alias: pci:v00001186d00004302sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv00001186sd00004C00bc*sc*i*
alias: pci:v00001186d00004302sv00001186sd00004302bc*sc*i*
alias: pci:v00001186d00004300sv00001186sd00004300bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
depends:
vermagic: 3.10.0-327.3.1.el7.x86_64 SMP mod_unload modversions
-- snipped
and for those wondering - the machine is named after the young courtesan in my favourite opera - La Traviata... -
Accepted Answer
-
Accepted Answer
Tony Ellis wrote:
If you can, that would be brilliant. I don't think you even need to swap the NIC's, but just install the drivers then see what survives the upgrade. I guess swapping the NIC's is the icing on the cake.
OK - have an Atom 330 system with ClearOS 6.x 64-bit installed - a Realtek 8168 onboard and dual Intel e1000 in the PCI slot. It is currently running medical research for IBM World Community Grid - "Microbiome Immunity Project" and "Smash Childhood Cancer". In anticipation have stopped it requesting new work and it should finish its current 'work in progress' by sometime tomorrow. Quite happy to remove the disk drive, install a spare, swap the dual e1000 NIC for a spare r8169 NIC and try to load ClearOS 7.3 - then upgrade to 7.4. Should work - just that haven't seen any reports of ClearOS 7.x running on such an old Atom system. Will then set it back to work on medical research. In the meantime, if you wish to compile new r8168/r8169 kmod drivers at your convenience and subject to source availability - would be happy to download whenever they are ready, and test...
Interested? -
Accepted Answer
OK - have an Atom 330 system with ClearOS 6.x 64-bit installed - a Realtek 8168 onboard and dual Intel e1000 in the PCI slot. It is currently running medical research for IBM World Community Grid - "Microbiome Immunity Project" and "Smash Childhood Cancer". In anticipation have stopped it requesting new work and it should finish its current 'work in progress' by sometime tomorrow. Quite happy to remove the disk drive, install a spare, swap the dual e1000 NIC for a spare r8169 NIC and try to load ClearOS 7.3 - then upgrade to 7.4. Should work - just that haven't seen any reports of ClearOS 7.x running on such an old Atom system. Will then set it back to work on medical research. In the meantime, if you wish to compile new r8168/r8169 kmod drivers at your convenience and subject to source availability - would be happy to download whenever they are ready, and test...
Interested? -
Accepted Answer
Hi Tony,
I'd love to do some more testing, but it looks like in some cases you can choose an earlier kernel and it will use the earlier module which is probably good news. I have my old server pieces in the attic which I could really do with setting up. I don't think it has a PSU any more and I don't know what else is missing but it has an on-board r8168 NIC and a plugged in r8169 NIC so would be a great test bed.
From the mailing list, although the kmod r8169 driver won't compile, when you do a kernel upgrade, it symlinks correctly to the new kernel. This could be a disaster waiting to happen for r8168 users depending on how that module responds to an upgrade and I am concerned that a 7.4 specific version has been released which makes me wonder about compatibility. The disaster is because the kmod r8169 driver comes with a set of compatible PCI ID's which exclude the r8168. If the r8169 survives a kernel upgrade and the r8168 does not, then ClearOS will see no compatible drivers for the r8168. Had the kmod r8169 died during the upgrade, ClearOS would have fallen back to the stock r8169 driver which would have allowed the r8168 card to keep working, albeit with the usual problems, but at lease some sort of network connectivity could be maintained.
I wish I had the time to set up my old server. -
Accepted Answer
Nick wrote
Could you now have two via-rhine.ko's?
In fact suspect it could possibly be more than two if you re-compiled and re-installed for each new kernel upgrade and more than two versions of the source... here's an example of two from a machine where the kmod r8169 driver ClearOS 6.x got updated... note the different dates and sizes... used this example as now consider my two test machines are no longer typical as far as the via-rhine driver and ClearOS 7.4 is concerned as a result of the numerous re-install of various via-rhine kmod version drivers that were done earlier today...
[root@violetta ~]# ls -lad `locate r8169.ko`
-rwxr--r-- 1 root root 126464 Jan 17 2017 /lib/modules/2.6.32-642.13.1.v6.x86_64/kernel/drivers/net/r8169.ko
-rwxr--r-- 1 root root 126304 Apr 13 07:32 /lib/modules/2.6.32-696.v6.x86_64/kernel/drivers/net/r8169.ko
[root@violetta ~]# modinfo /lib/modules/2.6.32-642.13.1.v6.x86_64/kernel/drivers/net/r8169.ko
filename: /lib/modules/2.6.32-642.13.1.v6.x86_64/kernel/drivers/net/r8169.ko
-- snipped
vermagic: 2.6.32-642.13.1.v6.x86_64 SMP mod_unload modversions
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug
ebug verbosity level (0=none, ..., 16=all) (int)
[root@violetta ~]# modinfo /lib/modules/2.6.32-696.v6.x86_64/kernel/drivers/net/r8169.ko
filename: /lib/modules/2.6.32-696.v6.x86_64/kernel/drivers/net/r8169.ko
--snipped
vermagic: 2.6.32-696.v6.x86_64 SMP mod_unload modversions
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debugebug verbosity level (0=none, ..., 16=all) (int)
One other obvious thing worth mentioning - once you have an upgraded kernel, you can no longer build some older kmod versions e.g. via-rhine. - even if you boot into an older kernel...
Edit: If you do produce a kmod-8169 driver - will happily test it on a genuine r8169 on 7.4...
"Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)" -
Accepted Answer
Hi Tony,
That looks good and I'll post to ElRepo.
Your output shows something interesting and I have a thought. Could you now have two via-rhine.ko's, one symlinked to the old kernels and one symlinked to the new?
I've hit more compatibility problems and the following kmod drivers which I have provided in the past fail to compile in 7.4:
ath10k
ne2k-pci
r8169
rtl8723be
Of those the r8169 is the most concerning as it is needed to remove compatibility with r8168 cards otherwise the r8169 module can still load in preference. I'll post these to ElRepo as well. -
Accepted Answer
Good News on several fronts - but note this report is restricted to the via-rhine kmod driver - other drivers may behave differently...
1) Your driver works - tested on both machines - a reasonable amount of traffic for a test...
enp0s10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.28 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::214:6cff:fe2e:1ae2 prefixlen 64 scopeid 0x20<link>
ether 00:14:6c:2e:1a:e2 txqueuelen 1000 (Ethernet)
RX packets 294166 bytes 128851143 (122.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 232342 bytes 95871751 (91.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Details..
[root@pamela ~]# cat /etc/clearos-release && uname -r && modinfo via-rhine
ClearOS release 7.4.0 (Beta 1)
3.10.0-693.2.2.v7.x86_64
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko
license: GPL
description: VIA Rhine PCI Fast Ethernet driver
author: Donald Becker <becker@scyld.com>
rhelversion: 7.4
srcversion: C46AB948914FC2B512FF4BB
alias: pci:v00001106d00003053sv*sd*bc*sc*i*
alias: pci:v00001106d00003106sv*sd*bc*sc*i*
alias: pci:v00001106d00003065sv*sd*bc*sc*i*
alias: pci:v00001106d00003043sv*sd*bc*sc*i*
depends: mii
vermagic: 3.10.0-693.2.2.v7.x86_64 SMP mod_unload modversions
parm: debug:VIA Rhine debug message flags (int)
parm: rx_copybreak:VIA Rhine copy breakpoint for copy-only-tiny-frames (int)
parm: avoid_D3:Avoid power state D3 (work-around for broken BIOSes) (bool)
2) Rebooted the machine to a previous kernel - this was a nice surprise, the previous via-rhine drivers hadn't been replaced - so there was no problem with the interface... no burnt bridges here...
[root@pamela ~]# cat /etc/clearos-release && uname -r && modinfo via-rhine
ClearOS release 7.4.0 (Beta 1)
3.10.0-514.26.2.v7.x86_64
filename: /lib/modules/3.10.0-514.26.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
license: GPL
description: VIA Rhine PCI Fast Ethernet driver
author: Donald Becker <becker@scyld.com>
rhelversion: 7.3
srcversion: A1543A8D6D8256F5326E388
alias: pci:v00001106d00003053sv*sd*bc*sc*i*
alias: pci:v00001106d00003106sv*sd*bc*sc*i*
alias: pci:v00001106d00003065sv*sd*bc*sc*i*
alias: pci:v00001106d00003043sv*sd*bc*sc*i*
depends: mii
vermagic: 3.10.0-514.16.1.v7.x86_64 SMP mod_unload modversions
parm: debug:VIA Rhine debug message flags (int)
parm: rx_copybreak:VIA Rhine copy breakpoint for copy-only-tiny-frames (int)
parm: avoid_D3:Avoid power state D3 (work-around for broken BIOSes) (bool)
But what, if like on one of my machines, the older drivers have been deleted...
While using the older kernel deleted the via-rhine kmod rpm and deleted all instances of the older via-rhine drivers and symlinks...
Then installed the 7_4 version using the older kernel and rebooted. The interface came up OK No errors shown by ifconfig... 
[root@pamela ~]# modinfo via_rhine.ko
modinfo: ERROR: Module via_rhine.ko not found.
[root@pamela ~]# lsmod | grep via
i2c_viapro 13312 0
i2c_core 40756 1 i2c_viapro
sata_via 18153 0
pata_via 13672 3
via_rhine 32583 0
libata 247095 4 pata_acpi,sata_via,pata_via,ata_generic
mii 13934 2 r8169,via_rhine
[root@pamela ~]# updatedb && locate via-rhine.ko
/usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko
[root@pamela ~]# modinfo /usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko
filename: /usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko
license: GPL
description: VIA Rhine PCI Fast Ethernet driver
author: Donald Becker <becker@scyld.com>
rhelversion: 7.4
srcversion: C46AB948914FC2B512FF4BB
alias: pci:v00001106d00003053sv*sd*bc*sc*i*
alias: pci:v00001106d00003106sv*sd*bc*sc*i*
alias: pci:v00001106d00003065sv*sd*bc*sc*i*
alias: pci:v00001106d00003043sv*sd*bc*sc*i*
depends: mii
vermagic: 3.10.0-693.2.2.v7.x86_64 SMP mod_unload modversions
parm: debug:VIA Rhine debug message flags (int)
parm: rx_copybreak:VIA Rhine copy breakpoint for copy-only-tiny-frames (int)
parm: avoid_D3:Avoid power state D3 (work-around for broken BIOSes) (bool)
[root@pamela ~]# uname -r && cat /etc/clearos-release
3.10.0-514.26.2.v7.x86_64
ClearOS release 7.4.0 (Beta 1)
[root@pamela ~]# rpm -qa | grep via-rhine
kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64
[root@pamela ~]#
Rebooted into the latest kernel - and again the interface came up OK as expected...
For the record both machines have this NIC
Ethernet controller: VIA Technologies, Inc. VT6102/VT6103 [Rhine-II] (rev 78)
I have followed the ElRepo mailing list in the past - in fact currently have the gmane copy on my private news server - and on checking can see your discussion with Phil is on my machine (Read only - no posting). Have been spending what time I have watching the General CentOS list scanning for problems people have experienced with 7.4. Seems another solid upgrade from the CentOS staff..
As for r8168 - don't have a machine with one free for testing currently - the two machines being used for testing at the moment do not have PCIe - only PCI - hence the via-rhine NICs as well as e1000 and r8169. -
Accepted Answer
Hi Tony,
I don't know if you follow the ElRepo mailing list, but, following my request, they have updated the via-rhine source to be 7.4 compatible and it is now in their testing repo. I have compiled it here and I'd appreciate it if you could test it. If it is OK they will then promote it to a live package.
Unfortunately it looks like there was a kernel change in 2016 which RHEL have implemented in 7.4 and it may affect quite a few drivers.
I've also updated the e100 driver and the r8168 driver. The r8168 driver is bad news as it is used by quite a lot of people on the forum and they may not notice they need to update
Note that any driver which ElRepo put 7_4 in the name is not backward compatible with earlier kernels. -
Accepted Answer
Not sure what caused the failure on the one machine that the via-rhine driver disappeared from... It was the exact same installed kmod via-rhine rpm that survived the upgrade on the other machine. Re-installing the very same kmod rpm was successful.
Just tried 3 different versions compiled with different kernels - and all worked with ClearOS 7.4 - so hopefully this is the case until the change to the CentOS 7.4 kernels where hopefully the compile problem is fixed, or the currently compiled elrepo version continues to function :-). Thanks Nick for discovering this...
[root@pamela ~]# modinfo via-rhine
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
license: GPL
description: VIA Rhine PCI Fast Ethernet driver
author: Donald Becker <becker@scyld.com>
rhelversion: 7.2
srcversion: 85C100C679435F6DEA5B111
alias: pci:v00001106d00003053sv*sd*bc*sc*i*
alias: pci:v00001106d00003106sv*sd*bc*sc*i*
alias: pci:v00001106d00003065sv*sd*bc*sc*i*
alias: pci:v00001106d00003043sv*sd*bc*sc*i*
depends: mii
vermagic: 3.10.0-327.10.1.v7.x86_64 SMP mod_unload modversions
parm: debug:VIA Rhine debug message flags (int)
parm: rx_copybreak:VIA Rhine copy breakpoint for copy-only-tiny-frames (int)
parm: avoid_D3:Avoid power state D3 (work-around for broken BIOSes) (bool)
[root@pamela ~]# modinfo via-rhine
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
... snipped
rhelversion: 7.3
... snipped
vermagic: 3.10.0-514.16.1.v7.x86_64 SMP mod_unload modversions
... snipped
[root@pamela ~]# modinfo via-rhine
filename: /lib/modules/3.10.0-693.2.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
... snipped
rhelversion: 7.3
... snipped
vermagic: 3.10.0-514.26.2.v7.x86_64 SMP mod_unload modversions
... snipped
-
Accepted Answer
I've upgraded my VM so have now compiled the e1000e and zd1211rw drivers for ClearOS 7.4. They can be found here. I've tried compiling the via-rhine driver but it fails so I'll need to post to the ElRepo lists to see if they can fix it. Presumably this failure is why it did not set up its symlinks when Tony upgraded.
Please follow the other thread on the possible kernel update as these drivers will become obsolete. It should not matter too much for the e1000e driver as the kernel version is fairly recent anyway and ClearOS will revert to that. It will be fatal for my zd1211rw driver which will not load when they do the kernel changeover. -
Accepted Answer
Dave Loper wrote:
Kapano app (Zarafa Replacement) (https://www.clearos.com/resources/documentation/clearos/content:en_us:7_kb_zarafa_to_kopano_upgrade)
Dave,
Do you what is going to happen with the Home essential subsciption.
This includes now a Zarafa package, but do need to pay extra for Kopano or will there be a package deal again.
-
Accepted Answer
In 7.x, RedHat seem to be changing the kernel ABI quite often when they do a kernel for a new dot release. This means that some drivers are failing on these newer kernels and need to be recompiled. For others it is worse in that the source package needs to be bumped. The ones I know about which have a package bump are:
kmod-ar5523-0.0-6
kmod-zd1211rw-1.0-5
kmod-tpe-2.0.3-4.20170731git
kmod-e1000e-3.3.5.10
kmod-drbd90-9.0.9-1
drbd90-utils-9.1.0-1
drbd90-utils-sysvinit-9.1.0-1
wl-kmod-6_30_223_271-4
These versions are only for the 7.4 kernels. Of these, I've only compiled the zd1211rw and e1000e drivers in the past. I'm travelling at the moment, but when I get home I'll upgrade my VM to 7.4 then compile and publish the drivers. If you find any others which fail on 7.4, if you let me know, I will be able to compile them against the 7.4 kernel. I have a feeling the e100 driver may be in the same boat but I can't see why I think that for the moment. -
Accepted Answer
-
Accepted Answer
Returned to the first system and fixed the disk space issues... and upgraded OK.
This also has a VIA NIC and is very similar to the other test machine...
[root@alex ~]# lspci -vk | grep -A 7 Rhine
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102/VT6103 [Rhine-II]
(rev 78)
Subsystem: ASRock Incorporation K7VT series Motherboards
Flags: bus master, medium devsel, latency 32, IRQ 23, NUMA node 0
I/O ports at d400 [size=256]
Memory at febffc00 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Kernel driver in use: via-rhine
Kernel modules: via_rhine
This time the kmod via-rhine kmod rpm survived intact and the machine came up with the new kernel and all the network interfaces - now to explore the updates and changes + new apps as they are made available...
So you might be lucky - you might not... not a ClearOS problem as these kmod rpms are not part of their repositories... -
Accepted Answer
Thanks for the beta - successfully updated one test machine..
However, think that these two warnings are in order as it may save somebody some grief...
1) Warning disk space...
First attempt was on a test machine with many extra rpms and low on available disk space - have a plan to fix..
Install 8 Packages (+22 Dependent packages)
Upgrade 613 Packages
Total size: 705 M
Is this ok [y/d/N]: N
Second attempt on another test machine - fewer additional packages and more disk space
Install 8 Packages (+14 Dependent packages)
Upgrade 387 Packages
Total download size: 446 M
Is this ok [y/d/N]: Y
All the packages downloaded and installed OK - except for some warnings like this
- a sample
//lib/modules/3.10.0-514.16.1.v7.x86_64//weak-updates/via-rhine/via-rhine.ko:
//No such file or directory
/usr/lib/dracut/modules.d/50drm/module-setup.sh: line 26:
//lib/modules/3.10.0-514.16.1.v7.x86_64//weak-updates/via-rhine/via-rhine.ko:
//No such file or directory
What
2) Warning kmod
This second machine is multi-wan with one external interface a via-rhine II NIC using a kmod driver compiled locally using the elrepo source... worked well..
Before upgrade...
[root@pamela ~]# lsmod | grep via
i2c_viapro 13312 0
i2c_core 40756 1 i2c_viapro
sata_via 18153 0
pata_via 13672 3
libata 247095 4 pata_acpi,sata_via,pata_via,ata_generic
via_rhine 32583 0
mii 13934 2 r8169,via_rhine
[root@pamela ~]# rpm -qa | grep via-rhine
kmod-via-rhine-1.5.1-2.v7.x86_64
Rebooted into the new kernel - and the via-rhine driver was nowhere to be found...
[root@pamela ~]# uname -r
3.10.0-693.2.2.v7.x86_64
[root@pamela ~]# lsmod | grep via
i2c_viapro 13312 0
i2c_core 40756 1 i2c_viapro
pata_via 13672 3
sata_via 18153 0
libata 247095 4 pata_acpi,sata_via,pata_via,ata_generic
A 'updatedb' and 'locate' just found broken symlinks to via-rhine.ko
A "rpm -V kmod-via-rhine" showed all files missing...
Fortunately had taken the precaution of having both the locally compiled via-rhine as well as the official elrepo compiled via-rhine binary rpms on the machine - just in case...
(and also why had verified the via-rhine driver was OK BEFORE install...). Since the kernel indicated 'v7' decided to reinstall the locally compiled kmod via-rhine rpm using yum - success! Driver loaded OK and able to bring up the missing external interface OK...
This is only a sample of one - so who knows if this is typical... but...
praemonitus praemunitus - or in English - forewarned is forearmed
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 »