RedHat have a policy of backporting patches from later packages into a current "stable" version. Our kernel is more like 4.10 or something after that but I'm not exactly sure which. The alternative is ElRepo where there is a bleedin' edge kernel.

Nick Howitt wrote:

By default both "rhgb" and "quiet" appear in the kernel boot line. The **both** need to be removed when you boot. You get about 5 seconds to interrupt the boot process by hitting any key when prompted. Then follow the instructions on screen. The changes only affect the current boot and not subsequent boots.

The kernel, 3.10.0-957.10.1.v7 , is the latest from ClearOS and at Centos (and, presumably, RedHat). The only way to get a later one is to go to someone like ElRepo. Otherwise you will have to wait until RedHat update and the changes are then rolled downstream.

I probably missed out the rhgb in the line, I will take a look.
As for the kernel, I understand that there isn't much can be done if CentOS is what ClearOS derives from. Hopefully with more Ryzen CPUs being deployed RedHat will update their kernel to 4.10+ soon.

By default both "rhgb" and "quiet" appear in the kernel boot line. They **both** need to be removed when you boot. You get about 5 seconds to interrupt the boot process by hitting any key when prompted. Then follow the instructions on screen. The changes only affect the current boot and not subsequent boots.

The kernel, 3.10.0-957.10.1.v7 , is the latest from ClearOS and at Centos (and, presumably, RedHat). The only way to get a later one is to go to someone like ElRepo. Otherwise you will have to wait until RedHat update and the changes are then rolled downstream.

BTW, the post I found on the centos forum was only made yesterday, I think, so after you found your issue.

Nick Howitt wrote:

@Dave, I am responding as I was sent a PM by Sandbo Chang.

When you hit an issue like this it is always worth googling something like your motherboard or processor and "centos". If we have this sort of problem then generally they do as well. When I did that, the first result I bumped into was this. There are no diagnostics or workaround posted.

To troubleshoot you can try interrupting the boot and removing the "rhgb" and "quiet" from the boot line and try to catch any of the resulting messages. I think hitting almost any key during the boot up may achieve the same.

Lastly you can try using an ElRepo kernel where they have the most up-to-date kernels. If you do that and you use the QoS app you will need to change QOS_ENABLE_IFB to "yes" in /etc/clearos/qos.conf and restart the firewall.

If the earlier (7.5) kernel worked you can just make it the default boot option and wait for the next kernel. And FWIW, referencing your Gitlab issue, 3.10.0-957.10.1.v7 is in clearos-verified as well.

Hi Nick,

Thanks for taking time to look the issue up. I did Google a bit but I couldn’t find this post, but I also did have a feeling that it could be an issue with old kernel and the new AMD APUs. I was asking here actually just trying to see if there is other ideas than hardware.

The first thing I looked was to turn off the quiet in boot, but I found that it wasnt quiet by default. As you mentioned, one way may just be to update the kernel to the latest, while I was planning to do it a few days back, I am also worried it makes something incompatible with the later update of ClearOS. So for now I guess it’s best to stick with the previous kernel and hope a later one can work.

@Dave, I am responding as I was sent a PM by Sandbo Chang.

When you hit an issue like this it is always worth googling something like your motherboard or processor and "centos". If we have this sort of problem then generally they do as well. When I did that, the first result I bumped into was this. There are no diagnostics or workaround posted.

To troubleshoot you can try interrupting the boot and removing the "rhgb" and "quiet" from the boot line and try to catch any of the resulting messages. I think hitting almost any key during the boot up may achieve the same.

Lastly you can try using an ElRepo kernel where they have the most up-to-date kernels. If you do that and you use the QoS app you will need to change QOS_ENABLE_IFB to "yes" in /etc/clearos/qos.conf and restart the firewall.

If the earlier (7.5) kernel worked you can just make it the default boot option and wait for the next kernel. And FWIW, referencing your Gitlab issue, 3.10.0-957.10.1.v7 is in clearos-verified as well.

Dave Loper wrote:

