CI: Add CentOS Stream 9/10 to the FULL_OS runner list

[carlwgeorge]

Motivation and Context

Testing on CentOS Stream provides several months advance notice of changes coming to the RHEL kernel. This should help OpenZFS be proactive instead of reactive to new RHEL minor versions.

Description

I partially reverted the changes in #16904 which made CentOS Stream 9 an optional runner, and added CentOS Stream 10 to the FULL_OS runner list.

How Has This Been Tested?

As this is a change to the CI itself, I'd like the CI run on this PR to serve as the testing.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[carlwgeorge]

@behlendorf I noticed that the CI run for this PR seems to have used the QUICK_OS list, not the FULL_OS list. Would it be appropriate to add CentOS Stream 9 and 10 to the QUICK_OS list as well?

[behlendorf]

@carlwgeorge the QUICK_OS gets used when the CI determines the PR doesn't have any ZFS code changes. So it worked properly here, and we wouldn't want to add the new runners to the QUICK_OS list. You should be able to force a full run by adding "ZFS-CI-Type: full" to your commit message and force updating the PR.

[carlwgeorge]

I think this may have already identified a change in the RHEL 9.7 and 10.1 kernels that will be a problem for the kmods for those minor versions down the road.

On Alma 9:

checking whether CONFIG_OBJTOOL_WERROR is defined... no

  make -C /usr/src/kernels/5.14.0-570.24.1.el9_6.x86_64  \
  	  \
  	 \
  	 \
  	 \
  	M="$PWD"  CONFIG_DEBUG_INFO=y CONFIG_ZFS=m modules

On CentOS Stream 9:

checking whether CONFIG_OBJTOOL_WERROR is defined... yes

   make -C /usr/src/kernels/5.14.0-596.el9.x86_64  \
  	  \
  	 \
  	 \
  	objtool=../scripts/objtool-wrapper \
  	M="$PWD"  CONFIG_DEBUG_INFO=y CONFIG_ZFS=m modules

  /bin/sh: line 1: ../scripts/objtool-wrapper: No such file or directory

Similar output can be observed for version 10 of each.

Is it possibly that something is wrong with the generation of scripts/objtool-wrapper or the path to it? I'm not real strong with autoconf so I'd appreciate any pointers here.

[AttilaFueloep]

Does scripts/objtool-wrapper exists after configure and if so what is its content.

[AttilaFueloep]

I had a look, the wrapper seem to get created

config.status: creating scripts/objtool-wrapper

I'd need access to the filesystem of the runner to root cause the failure.