To be very honest, when I posted a few days ago, Oracle Database 19c is certified on OL8/RHEL8 I didn’t check for the Oracle Clusterware (OCW) certification. I blindly assumed that this is the case. But from comments and discussions on twitter, I realized it may be necessary to point this out explicitly to avoid confusion. Even though my fellow mate, RAC Product Manager Anil Nair has pointed it out already many times: Of course, Oracle Clusterware is certified on OL8/RHEL8 as well.
Find it on MOS
Your source for certification information for Oracle products is MyOracle Support. Hit the “Certification” tab.
As you see, there is a separate Product “Oracle Clusterware“. And once you choose “220.127.116.11.0” as Release, you will get the Platform options OL8 (marked blue) and RHEL8 (two lines above OL8).
So yes, you can have OCW 19c on OL8 and RHEL8. And the fine print says:
- For OL8, it has to be Update 1 or newer (i.e. 8.1, 8.2 etc)
- Minimum RU is 19.7.0
- Minimum kernel versions:
- Oracle Linux 8.1 with the Unbreakable Enterprise Kernel 6: 5.4.17-2011.0.7.el8uek.x86_64 or later,
- Oracle Linux 8.0 with the Red Hat Compatible kernel: 4.18.0-80.el8.x86_64 or later
- Oracle Linux 8.1 with the Unbreakable Enterprise Kernel 6: 5.4.17-2011.0.7.el8uek.x86_64 or later,
And some people really tested it right away 🙂 Very cool!
For important patches, please find this section in the Oracle Documentation:
ASMLIB and ASMFD on OL8, RHEL8 and SUSE SLES
Please visit this MOS Note 1369107.1 – ACFS Support On OS Platforms (Certification Matrix), and scroll dooooooown to Note 1 – ACFS support for new OS updates.
There you will find several bug numbers specified. This means, depending on your kernel/version, you will need to request request via an SR a BLR for the specific bug numbers listed in the notes. Then a patch will be produced and provided via download.
Important Annotation – Oct 1, 2021
Based on a discussion and a call with Anil Nair, PM for RAC and ASM, I’d like to add the following links:
which is a must-read for you when you don’t use Oracle Linux but instead, RHEL or SLES. There are certain dependencies and requirements you must follow. And the note explains all this regarding the ASMFD.
Further Information and Links:
- Oracle Database 19c is certified on OL8/RHEL8
- Clusterware 19c certification on OL8
- Clusterware 19c certification on RHEL8
- Certification OL8 for Oracle Database 19c
- Certification RHEL8 for Oracle Database 19c
- Patching all my environments with the April 2020 Bundles (includes 19.7.0)
- Known Issues and Bugs with OL8/RHEL8
- MOS Note 1369107.1 – ACFS Support On OS Platforms (Certification Matrix)
Just waiting now to see if EBS R12.2 application tier and EBS database tiers are certified for OEL8 and when is the preinstall RPMs for EBS and DB available in the OEL8 addons repo
I am an Oracle engineer in Japan.
“Oracle 19c (19.7) Clusterware is certified on RHEL8”
I want to know the pre-requisite PKG in RHEL8 installation requirements, but no info anywhere.
Help me. please tell me.
I did a deep check on MOS, but I only found this note:
Oracle Support Document 2668780.1 (Requirements for Installing Oracle Database 19c on OL8 or RHEL8 64-bit (x86-64)) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2668780.1
Which is for the database only, and explicitly says, it does not cover GI.
So for the database, this will help you.
But for GI, you may need to open an SR please and check with Oracle Support.
Thanks, and kind regards,
But still no AFD support for OL8.x…sigh….any clue if/when that is coming?
No, you will need to bother Oracle Support with this please.
Hi Mike, do we have ASMlib packages for OL8?
I am not able to find them, with el7 packages i am not able to get working asmlib on OL8,
my system is on Azure: 4.18.0-147.8.1.el8_1.x86_64
please open an SR and check with Oracle Support. I have seen mixed messages (people using the lib from OL7 with success) but not sure what’s right or wrong.
There are different messages written about 19.8 and RHEL8.2. I am constantly getting the “AFD-620: AFD is not supported on this operating system version: ‘unknown'”-message. Someone is saying 82 is not supported?
does this happen during the installation on 8.2?
Then try with ./runInstaller -ignoreSysPreReqs
As far as I’m aware (and this is what the official information on MOS says), 19c (and this includes all RUs unless otherwise stated) is supported on RHEL 8.2.
Mike, -ingnoreSysPreReqs is not a valid option for the gridSetup.sh. Here is what is happening:
/u01/app/oracle/product/19.0.0/grid/gridSetup.sh -silent -responsefile /home/oracle/gridsetup19.rsp
Launching Oracle Grid Infrastructure Setup Wizard…
[FATAL] [INS-41223] ASM Filter Driver is not supported on this platform.
ACTION: To proceed, do not specify or select the Oracle ASM Filter Driver option.
– AFD-620: AFD is not supported on this operating system version: ‘unknown’
It would be strange if they support GI without AFD as AFD is told to be a very good thing when it comes to reduce of IO’s against the disks where the ASM resides.
I did create a SR yesterday and then we will see what comes out of that
Thanks Kurt – I didn’t try it – thanks for the update.
Did a SR at this spesific problem:
“…..you can apply patch 31643145 to fix this issue”
Did not work as this end up in conflict. Did a reply with output and so on
“AFD is currently not supported on any version of Linux 8 you will have to use Linux 7 or not use AFD”
Typically workflow in MOS. They suggest a solution and say nothing about the feature is not supported. Further on after spending more time with it they state that this is not supported 🙂
By the way – the Certification says RHEL8 is supported, but sas nothing about the AFD.
Well….. better wait with this plattform 🙁
Did a SR about this matter and firstly they asked me to install a patch, but as this patch ended up with conflict they told me that AFD is not supported in RHEL8.
AFD is told by Oracle to limit IO-request against disks and because of that it is improving perfomance. It is supposed to replace ASMLibs which has not been developed or updated sonce long time ago.
MOS said the solution is not to use RHEL8 and go back to RHEL7. Arrogant as always 🙂
Interesting that a certified product is does not include the out-of-the-box-stack.
I see the dilemma 🙁
But I couldn’t get more information about it internally either.
did Oracle provide you with a workaround to use ASMLib on RHEL 8? I got the AFD-620: AFD is not supported on this operating system version: ‘unknown’ error while installing Grid 19.3 on RHEL 8.2. Put in a SR and was suggested to apply a merge patch on top of RU 19.8 $GI_HOME/gridSetup.sh -applyRU /31305339 -applyOneOffs /31692197
Then I got another error AFD-9384: INVALID OS kernel variatiion el8-2
As they say AFD is going to be a replacement for ASMLib we have been using AFD since version 12.2. Also Oracle recomend the use of AFD to reduce the IO-request from the OS. Sad that this is not supported on RHEL8.
Here is what i got from Oracle Support:
ASM Filter Driver (ASMFD or AFD) is a disk management tool that is optional. ASMLib also is a disk management tool that is optional. Neither are required but one of the two is recommended by Oracle to ease management of disks. As mentioned in previous updates AFD is not supported on Linux version 8 at all. There are several options. One you can not use AFD at all but can use udev rules, two you can use AFD and use Linux 7 or lower version where it is supported, three, you can use ASMLib kernel driver in place of AFD. If using option 3 and if you have issues depending on if you are on RedHat or Oracle Linux you will need to either engage RedHat or Oracle Linux as we support the use of it but we do not own the code nor do we support its configuration.
thanks for the update. Their reply sucks. On my side I managed to engage with their solution engineer and he asked me to put in a so called BLR for RHEL 8.2 support and I did. It has been a few days and again they asked me to try many things including different ways to stall latest patches, cleanup, and install but none of them could pass the nasty AFD-9384 kernel not supported error. Now my SR has been sitting there without update for two days. They actually have bugs tracking for the AFD support issue on RHEL 8.2 and the latest patch released in this month is supposed to fix the problem. But based on my test, it doesn’t.
29557768 RHEL8 GA and OL8 RHCK GA SUPPORT FOR ACFS/AFD
31019017 RHEL8.1 and OL8.1 RHCK SUPPORT FOR ACFS/AFD
31480077 RHEL8.2 AND OL8.2 RHCK SUPPORT FOR ACFS\AFD – 4.18.0-193
Wow, this sucks. The fact that no one seems willing to take ownership of getting AFD going on OL8 is sort of incredible, given that the “official” Oracle position is that “AFD replaces ASMLib, and AFD is a good thing.”
It seems to me that there should be someone in Oracle who is tasked with the responsibility to resolve this issue.
Are they expecting us to wait for OL9, to see if AFD will be supported there?
Thanks to Mike and Kurt for all the work on this!
I get really bored of MOS and their support. They have certified the RHEL8 but without support for their “recommended” AFD, which where supposed to be the new thing and best practice. Replacing the old ASMlib
Hi did you try setting UDEV rules for asm storage? I configure udev rules for asm disk and it works fine.
Hi had anyone test 19.8c Orachk with RHEL 8 ? I run it but I had and empty report all times that I had run it.
Only Had failed checks with wrong file permission but the root.sh scripts had run ok and the installation has no errors. All other verifications all empty. Did anyone test it?
Just did my testing with GI 19.9 on RHEL8.
I found that ACFS was running with Kernel 4.18.0-147.el8 and Patch 31838226.
I did the test a Kernel Upgrade to 4.18.0-193:
– Rollback Patch 31838226.
– Installed Patch 31480077 –> Includes Kernel Modules for Kernel 4.18.0-193
– Installed and Booted the latest -193 Kernel Version: 4.18.0-193.28.1
Result: “ACFS-9384: Invalid OS kernel variation ‘el8_2’.” When loading acfs module.
Let’s query the available Kernel versions:
# yum list kernel –showduplicates
kernel.x86_64 4.18.0-193.el8 @rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-193.28.1.el8_2 @rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-80.el8 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-80.11.2.el8_0 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-147.el8 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-147.8.1.el8_1 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-193.el8 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-193.28.1.el8_2 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-240.el8 rhel-8-for-x86_64-baseos-rpms
kernel.x86_64 4.18.0-240.1.1.el8_3 rhel-8-for-x86_64-baseos-rpms
Seems that only the Base Kernel Version of a Release is named .el8 and all Updates to that Base Version are named .el8_
‘uname -r’ does also show the .el8_ string. And ACFS drivers will only load id they find .el8
So I booted Kernel 4.18.0-193.el8 and ACFS is running again.
Oracle does only support the base Kernel version of a release with the current patches in EL8. No Updated Kernel version will run because these Kernels change the output of ‘uname -r’ to “el8_” instead of using “el8”.
Thanks for sharing, TZar – and actually my current recommendation to all my customers is OL7 or RHEL7.
my 19.9 grid standalone installation is failing with the below errors on 8.3 ( 4.18.0-240.1.1.el8_3.x86_64)
ACFS-9384: Invalid OS kernel variation ‘el8_3’.
2020-12-21 11:52:11.990 [OHASD(2667235)]CRS-0715: Oracle High Availability Service has timed out waiting for init.ohasd to be started.
2020-12-21 13:14:34.677 [CLSECHO(52825)]CLSRSC-0567: Beginning Oracle Grid Infrastructure configuration.
2020/12/21 13:16:57 CLSRSC-318: Failed to start Oracle OHASD service
Died at /u01/app/oracle/product/19c/asm_1/crs/install/crsinstall.pm line 3290.
sorry to hear that – but please you need to work this out with Oracle Support.
We can’t replace Support with this blog.
I tried an Upgrade to 19.10 – that fixed the issue
Thanks for the feedback, Christian!
Really? That’s what I thought I had done when I applied the January PSU/RU (from opatch lsinv):
Patch 32222571 : applied on Sat Mar 27 18:39:24 CDT 2021
Unique Patch ID: 24017129
Patch description: “OCW Interim patch for 32222571”
Patch 32218663 : applied on Sat Mar 27 18:36:11 CDT 2021
Unique Patch ID: 23983106
Patch description: “ACFS RELEASE UPDATE 18.104.22.168.0 (32218663)”
Patch 32218454 : applied on Sat Mar 27 17:25:41 CDT 2021
Unique Patch ID: 24018797
Patch description: “Database Release Update : 22.214.171.124.210119 (32218454)”
Patch 29340594 : applied on Sat Mar 27 17:17:31 CDT 2021
Unique Patch ID: 24005319
Patch description: “DBWLM RELEASE UPDATE 126.96.36.199.0 (29340594)”
Yet, when I try to configure AFD, it craps out:
# asmcmd afd_configure
ASMCMD-9520: AFD is not ‘supported’
Looking at the support matrix in MOS Note 1369107.1, it indicates that the kernel my sysadmin installed when he built this machine for me is TOO NEW!?!
# uname -r
# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)
So at this point, I just reverted to a really kludgy use of asmlib to get it working. It does work, but this is really, really awkward.
Thanks, Mike, for a great resource for those of us struggling to navigate the choppy waters of the life of an Oracle DBA. 🙂
I fear that Kernel modules shipped with 19.10 are only for Rhel 8.2 Kernel (4.18.0-193) .
So for AFD you might have to use a 4.18.0-193 Kernel version.
Kernel Modules shipped can be found at GI_HOME/usm/install/
Maybe we get Kernel modules with 19.11 which will be released this month.
Yep, it looks that way. I did discover, however, that by using ASMlib & setting my asm_diskstring to “/dev/oracleasm/disks/*” I was able to get things sort of working. By “sort of”, I mean that the database is there, and I can perform operations on it, but random stuff doesn’t work (mostly third-party, such as the RMAN plugin for our backup software). This is pretty kludgy. I’m guessing the April RU will be released any day now, so I’ll hold out hope that cleans it up. This is going to be a real pain for our sysadmin if he has to wait for an Oracle RU every time he wants to do OS patching.
OK, so I installed the 19.11 RU today, and still no luck:
# asmcmd afd_configure
ASMCMD-9520: AFD is not ‘supported’
Alas, the aforementioned MOS not for AFD support has been updated for 19.11 for some platforms (e.g. SLES), but for RHEL8, it still indicates that the highest supported kernel is 4.18.0-193. This is an incredibly frustrating experience. 🙁
We had this same issue one month ago and I put in an Severity 1 SR to Oracle. They delivered an interim patch after a few days.
Please search and download patch 32408255. It will fix the RHEL 8.3 kernel compatibility issue with Oracle 19C.
Anybody who have managed to get an out-of-the-box installation of RHEL8 with latest updates to accept the AFD-driver now? Oracle did recommend RHEL7, but this version has end-of-life by june 2024. At the moment we want to use RHEL8 when deploying new servers. The solution for us was to use udev rules, but this is not our favorite as we already had some problems due to the fact that AFD is protecting the disks in a better way.
did you see my addition from Oct 1 in the blog post?
Didn’t MOS Note: 2806979.1 – Oracle Automatic Storage Management Filter Driver (ASMFD) help and answer your question?
If not, then please open an SR. The topic got explained to me but I’m not a true expert I’ve to confess.
Hi Mike !
No I didn’t see your addiction, but thanks for the update and the MOS Note. This MOS note explain a bit about the bumpy road AFD has had in RHEL8. As we have been using AFD for years on Oracle 12.x and RHEL7, we started with udev when migrationg to RHEL8 this year. This was looking as a ok alternative until the day a Linux junior start tampered with the disks as he was in the opinion that the disks was not in use 🙂 The rest of the story – I guess you know 🙂
By then we started to search for the use of AFD again – but it looked like a bit bumpy from our point of view. Our main argument for using AFD is disk-protection, but also I might read between the lines that AFD can be more faster. Don’t know how much that matter plays in real world, but in theory it might be.
Well, we will follow this and consider to start using it. But I can see some problems as our Linux admins are updating the kernel in a quite fast frequencies. So this can lead us into some problems. I guess we will hang out until the ASMFD get more mature together with the kernel
Thanks for the feedback, Kurt – and I have a pretty solid idea where this went to … 😉
Thanks for sharing – kind regards,