I don't get a blank screen on my pre-release board but rather I get a kernel panic. If the screen just goes blank, does it still respond to things like SSH or Webconfig?

That's what puzzled me, the screen simply went blank (black) with no information at all.
The power button then can no longer soft turn off the computer, and trying to reach the terminal by Alt-F2 won't work either. (Ctrl-Alt-Del has not reponse). SSH not tried but I pretty much believe it won't connect.
The only thing I could do was to hard reset.

I don't get a blank screen on my pre-release board but rather I get a kernel panic. If the screen just goes blank, does it still respond to things like SSH or Webconfig?

Dave Loper wrote:

Sandbo,

Can you send me a screenshot of the boot for the newer kernel.

I have one (and only one system) that has a kernel problem and it is on an AMD-based Microserver Gen10 server. Of particular note on this server is that I have several of them (MicroServer Gen10) and the only one that I have a kernel issue with is a pre-release board with an early BIOS. I've not updated the BIOS yet on it since I have had some other early pre-release boards that bork when production BIOS is applied (no problems with boards that are production [ie. green boards]).

This may just be an issue with your BIOS and an update to your BIOS may allow the newer kernel to work. Please let me know what you find.

Hi Dave,

Thanks for looking into it.
I will try to capture the screen (can only do so from my phone). Basically during boot after the BIOS post screen, it first shows the screen (with some Linux Penguins) with a few messages in common with other kernels (which work), but then quickly jump to a completely blank, black screen where I cannot see any error messages. In working kernels, the previous boot screen stays longer and will further report the detection of the attached USB devices.

Regarding the BIOS, I have updated to the second latest non-beta BIOS of my board, MSI B450M Gaming Plus. The latest one is meant to support the upcoming Ryzen 3000 series CPU and the AGESA 0.0.7.2 is in beta so I didn't try it. I can see if I have a chance to upgrade and test later today.

Sandbo,

Can you send me a screenshot of the boot for the newer kernel.

I have one (and only one system) that has a kernel problem and it is on an AMD-based Microserver Gen10 server. Of particular note on this server is that I have several of them (MicroServer Gen10) and the only one that I have a kernel issue with is a pre-release board with an early BIOS. I've not updated the BIOS yet on it since I have had some other early pre-release boards that bork when production BIOS is applied (no problems with boards that are production [ie. green boards]).

This may just be an issue with your BIOS and an update to your BIOS may allow the newer kernel to work. Please let me know what you find.

Probably not exactly due to 7.6 as it works for me a few days ago, my router now boots into a blackscreen which is frozen (nothing except hard reset by powering off then on).
I only found that after rebooting the router today so I cannot isolate the cause.

I found that I can boot into this kernel:
3.10.0-862.11.6.v7.x86_64
But fails on this newer one which is default
3.10.0-957.10.1.v7.x86_64

Checking the kernels, the first one that works fall under "clearos-verified", but the second that which failed to work wasn't labelled verified.
I thought with the Home subscription I should only receive the verified one, maybe something is missed?

My system:
ClearOS 7.6 Home
AMD Athlon 200GE
Intel i340-T4

Temporarily I have set the old kernel as default to allow the router to work.
Any ideas what may have gone wrong?

I've taken mine back to the barest (minimal) installation (luckily I'd taken a snapshot), fixed the paravitualization issue and it has now updated correctly.
Irritation over

Thanks for the announcement!

My system was updated without any issues!

==============================================================================================================================================

 Package                               Arch             Version                                      Repository                          Size

==============================================================================================================================================

Installing:

 podman                                x86_64           0.12.1.2-2.git9551f6b.el7.centos             centos-extras-unverified           7.6 M

Installing for dependencies:

 atomic-registries                     x86_64           1:1.22.1-26.gitb507039.el7.centos            centos-extras-unverified            35 k

 containernetworking-plugins           x86_64           0.7.1-1.el7                                  centos-extras-unverified            10 M

 containers-common                     x86_64           1:0.1.31-8.gitb0b750d.el7.centos             centos-extras-unverified            21 k

 criu                                  x86_64           3.9-5.el7                                    centos-unverified                  432 k

 libnet                                x86_64           1.1.6-7.el7                                  centos-unverified                   59 k

 protobuf-c                            x86_64           1.0.2-3.el7                                  centos-unverified                   28 k

 runc                                  x86_64           1.0.0-59.dev.git2abd837.el7.centos           centos-extras-unverified           2.9 M



