Community Forum

Share this post:
Responses (32)
  • Accepted Answer

    Sunday, October 08 2017, 11:08 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, October 08 2017, 03:38 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 06 2017, 03:57 PM - #Permalink
    Resolved
    0 votes
    Thanks, again, Tony. I've now found the lines in /var/log/system:
    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
    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.

    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 06 2017, 02:15 PM - #Permalink
    Resolved
    0 votes
    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...
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 06 2017, 07:26 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 06 2017, 01:37 AM - #Permalink
    Resolved
    0 votes
    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...
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 05 2017, 06:19 PM - #Permalink
    Resolved
    0 votes
    Hmm. Possibly caused by losing all my shares which I could no longer map. Stopping and restarting nmb and smd has fixed that so I can now map my shares (simple filesharing mode). I'll try to reboot the server before the family get home as I have not rebooted since upgrading.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 05 2017, 04:11 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 05 2017, 03:58 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 05 2017, 03:47 PM - #Permalink
    Resolved
    0 votes

    172.17.3.38 - - [04/Oct/2017:08:57:52 +0100] "PROPFIND /family HTTP/1.1" 405 232 "-" "Microsoft-WebDAV-MiniRedir/10.0.14393"


    Microsoft-WebDAV-MiniRedir is an interesting user agent.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 05 2017, 01:06 PM - #Permalink
    Resolved
    0 votes
    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:
    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"
    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.

    Is this a feature of the upgrade or total coincidence?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 04 2017, 07:20 AM - #Permalink
    Resolved
    0 votes
    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:
    echo "modprobe r8169" > /etc/sysconfig/modules/r8169.modules
    chmod +x /etc/sysconfig/modules/r8169.modules
    This worked after every boot.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 04 2017, 05:36 AM - #Permalink
    Resolved
    0 votes
    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...
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 04 2017, 05:24 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 04 2017, 04:30 AM - #Permalink
    Resolved
    0 votes
    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...
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 03 2017, 04:49 PM - #Permalink
    Resolved
    0 votes
    Hi Tony,
    Did you try then doing the upgrade to 7.4 Beta and see what survived? I think all your output is on the 7.3 kernel?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 03 2017, 01:57 PM - #Permalink
    Resolved
    0 votes
    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...
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 02 2017, 01:46 PM - #Permalink
    Resolved
    0 votes
    OK - since it's necessary to open the machine up to swap in a new disk will swap the NIC at the same time... Looks like the current work will finish between 9 and 10 am...
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 02 2017, 12:49 PM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:

    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?
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 02 2017, 12:36 PM - #Permalink
    Resolved
    0 votes
    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?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 02 2017, 11:44 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 02 2017, 03:18 AM - #Permalink
    Resolved
    0 votes
    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:Debug 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: debug:Debug 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)"
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, October 01 2017, 03:53 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, October 01 2017, 02:44 AM - #Permalink
    Resolved
    0 votes
    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... :o

    [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.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, September 30 2017, 06:59 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 29 2017, 11:54 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 29 2017, 06:37 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, September 28 2017, 05:13 PM - #Permalink
    Resolved
    0 votes
    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. ;)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, September 28 2017, 12:04 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 27 2017, 01:31 PM - #Permalink
    Resolved
    0 votes
    Thanks for the feedback Tony!

    Aside: ELRepo/kmod is a big topic of discussion for the ClearOS migration to the vanilla upstream kernel. It's definitely a moving target right now.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 27 2017, 11:06 AM - #Permalink
    Resolved
    0 votes
    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 :D - 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...
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 27 2017, 07:13 AM - #Permalink
    Resolved
    0 votes
    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 :o

    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
    The reply is currently minimized Show
Your Reply