Forums

Resolved
1 votes
ClearOS 7.5 is now available to download from the updates-testing repo. If you would like to try it out, please run the following commands:
yum --enablerepo=clearos-updates-testing upgrade clearos-release app-base
yum --enablerepo=clearos-updates-testing upgrade
If you don't use kmod NIC drivers (see below), reboot your server.

If you use any kmod NIC drivers, the kmod-r8168 and kmod-r8169 drivers will have updated automatically. The rest are available from my web site. If you need to upgrade your driver, there will be an el7_5.elrepo version to install. Download the driver using "wget" and install with "yum localupdate". Then reboot your server. Virtually all the drivers I have supplied in the past will need updating. Any which don't look like they need updating may also need an update but I will have to request them from ElRepo if they don't work in 7.5.

Please post any 7.5 Beta issues to this thread. Any feedback would be welcome.

[edit]
kmod drivers which I have supplied in the past and still may need recompiling are:
kmod-aic7xxx
[/edit]
Friday, June 08 2018, 07:31 PM
Share this post:
Responses (22)
  • Accepted Answer

    Saturday, July 07 2018, 07:49 AM - #Permalink
    Resolved
    0 votes
    Yes Nick, was somewhat surprised when my daily "download only" yum command indicated a large number of rpms available for install including this which has broken my file sharing for Windows clients when installed; 7.4 wasn't a problem... Linux clients can still connect to the shares OK... off now to watch some motor sport, NASCAR and F1... and agreed ClearOS communication is definitely getting worse... perhaps they feel the Community users are not so important to them any more and can be more often ignored, though Ben (thanks Ben) still pops in here regularly...

    [root@karien ~]# grep samba /var/log/yum.log
    Jul 07 07:56:44 Updated: samba-common-4.7.1-6.2.v7.noarch
    Jul 07 07:56:48 Updated: samba-common-libs-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:49 Updated: samba-client-libs-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:49 Updated: samba-libs-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:49 Updated: samba-common-tools-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:49 Updated: samba-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:56 Updated: samba-dc-libs-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:56 Updated: samba-winbind-modules-4.7.1-6.2.v7.x86_64
    Jul 07 07:56:56 Updated: samba-winbind-4.7.1-6.2.v7.x86_64
    Jul 07 07:57:47 Updated: 1:app-samba-extension-core-2.5.0-1.v7.noarch
    Jul 07 07:57:50 Updated: samba-client-4.7.1-6.2.v7.x86_64
    Jul 07 07:57:51 Updated: samba-winbind-clients-4.7.1-6.2.v7.x86_64
    Jul 07 07:57:51 Updated: samba-dc-4.7.1-6.2.v7.x86_64
    Jul 07 07:58:03 Updated: samba-python-4.7.1-6.2.v7.x86_64
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 07 2018, 07:23 AM - #Permalink
    Resolved
    0 votes
    Good and bad. I'm glad it is working and thanks for your help with debugging MultiWAN the issue.

    Bad because it looks like 7.5 has gone final without an announcement. I missed the meeting on Thursday so I don't know if the decision was taken then to release 7.5, but I would have expected an announcement to the forums. I'll ping Dave but it is 1.30 am there.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 07 2018, 03:47 AM - #Permalink
    Resolved
    0 votes
    Just installed 78 new rpms that have been released since the initial Beta 7.5 install, one of which was a newer kernel... One or more these rpms have fixed my Multi-WAN problem with the Beta - can now run with one static external interface and the other dynamic...

    Sat Jul 7 13:24:46 2018 info: system - syswatch started
    Sat Jul 7 13:24:46 2018 info: config - IP referrer disabled in multi-WAN
    Sat Jul 7 13:24:46 2018 info: config - IP referrer tool is installed
    Sat Jul 7 13:24:46 2018 info: config - debug level - 0
    Sat Jul 7 13:24:46 2018 info: config - retries - 3
    Sat Jul 7 13:24:46 2018 info: config - heartbeat - 15
    Sat Jul 7 13:24:46 2018 info: config - interval - 20 seconds
    Sat Jul 7 13:24:46 2018 info: config - offline interval - 10 seconds
    Sat Jul 7 13:24:46 2018 info: config - referrer IP detection - disabled
    Sat Jul 7 13:24:46 2018 info: config - ping server auto-detect - enabled
    Sat Jul 7 13:24:46 2018 info: config - try pinging gateway - yes
    Sat Jul 7 13:24:46 2018 info: config - number of external networks - 2
    Sat Jul 7 13:24:46 2018 info: config - monitoring external network - enp0s9f1
    Sat Jul 7 13:24:46 2018 info: config - monitoring external network - enp0s9f0
    Sat Jul 7 13:24:46 2018 info: config - number of standby networks - 0
    Sat Jul 7 13:24:46 2018 info: info - loading network configuration
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f1 - config: ifcfg-enp0s9f1
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f1 - onboot: enabled
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f1 - type: static
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f1 - wifi: disabled
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f1 - gateway: 192.168.0.1
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f0 - config: ifcfg-enp0s9f0
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f0 - onboot: enabled
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f0 - type: dhcp
    Sat Jul 7 13:24:46 2018 info: info - network configuration for enp0s9f0 - wifi: disabled
    Sat Jul 7 13:24:46 2018 info: enp0s9f1 - network - IP address - 192.168.0.28
    Sat Jul 7 13:24:46 2018 info: enp0s9f1 - network - gateway - 192.168.0.1
    Sat Jul 7 13:24:46 2018 info: enp0s9f1 - network - type - private IP range
    Sat Jul 7 13:24:47 2018 info: enp0s9f0 - network - IP address - 192.168.4.28
    Sat Jul 7 13:24:47 2018 info: enp0s9f0 - network - gateway - 192.168.4.1
    Sat Jul 7 13:24:47 2018 info: enp0s9f0 - network - type - private IP range
    Sat Jul 7 13:24:47 2018 info: system - changing active WAN list - enp0s9f0 enp0s9f1 (was startup)
    Sat Jul 7 13:24:47 2018 info: system - current WANs in use - enp0s9f0 enp0s9f1
    Sat Jul 7 13:24:47 2018 info: system - restarting firewall
    Sat Jul 7 13:25:18 2018 info: system - dynamic DNS updated
    Sat Jul 7 13:30:20 2018 info: system - heartbeat...
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 24 2018, 09:09 AM - #Permalink
    Resolved
    0 votes
    Yes, sad to see 6.x go - gradually updating all my machines (except a very few that don't support 64-bit)
    In my case having the older drivers on the other machine (alex) meant that I could re-create the necessary directories and copy them from one machine to the other.. Thus was able to add the older drivers back to 'pamela'. Booting into the older 7.4 kernel and using the following commands brought the via-rhine NIC up...

    [root@pamela ~]# insmod /usr/lib/modules/3.10.0-693.17.1.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
    [root@pamela ~]# ifup enp0s18

    So can now boot between kernels on pamela without having to re-install drivers each time... So if booting to an older kernel is important to some-one, then saving the older driver .ko files and restoring them after the upgrade would save time and allow easier transition between kernel booting...
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 24 2018, 08:08 AM - #Permalink
    Resolved
    0 votes
    Hi Tony,
    We were aware of the risk at the time 7.4 was released that there may be no way to boot to an older kernel. The kmod-r8168 package is slightly modified from ElRepo's version so it does not blacklist the r8169 driver. The intention of this was that if you booted to the older kernel, at least the stock r8169 driver would load against the r8168 NIC.
    When ElRepo produced specific 7.4 upgrades they changed the spec file which is why the files all appear as el7_4.elrepo.rpm. Previously it would pick up the %dist parameter from /home/build/.rpmmacros. That way mine were always .clearos7.njh.rpm. I wonder if this change is why specific 7_4.elrepo ones have survived and others have not. There may be other changes to the spec file as well, but I have not investigated.

    It is a real pity because in EL6, Redhat hardly ever changed the kernel ABI and I perhaps remember recompiling only once or trice over the whole 6.x cycle. Now with EL7 they appear to be changing with each point release which introduces these issues. I think some of the change was the introduction of a retpoline enabled compiler for the Spectre/Meltdown issue.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 24 2018, 07:44 AM - #Permalink
    Resolved
    0 votes
    Just upgraded another server to 7.5
    Interesting difference between the kmod r8169 and kmod via-rhine... kmod r8169 from the ClearOS upgrade, kmod via-rhine from Nick's site...

    After the upgrade booting into the new kernel - we see this

    [root@pamela ~]# 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.11.6.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
    /usr/lib/modules/3.10.0-693.17.1.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
    /usr/lib/modules/3.10.0-693.2.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
    /usr/lib/modules/3.10.0-862.3.2.v7.x86_64/extra/r8169/r8169.ko
    /usr/lib/modules/3.10.0-862.3.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
    [root@pamela ~]# locate via-rhine.ko
    /usr/lib/modules/3.10.0-862.2.3.el7.x86_64/extra/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-862.3.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

    The old via-rhine kmod drivers are gone meaning that we cannot reboot to an older kernel and have all the NICs working upon reboot...
    Confirmed this with a reboot to an older kernel...) The bridge got burnt this time :(
    Looking in the yum log we can see the previous versions...

    /var/log/yum.log-20180222:Mar 13 12:14:37 Installed: kmod-via-rhine-1.5.1-1.v7.x86_64
    /var/log/yum.log-20180222:Sep 27 16:09:06 Installed: kmod-via-rhine-1.5.1-2.v7.x86_64
    /var/log/yum.log-20180222:Oct 01 12:45:46 Installed: kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64
    /var/log/yum.log:Jun 24 15:32:09 Updated: kmod-via-rhine-1.5.1-3.el7_5.elrepo.x86_64

    This is different to the last upgrade where the older kmod via-rhine driver was retained...

    [root@alex ~]# locate via-rhine.ko
    /usr/lib/modules/3.10.0-693.17.1.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-862.2.3.el7.x86_64/extra/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-862.3.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

    No idea why the difference - but does serve as a warning to make sure you have the older driver available if you have a need to boot into an older kernel...
    The only way to restore NIC use under the 7.4 kernel

    [root@pamela ~]# yum downgrade kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64.rpm
    Loaded plugins: clearcenter-marketplace, fastestmirror
    ClearCenter Marketplace: fetching repositories...
    Examining kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64.rpm: kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64
    Resolving Dependencies
    --> Running transaction check
    ---> Package kmod-via-rhine.x86_64 0:1.5.1-3.el7_4.elrepo will be a downgrade
    ---> Package kmod-via-rhine.x86_64 0:1.5.1-3.el7_5.elrepo will be erased
    ...

    This allows us to install the via-rhine driver and bring up the NIC under the older kernel. We now have this...

    [root@pamela ~]# locate via-rhine.ko
    /usr/lib/modules/3.10.0-693.11.6.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-693.17.1.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko

    Of course, rebooting to the 7.5 kernel means we have to install the 7_5 driver yet again :( and back to the 7.5 driver only...

    [root@pamela ~]# locate via-rhine.ko
    /usr/lib/modules/3.10.0-862.2.3.el7.x86_64/extra/via-rhine/via-rhine.ko
    /usr/lib/modules/3.10.0-862.3.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 23 2018, 07:20 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    Yumdownloader downloads the rpm into your working directory so you can inspect it. Being a luddite, I drag it to my Windows desktop and open it with 7z, doubleclick on the cpio file and then again on the "." file and from there you'll see the layout and files in the rpm.

    Also from your working directory in ClearOS you can look at the install scripts with:
    rpm -qp app-base-core-2.4.24-1.v7.noarch.rpm --scripts
    Note I've found you also need to look in app-base-core and you can follow the upgrade script. The script does a load of manipulation of various files and the rpm contains updated yum-repos-d definitions.

    I've suddenly remembered there is another dependency, clearos-release, which comes down when you update app-base, and this is the rpm which sets the ClearOS release number.


    Ah I see. Interesting going to play bit!
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Saturday, June 23 2018, 02:51 PM - #Permalink
    Resolved
    0 votes
    What is the clearos-release app-base?


    Y'all figured it out! It's all about updating the various /etc/yum.repos.d/ yum configlets to point to the 7.5 versions, or tweaking the yum exclude lists.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 23 2018, 12:15 PM - #Permalink
    Resolved
    0 votes
    Yumdownloader downloads the rpm into your working directory so you can inspect it. Being a luddite, I drag it to my Windows desktop and open it with 7z, doubleclick on the cpio file and then again on the "." file and from there you'll see the layout and files in the rpm.

    Also from your working directory in ClearOS you can look at the install scripts with:
    rpm -qp app-base-core-2.4.24-1.v7.noarch.rpm --scripts
    Note I've found you also need to look in app-base-core and you can follow the upgrade script. The script does a load of manipulation of various files and the rpm contains updated yum-repos-d definitions.

    I've suddenly remembered there is another dependency, clearos-release, which comes down when you update app-base, and this is the rpm which sets the ClearOS release number.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 23 2018, 10:32 AM - #Permalink
    Resolved
    0 votes
    I did a yumdownloader app-base but it just checks the repos and then nothing.. I'm not sure what you trying to say/explain in the first rule of your post. Everything else is clear. Thanks for that info.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 23 2018, 09:53 AM - #Permalink
    Resolved
    0 votes
    Do a "yumdownloader app-base" then try to work it out!

    I've tried and failed. It contains the shutdown widgit and the first run wizard.

    I thought it also controlled the release number so would bump the release to 7.5 and allow yum to use the 7.5 channel of clearos-centos, but I don't see where it does it. That is why it has to be run first otherwise ClearOS points to the wrong clearos-centos channel and the update fails with dependency errors.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 23 2018, 07:55 AM - #Permalink
    Resolved
    0 votes
    Installed ClearOS 7.5 Beta in a VM with success.

    Nick Howitt wrote:

    ClearOS 7.5 is now available to download from the updates-testing repo. If you would like to try it out, please run the following commands:
    [code]yum --enablerepo=clearos-updates-testing upgrade clearos-release app-base
    yum --enablerepo=clearos-updates-testing upgrade[/code
    [/edit]


    What is the clearos-release app-base? Do we see this in the webgui or is it a underlying code?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 21 2018, 02:36 PM - #Permalink
    Resolved
    0 votes
    Another kernel panic on boot in my VM which I was unable to capture. :(
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Tuesday, June 12 2018, 05:50 PM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:

    ... snip ...

    Jun 10 16:56:51 alex firewall: Error: /usr/clearos/apps/firewall/deploy/libmultipath.lua:56: bad argument #3 to 'format' (string expected, got nil)


    Many thanks Tony. We're on it.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 12 2018, 02:34 PM - #Permalink
    Resolved
    0 votes
    I'm getting two firewall start failures, one for docker and one for wpad. The log from "firewall-start -d":
    firewall: Execution time: 0.369s
    firewall: Running post-firewall: 110740
    firewall: Running /etc/clearos/firewall.d/custom
    firewall: Running /etc/clearos/firewall.d/local
    firewall: Running /etc/clearos/firewall.d/10-docker
    Device "docker0" does not exist.
    iptables v1.4.21: host/network `!' not found
    Try `iptables -h' or 'iptables --help' for more information.
    firewall: Running /etc/clearos/firewall.d/10-snortsam
    firewall: Running /etc/clearos/firewall.d/10-wpad
    iptables v1.4.21: host/network `. . ' not found
    Try `iptables -h' or 'iptables --help' for more information.
    iptables v1.4.21: host/network `. . ' not found
    Try `iptables -h' or 'iptables --help' for more information.
    firewall: Running /etc/clearos/firewall.d/90-attack-detector


    Docker was not running. If I start docker the docker error goes.

    There is not an option to start wpad. Looking at /etc/clearos/firewall.d/10-wpad, it looks like $exempt_ip is returning a blank and even if it returned something, the parameter after -s would be meaningless, because " . $exempt_ip . " needs to evaluate to an IP, subnet or resolvable FQDN.

    Also this morning I had a kernel panic and halt during the booting of a VM. I tried and failed to get a screenshot and the logs failed to show anything.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 12 2018, 12:36 AM - #Permalink
    Resolved
    0 votes
    Peter - email sent - most interesting was this... repeated over and over again...

    Jun 10 16:56:51 alex firewall: Synchronizing multipath routing tables...
    Jun 10 16:56:51 alex firewall: Loading environment
    Jun 10 16:56:51 alex firewall: Detected WAN role for interface: enp0s9f0
    Jun 10 16:56:51 alex firewall: Detected WAN role for interface: enp0s9f1
    Jun 10 16:56:51 alex firewall: Detected WAN backup role for interface: enp0s9f0
    Jun 10 16:56:51 alex firewall: Detected WAN backup role for interface: enp0s9f1
    Jun 10 16:56:51 alex firewall: Detected LAN role for interface: enp0s10
    Jun 10 16:56:51 alex firewall: Error: /usr/clearos/apps/firewall/deploy/libmultipath.lua:56: bad argument #3 to 'format' (string expected, got nil)
    The reply is currently minimized Show
  • Accepted Answer

    PeterB
    PeterB
    Offline
    Monday, June 11 2018, 01:42 PM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:

    ...
    After re-booting after the upgrade the firewall immediately went into panic mode and refused any attempts to rectify...


    Do you happen to have the screen or log output from the firewall panic? If so, please forward it to developer@clearfoundation.com.

    Thanks.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 10 2018, 09:42 PM - #Permalink
    Resolved
    0 votes
    So far a upgrade on a simple inside/outside routed system - everything seems ok. Glad to be on the 3.10.0-862.x.x (3.10.0-862.3.2.v7) kernel series.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 10 2018, 09:42 AM - #Permalink
    Resolved
    0 votes
    Thanks Nick - you will see my box is running at 100% CPU :D

    Asked about testing as was wondering if this MultiWan issue was a known problem, and hence would not waste any more time on it...

    ClearOS used to provide details with a Beta release - and list known problems... However, a check of https://www.clearos.com/clearfoundation/development/clearos/announcements:releases:start shows the information there is woefully out-of-date - nobody at ClearOS can be bothered with updating it? :(
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 10 2018, 08:52 AM - #Permalink
    Resolved
    0 votes
    Hi Tony, That is not so good! I released the announcement on behalf of the devs and I don't know what testing they've done. On my side I've upgraded two play VM's and a test box, but I don't have your facilities. I only have a single external connection and can't easily stress my test box. The VM's are irrelevant as I have them with NAT's NIC's to my desktop on 127.0.0.1 and funny ports. I've had one boot failure on a VM and had to reset it.

    I'll mention your issue to the devs, but I hope they are following the thread anyway.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 10 2018, 08:17 AM - #Permalink
    Resolved
    0 votes
    Nick a result for you - just updated a test server to ClearOS 7.5

    Install 2 Packages (+27 Dependent packages)
    Upgrade 419 Packages
    Remove 2 Packages
    Total download size: 673 M

    One major problem - multiwan
    This machine through 6.x and 7.x (up-to 7.4) has run successfully with two external interfaces
    1) cable modem - static 2) ADSLl2+ modem dynamic
    After re-booting after the upgrade the firewall immediately went into panic mode and refused any attempts to rectify...
    As a test removed using webconfig the interface to the ADSL modem - no firewall panic
    Re-added the ADSL interface using a static address - no firewall panic
    Changed ADSL interface back to dynamic - immediate panic...
    Nothing to do with kmod drivers as both these external interfaces are Intel e1000...
    Have resorted to static at the moment so the machine can do a 'soak' test..

    Not good - was this configuration tested? - and don't have any more time to chase this at the moment... :(

    On the kmod front - this machine used the kmod-r8169 and kmod-via-rhine drivers on 7.4
    The kmod-r8169 updated OK with the upgrade and used the kmod-via-rhine 7.5 driver from your site Nick - saved me time to compile - thanks
    Both interfaces came up OK after the re-boot with the new kmod drivers...
    Also a nice surprise - re-booted back to the previous 7.4 kernel - and both older kmod drivers were still on the system and the interfaces all cam up OK - so no "burnt bridges" :D

    Note that this system, like all mine, is not 'typical' ClearOS installations
    1. No flexshares or ftp
    2. No dnsmasq - use bind and the dhcpd from ISC
    3. Samba is not configured the "ClearOS way'
    4. No paid apps
    5. Several hundred rpms over and above the base ClearOS install
    6. Monitoring tools are mostly 'home-grown'
    7. Extensive changes made to numerous configuration files
    8. Use home-grown attack-detector - the ClearOS one is too resource heavy for my systems

    Will re-append with any additional information as a result of prolonged testing over the next day or two...

    Edit: This machine can be seen at this url - http://www.sraellis.tk/frame.php?number=28&monitor=alex_sysconfig
    The reply is currently minimized Show
  • Accepted Answer

    Mansoor
    Mansoor
    Offline
    Sunday, June 10 2018, 02:42 AM - #Permalink
    Resolved
    0 votes
    Great news Nick.

    [EDIT: the yum issue has been solved and I'm upgrading now.]

    EDIT 2: this beta version has been working as a gateway for my home's network for 24 hours. I have no issues and everything seems to be working well so far.
    The reply is currently minimized Show
Your Reply