Transaction Summary

==============================================================================================================================================

Install  1 Package (+7 Dependent packages)



Total download size: 21 M

Installed size: 80 M

..and there is podman!!

Ok thanks Dave - although I assumed from your post that it had mirrored completely .. my bad.

AFA the virtio thing, you've completely misunderstood - I'm not interested in getting a Windoz machine working as a paravirtualized object .. I know all about that.

No, the issue was with getting a ClearOS box working as a paravirtualized object. Everything I've read says that kernels from 2.6 (or thereabout) ship with virtio_net enabled; ClearOS doesn't (because of the missing config file), so trying to turn a virtual machine of COS7 into a pv object (complete with pv network interface) fails as the interface eth0 (created when virtio_net is enabled by the creation of the config file) isn't detected and it was only after a load of poking around that I discovered what was missing.

Certain mirrors, have yet to be updated. Others including voluntary ones have had issues (like running out of space). A lot moves around and some mirrors still have to finish their syncs. Normally, if it fails in part of the process, it shuts the process down for all of it. This is a good thing because you don't get the update piecemeal. I would not suggest enabling individual repos to get only parts of 7.6 in the manner you describe but to let the auto updates do their job and fail today and work when all is settled. With windows, updates like this come in a single patch file instead of individual files. This all means that a failure to updates is not a bad thing, it indicates that things are not yet in order for the update to happen correctly. This all will resolve in time with no addition work on our part making it go any faster. If your box hit a mirror on which this worked, you are already updated. If your box does not, it will come down tonight or tomorrow night.

===========

Sorry about not having steps for crafting virtio. We generally recommend using the upstream Fedora drivers since:

1) They are fully compatible with ClearOS.
2) They went ahead and got the drivers digitally signed.
3) They always have updates when needed.
4) They do the full stack including network, storage, USB, and others.

The virtualization solution from ClearCenter is ClearVM or ClearGLASS. One place you can read about the virtio drivers is here: https://www.clearos.com/resources/documentation/clearos/content:en_us:vm_windows-2012

Ok, this is ridiculous.

How long does it take for the repositories to completely update as I'm getting errors left, right and centre. It starts with -

clearos-contribs,
then clearos-infra,
then clearos-centos-verified,
then clearos-epel-verified,
then clearos-verified,

and then after temporarily disabling each in turn

dies as openldap updates fail.

Awful. 404 Not found all over the place; and this apparently over 7 hours after everything went live.

Luckily it's on a new mail server I'm trying to put together (existing one is on COS6), so I'm not dead, but I dread to think what's going to happen to my two existing COS7 servers ...

Losing the will to live at this point.

ON THE PLUS SIDE however, I've managed to get (this) COS7 machine working as a VM using virtio (no documentation on this BTW!).
How?

1. You first need to create virtio_net.conf containing 'virtio_net' in the kernel modules conf area (just about every other linux based installation seems to enable this by default BTW ... - at least from reading between the lines on every google search I did on the subject)

2. And this took some head scratching ...
virtio_net actually uses the old eth0 interface, so you need to hand create a configuration file in the network-scripts directory. From what I've been able to ascertain, if the virtio_net configuration was there to begin with, eth0 would have been there as an option at the outset.

3. Reboot and there's your interface all ready to be setup.

It might be worth adding something to the installer asking if the target machine is to be a VM and if the user wants to use virtio_net as the network driver; this could then be handled up front. I suspect this would be of interest to business users where most machines are VMs residing on dedicated hardware. In my case, I've a big(ish) headless VirtualBox server/disk setup that will hold this VM (when it works!), along with a couple of Win10 and Ubuntu VMs. Just makes backups so much easier when you can save the whole thing!