ZoL has not released a kABI for el8_2 so you will have to use DKMS to get it to work with RHEL/CentOS 8.2 for the time being.
Not testing it on 1 or 2 first??
I only have ZoL on my main server. My nas runs FreeNAS.
All my other VMās updated to el8.2 just fine but this was the issue when I updated the underlying system because all the VMās are stored as .qcow2 on a SSD zpool.
oic. My dad is still testing it on 2 vms to make sure.
Yeah unfortunately I donāt have any secondary serverās to do a proper DR testing but what I had to do was uninstall ZoL and reinstall from the 8.1 repo and then enable DKMS and then it rebuilt the package and my pool was imported.
The version did not change it is still 0.8.4-1 but due to the way the kernel modules load this was necessary.
Everything else works without issue.
Now, CentOS can be a valid type of hypervisor.
There is a pretty major issue on latest CentOS 7 and 8. Looks like itās on skylake xeons, not sure if itās broader in scope, but itās definitely breaking servers.
I had an update to that microcode package but everything installed successfully (AMD Epyc). My whole environment is updated now.
I do see however, that the update to 8.2 re-enabled kdump (I disable it for VMās), and that the MCElog now fails saying my CPU is not supported.
Everything else works fine.
Thatās interesting. STIG says to leave it off because of a security concern, I forget what exactly. I wonder if thatās going to inadvertently throw some people out of compliance.
Yeah, so MCELog has a problem with Zen architectures for some reason. I remember running into this when I was on Fedora. I just yeeted the daemon. This was back when I was on a 1700x.
Actually, its disabled. But I get more annoying errors about it being turned off.
OH WELL THEN.
what does the MCELog even do?
What does Machine Check Exception Logging Daemon even do?
Most of the time, youāll get ECC or memory problem reports here, but itās really any hardware error the kernel can detect will be noted in that log.
Perfect so I can ignore it. Any hardware issues I use my iLO for.
Yep, basically.
My hardware error detector is segfault -> memcheck -> stability test
So my boss is working on hiring a company to do a security audit of us and I canāt wait. We have some really bad security practices here for the sake of convenience.
Hereās a fun one.
GitLab released a package build for el8
but has not released a complimentary package for the gitlab-runner
because in el8
RedHat dropped support for Docker in favor of Podman.
Now podman is great but there was a lot of infrastructure build up around that.
I managed to get gitlab-runner
installed via the rpm script by telling it to install the el7
version of the package and it seems to work just fine. The issue is that I cannot use the docker
executor when registering a runner because the way the runners are built they need to communicate with the docker daemon, which podman doesnāt have.
So I am currently experimenting with using the shell /ssh executors.
tldr; if you still want to use GitLab runners with docker then you need to stay on el7
or switch to Debian.
Does the runner need to be on the same machine as gitlab?
It does not.
This sounds like a PSA that Gitlab should be aware of.