Forums

Share this post:
Responses (32)
  • Accepted Answer

    Wednesday, July 01 2020, 11:50 AM - #Permalink
    Resolved
    0 votes
    It is probably a start up dependency. I wonder if it should start after the network-onlne target instead of the network target. Anyway the firewall starts multiple times during boot up so it should not be an issue.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 01 2020, 11:25 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    With a systemcl restart its running just fine! Seems only to happen on a boot!
    Anyone else who has this?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 01 2020, 10:02 AM - #Permalink
    Resolved
    0 votes
    Can you do a "systemctl restart firewall" and if it fails, try a "firewall-start -d" and see where the failure happens. It may just be because the update forces a firewall failure but it restarts correctly. Alternatively it is possibly something around netify (application and protocol filters).
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 01 2020, 08:35 AM - #Permalink
    Resolved
    0 votes
    I saw this in messages:

    Jul 1 10:08:47 fw01 kernel: ip_set: protocol 7
    Jul 1 10:08:47 fw01 php: Netify Firewall Agent v2.93 starting...
    Jul 1 10:08:47 fw01 netify-fwa[1511]:
    Jul 1 10:08:47 fw01 systemd: firewall.service: main process exited, code=killed, status=15/TERM
    Jul 1 10:08:47 fw01 systemd: Unit firewall.service entered failed state.
    Jul 1 10:08:47 fw01 systemd: firewall.service failed.

    Firewall is running when i look..... what is causing this?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 01 2020, 08:26 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    Working on 2 systems after reboot!

    Updating : 2:microcode_ctl-2.1-61.10.el7_8.x86_64
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 27 2020, 08:07 AM - #Permalink
    Resolved
    0 votes
    There is an update to microcode_ctl available in the centos-updates-unverified repo which is designed to replace the faulty one released with ClearOS 7.8 (although it is not specifically a 7.8 package). If you would like to test it you can do a:
    yum update microcode_ctl --enablerepo=centos-updates-unverified

    I am planning to release it on Tuesday if I see no general noise on the internet or negative feedback from you or anyone else.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 23 2020, 07:33 AM - #Permalink
    Resolved
    0 votes
    @John, that is a Community system, but it was only registered on the 18th so is in the 30 day period where it stays on the Paid repos. It won't update until either the 30 days pass or the Paid versions have 7.8 pushed, whichever is sooner.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 23 2020, 12:18 AM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    Sorry. /etc/suvad.conf.

    It is 935856
    The reply is currently minimized Show
  • Accepted Answer

    Monday, June 22 2020, 08:12 PM - #Permalink
    Resolved
    0 votes
    Sorry. /etc/suvad.conf.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, June 22 2020, 07:43 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    From that system what is its "device" from /etc/suvad?


    Well.... there is no file or directory named suvad in the /etc directory.

    There is a directory under /run/suvad with a suvad.pid file which has 5287 in it. Lastly there is what appears to be an executable file in /usr/sbin/suvad. If I enter /usr/sbin/suvad nothing returns.

    Other systems show the same directory and files.

    John
    The reply is currently minimized Show
  • Accepted Answer

    Monday, June 22 2020, 07:05 AM - #Permalink
    Resolved
    0 votes
    Your other First and Second systems need a reboot to have the latest kernel running. Is you brother's system a recent installation? If so, it will use the paid repos for the first 30 days so will not upgrade until it either the 30 days pass, when it will revert to using the community repos, or when 7.8 is released to paid, whichever is sooner.

    From that system what is its "device" from /etc/suvad?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 21 2020, 09:24 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    @John, you have a paid version, either Home or Business. That has not updated yet. We normally let Community update first in case there are any bugs we've not spotted. Paid versions follow .after a week or more. I was going to leave this update a couple of weeks because of the microcode_ctl issue, but we may have contained it by removing the package,


    Hi Nick!

    I am not sure how I have an ever lasting version of not paid for Home or Business when I installed the Community version ISO! I just downloaded the latest Community ISO for my brother, registered it and it says and does the exact same thing as my system! I guess I won't gripe, but not certain if I was Grandfathered from the old ClarkConnect days waayyyy back when or what, but this is news to me!!! No where does it say Home or Business, Just Free Now and Forever!

    I have double and triple checked both my systems and the latest install for my brother and they are identical as far as 'yum repolist' results. My brother's, the latest install, has yet to update while my two systems have and are now at 7.8.1(Final).

    My brother's Kernal is 3.10.0-1062.18.1.el7.x86_64 and is 7.7.2(Final) up for 3 days
    My First System Kernal is 3.10.0-1062.1.2.el7.x86_64 and is 7.8.1(Final) up for 244 days
    My Second System Kernal is 3.10.0-1062.18.1.el7.x86_64 and is 7.8.1(Final) up for 56 days

    I did reboot my first system to get the latest Kernal in operation.

    AND, my brother's ClearOS box is on my network double NATed right now for burn in. Would that keep it from getting the updates?

    In the meantime I will wait patiently for the update to come to my brother's system! Maybe I shouldn't have said anything?!!??

    John
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 21 2020, 08:20 AM - #Permalink
    Resolved
    0 votes
    @John, you have a paid version, either Home or Business. That has not updated yet. We normally let Community update first in case there are any bugs we've not spotted. Paid versions follow .after a week or more. I was going to leave this update a couple of weeks because of the microcode_ctl issue, but we may have contained it by removing the package,
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 21 2020, 06:50 AM - #Permalink
    Resolved
    0 votes
    grubs wrote:

    How does one check the version installed using the web interface?

    I found in recent posts that I can "cat /etc/clearos-release" at the command line.. ClearOS release 7.8.1 (Final) btw
    .but it seems an omission that this version number is not represented in the webconfig (that I can find) - I checked the obvious locations "Edition manager", "Software updates" and "Dashboard".

    7.8 working fine so far - (older J1900 platform apparently unaffected by microcode changes)


    You can do that by installing "system report" from the marketplace. Check my screenshot!

    Nice to hear that it is working well for you. [thumbsup]
    The reply is currently minimized Show
  • Accepted Answer

    grubs
    grubs
    Offline
    Sunday, June 21 2020, 05:22 AM - #Permalink
    Resolved
    0 votes
    How does one check the version installed using the web interface?

    I found in recent posts that I can "cat /etc/clearos-release" at the command line.. ClearOS release 7.8.1 (Final) btw
    .but it seems an omission that this version number is not represented in the webconfig (that I can find) - I checked the obvious locations "Edition manager", "Software updates" and "Dashboard".

    7.8 working fine so far - (older J1900 platform apparently unaffected by microcode changes)
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 20 2020, 09:54 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    So what do you get from:
    cat /etc/clearos-release
    yum repolist
    yum update


    Thanks again... the following is what I get...

    Last login: Sat Jun 20 12:39:00 2020 from 192.168.0.236
    [root@gateway ~]# cat /etc/clearos-release
    ClearOS release 7.7.2 (Final)
    [root@gateway ~]# yum repolist
    Loaded plugins: clearcenter-marketplace, fastestmirror
    ClearCenter Marketplace: fetching repositories...
    Loading mirror speeds from cached hostfile
    * clearos: mirror1-newyork.clearos.com
    * clearos-centos: download1.clearsdn.com
    * clearos-centos-sclo-rh: download1.clearsdn.com
    * clearos-centos-updates: download1.clearsdn.com
    * clearos-centos-verified: mirror1-newyork.clearos.com
    * clearos-contribs: mirror1-newyork.clearos.com
    * clearos-epel-verified: mirror1-newyork.clearos.com
    * clearos-fast-updates: download1.clearsdn.com
    * clearos-infra: mirror1-newyork.clearos.com
    * clearos-paid: mirror1-newyork.clearos.com
    * clearos-verified: mirror1-newyork.clearos.com
    * private-clearcenter-verified-updates: download2.clearsdn.com:80
    repo id repo name status
    clearos/7 ClearOS 7 - x86_64 - OS 663
    clearos-centos/x86_64 CentOS-7 - x86_64 - Base 10,042+55
    clearos-centos-sclo-rh/x86_64 CentOS-7 - x86_64 - CentOS Softwa 6,509
    clearos-centos-updates/x86_64 CentOS-7 - x86_64 - Updates 1,459+2
    clearos-centos-verified ClearOS 7 - x86_64 - CentOS Verif 13,340
    clearos-contribs/7 ClearOS 7 - x86_64 - Contribs 127
    clearos-epel-verified ClearOS 7 - x86_64 - EPEL Verifie 23,573
    clearos-fast-updates/x86_64 ClearOS 7 - x86_64 - Fast Updates 3
    clearos-infra/7 ClearOS 7 - x86_64 - Infrastructu 16
    clearos-paid ClearOS 7 - x86_64 - Paid 317
    clearos-verified ClearOS 7 - x86_64 - Verified Upd 405
    private-clearcenter-verified-updates ClearOS 7 Verified Updates 15
    repolist: 56,469
    [root@gateway ~]# yum update
    Loaded plugins: clearcenter-marketplace, fastestmirror
    ClearCenter Marketplace: fetching repositories...
    Loading mirror speeds from cached hostfile
    * clearos: mirror1-newyork.clearos.com
    * clearos-centos: download2.clearsdn.com
    * clearos-centos-sclo-rh: download2.clearsdn.com
    * clearos-centos-updates: download2.clearsdn.com
    * clearos-centos-verified: mirror1-newyork.clearos.com
    * clearos-contribs: mirror1-newyork.clearos.com
    * clearos-epel-verified: mirror1-newyork.clearos.com
    * clearos-fast-updates: download2.clearsdn.com
    * clearos-infra: mirror1-newyork.clearos.com
    * clearos-paid: mirror1-newyork.clearos.com
    * clearos-verified: mirror1-newyork.clearos.com
    * private-clearcenter-verified-updates: download1.clearsdn.com:80
    No packages marked for update
    [root@gateway ~]#
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 20 2020, 08:07 PM - #Permalink
    Resolved
    0 votes
    So what do you get from:
    cat /etc/clearos-release
    yum repolist
    yum update
    The reply is currently minimized Show
  • Accepted Answer

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

    @John, Community or Paid? If has not been released to paid yet. If it is Community, please start by checking this post, although your updates were far more recent.

    Do you seen any problems if you do "yum update"? It probably won't do a full update.


    Thanks Nick for the reply!

    Running community and I have no processes running when doing the yum check and when I do a yum update there are no packages marked for update. My system still shows 7.7.2.

    I am confused about why my updates "were far more recent" as May 27th is almost a month ago and this update was to come out June 16th?

    Thanks again so much!!

    John
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 20 2020, 08:05 AM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:

    There is a suggestion that some of the CPU microcode update problems stem from the update requiring a newer BIOS - and the need to match your BIOS level with what formware you need to run...
    So, generally speaking, if your board manufacturer doesn't supply a newer BIOS ???
    That'll leave a lot of us stuffed ........ I understood something slightly differently. I thought the update may work if put into a BIOS, in which case you don't need it in the kernel. Anyway, we've withdrawn the faulty package and my understanding is that when a new one is released, it will effectively be a downgrade.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 20 2020, 07:29 AM - #Permalink
    Resolved
    0 votes
    @John, Community or Paid? If has not been released to paid yet. If it is Community, please start by checking this post, although your updates were far more recent.

    Do you seen any problems if you do "yum update"? It probably won't do a full update.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 20 2020, 03:30 AM - #Permalink
    Resolved
    0 votes
    Somehow I missing the boat! Here is notice that ClearOS 7.8 should update on the 16th of June. Here it is June 19, 2020 and I am not certain if that means automatic or even manual updates, will update my ClearOS release 7.7.2 (Final).

    Is this a yum update or is it automatic? My last automatic software updates were the end of May; May 27th to be exact.

    Any hints so I can get back "onboard" would be great!

    Thanks so much!

    John
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 20 2020, 12:36 AM - #Permalink
    Resolved
    0 votes
    There is a suggestion that some of the CPU microcode update problems stem from the update requiring a newer BIOS - and the need to match your BIOS level with what formware you need to run...
    So, generally speaking, if your board manufacturer doesn't supply a newer BIOS ???
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 18 2020, 07:25 AM - #Permalink
    Resolved
    0 votes
    Just upgraded a production machine on a HP system with Intel(R) Core(TM) i5-4570 CPU.
    Booted just fine !
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 18 2020, 07:02 AM - #Permalink
    Resolved
    0 votes
    Hi,
    Yesterday i upgraded to 7.8 succesfully on a test machine in a VMWare envoirement. (end of the day europe time).
    In the morning i upgraded and it hung somehow on dracut, had no time to investigate.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 09:39 PM - #Permalink
    Resolved
    0 votes
    Just before 18:00 UTC+1 this evening, we pulled the latest microcode_ctl package, microcode_ctl-2.1-61.6.el7_8, from the repos. Anyone with a system that will only boot to an older kernel can downgrade to the earlier version with a:
    yum downgrade microcode_ctl
    You should end up with microcode_ctl-2.1-61.el7.x86_64. This is believed to be OK.

    Please note that the issue only seems affect some Intel processors and no AMD ones. I believe that an update for the package has been released by Intel to revert to previous microcode for the affected processors. This update needs to work its way through the Redhat release system (and Centos) before we can get our hands on it.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 01:50 PM - #Permalink
    Resolved
    0 votes
    OK - remember these two machines have already upgraded to the latest kernel and microcode_ctl without problems - did the downgrade and both rebooted OK


    [root@madeleine ~]# uname -r && rpm -q microcode_ctl
    3.10.0-1127.10.1.el7.x86_64
    microcode_ctl-2.1-61.el7.x86_64

    [root@violetta ~]# uname -r && rpm -q microcode_ctl
    3.10.0-1127.10.1.el7.x86_64
    microcode_ctl-2.1-61.el7.x86_64


    Note these are very old CPUs and probably have very few, if any, patches for the newly discovered CPU threats
    madeleine Intel E8400 genuine CentOS 7.8
    violetta Intel Atom D510 ClearOS 7.8
    There are a few other more modern Intel machines here, but they are all Windows or Fedora.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 01:11 PM - #Permalink
    Resolved
    0 votes

    Downgrade 1 Package

    Total download size: 2.5 M
    Is this ok [y/d/N]: y
    Downloading packages:
    microcode_ctl-2.1-61.el7.x86_64.rpm | 2.5 MB 00:00:19
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
    Installing : 2:microcode_ctl-2.1-61.el7.x86_64 1/2
    Cleanup : 2:microcode_ctl-2.1-61.6.el7_8.x86_64 2/2
    Verifying : 2:microcode_ctl-2.1-61.el7.x86_64 1/2
    Verifying : 2:microcode_ctl-2.1-61.6.el7_8.x86_64 2/2

    Removed:
    microcode_ctl.x86_64 2:2.1-61.6.el7_8

    Installed:
    microcode_ctl.x86_64 2:2.1-61.el7

    Complete!

    Remember I had not rebooted and was not running the latest kernel. This i7 is running 8 very long (think days) medical research jobs with widely spaced check-points so am reluctant to reboot. Interestingly the i3 here of same vintage as the i7 is running the very latest up-to-date Fedora without a problem; microcode_ctl-2.1-37.fc32.x86_64 and kernel 5.6.16-300.fc32.x86_64. I have two much older Intel boxes, one has ClearOS installed and the other CentOS 7.8, will check them out.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 12:53 PM - #Permalink
    Resolved
    0 votes
    Hi Tony, reading the bug report, is there any chance you can try a "yum downgrade microcode_ctl". It should downgrade to 2:microcode_ctl-2.1-61.el7. If it works, I'd love to know and I'll then get the faulty package removed from the repos. You can block the update by adding the following to /etc/yum.conf:
    exclude=microcode_ctl-2.1-61.6.el7_8
    7.8 and the kernel are not dependent on it.

    All the machines I've upgraded are AMD or VM's as well. I'd struggle to find an Intel server apart from my Business gateway. The bug report seems to point to some Intel servers and I'd doubt very much it is all of them.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 11:05 AM - #Permalink
    Resolved
    0 votes
    Interestingly the Beta tests here were performed on machines with AMD CPUs. The one that had the problem was an Intel, an i7-3770. Intel CPUs generally require more microcode patches against attacks focusing on CPU vulnerabilties. so maybe that was the problem.
    I have now set the default boot kernel to the older currently running kernel, 3.10.0-1062.18.1.el7.x86_64, in case the machine reboots itself. Hopefully that has taken, the list commad indicates success...

    # grub2-set-default 1
    # grub2-mkconfig -o /boot/grub2/grub.cfg
    # grub2-editenv list
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 10:10 AM - #Permalink
    Resolved
    0 votes
    Hi Tony,
    Thanks for the comment. On my main Community test box I have a 1GB /boot partition and it is only 27% used with 5 kernels including one from 7.8 Beta. But if you see the Centos bug linked to in this thread, I wonder if it is a similar issue where microcode_ctl could be doing some sort of post-install script which filled the partition. This is a bitch of a zero day bug for us as it is totally outside our control and none of the hardware we tested on is exposed to the issue so we have no way of testing for it.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 10:00 AM - #Permalink
    Resolved
    0 votes
    Hi Tony,
    Thanks for the comment
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 17 2020, 08:00 AM - #Permalink
    Resolved
    0 votes
    Hi - installed the update - but a little challenge... (there are no problems - only challenges or opportunities :p )
    Had previously installed the Beta on a couple of machines - no problem. However, on updating a production machine the yum update hung right at the end during initramfs stage with a disk full message for /boot - even though it is a full 1G in size. Used yum to delete a couple of older kernels and was then able to finish the update OK using the suggested yum commands from the previous yum error messages. Have now edited /etc/yum.conf to reduce the "installonly_limit" parameter fom the default 5 to 4. Have not yet rebooted into the kernel-3.10.0-1127.10.1.el7.x86_64 - still on 3.10.0-1062.18.1.el7.x86_64. Have reinstalled 3.10.0-1127.10.1.el7 using yum to make sure it is installed correctly. Looked in /boot and initramfs-3.10.0-1127.10.1.el7.x86_64.img seems to be the the expected size and /boot/grub2/grub.cfg seems OK.
    So ensure your /boot partition is large enough! Strangely the 'test' machines with the Beta have slightly smaller /boot partitions.
    Otherwise all appears to be OK so far...
    Edit: The test machines are running kernel-3.10.0-1127.10.1.el7.x86_64 OK
    Edit2: This was a manul update if that matters...
    The reply is currently minimized Show
Your Reply