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.

Hi Nick,

With a systemcl restart its running just fine! Seems only to happen on a boot!
Anyone else who has this?

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).

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?

Hi Nick,

Working on 2 systems after reboot!

Updating : 2:microcode_ctl-2.1-61.10.el7_8.x86_64

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.

@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.

Nick Howitt wrote:

Sorry. /etc/suvad.conf.

It is 935856

Sorry. /etc/suvad.conf.

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

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?

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

@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,

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]

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)

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 ~]#

So what do you get from:

cat /etc/clearos-release

yum repolist

yum update

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

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.

@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.

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

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 ???

Just upgraded a production machine on a HP system with Intel(R) Core(TM) i5-4570 CPU.
Booted just fine !

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.

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.

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.

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.

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.

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

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.

Hi Tony,
Thanks for the comment

Hi - installed the update - but a little challenge... (there are no problems - only challenges or opportunities )
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...