1.
ZeroAOS를 서비스할 때 주로 사용하는 OS는 Centos입니다. CentOS와 관련한 정책이 2022년부터 바뀌면서 CentOS Stream이라는 이름을 사용하고 있습니다. CentOS, CentOS Stream 그리고 대안에서 정리한 정책을 반영한 결과입니다.
고객이 새로운 서버를 요청하여 관련한 환경을 구축하기 위하여 Centos 8을 찾았습니다. 그동안 Centos 8을 설치하였는데 홈페이지에서 더이상 ISO파일을 받을 수 없네요. 고민을 하다가 시간도 있고 해서 Rocky Linux를 설치하였습니다. Xeon CPU를 2개가 달린 중국산 메인보드로 Rocky Linux Server를 구축해서 사용하기 때문에 설치 자체는 문제가 아니었습니다. 어플리케이션도 문제가 아닙니다. OS를 변경할 때 번거로운 점은 Ethernet Interface입니다. 고객이 요청한 제품은 Chelsio입니다.
Chelsio가 지원하는 배포판은 RHEL, SUse 및 Ubuntu입니다. RHEL용 파일을 다운로드 받아서 설치해보았습니다. install.py를 실행하니까 아래와 같은 메시지가 나옵니다.
The Operating System is not supported.
For the list of Supported Platforms and Operating Systems.
혹시나 했는데 역시나 오류가 발생합니다. 물론 python 파일을 수정할 수 있지만 굳이 그럴 필요가 없어서 소스파일을 받아서 컴파일을 했습니다. 별다른 문제 없이 install 까지 하였습니다. modprobe를 한 후 dmesg로 커널 로그를 확인하였습니다.
Warning:-
[ 629.090891]_pcie: loading out-of-tree module taints kernel.
[ 629.090921] pcie: module verification failed: signature and/or required key missing – tainting kernel.
우선 Tainted Kernel이라는 표현이 생소합니다. What is a tainted Linux kernel?을 찾아본 결과입니다. 간단히 요약하면 ‘정상적인 동작을 보장할 수 없지만 그렇다고 동작하지 않는 것은 아닌, 비정상적인 동작을 하는 경우가 발생할 수 있는 상태‘라는 뜻입니다.
A tainted kernel is one that is in an unsupported state because it cannot be guaranteed to function correctly. Most kernel developers will ignore bug reports involving tainted kernels, and community members may ask that you correct the tainting condition before they can proceed with diagnosing problems related to the kernel. In addition, some debugging functionality and API calls may be disabled when the kernel is tainted.
The taint state is indicated by a series of flags which represent the various reasons a kernel cannot be trusted to work properly. The most common reason for the kernel to become tainted is loading a proprietary graphics driver from NVIDIA or AMD, in which case it is generally safe to ignore the condition. However, some scenarios that cause the kernel to become tainted may be indicative of more serious problems such as failing hardware. It is a good idea to examine system logs and the specific taint flags set to determine the underlying cause of the issue.
This feature is intended to identify conditions which may make it difficult to properly troubleshoot a kernel problem. For example, a proprietary driver can cause problems that cannot be debugged reliably because its source code is not available and its effects cannot be determined. Likewise, if a serious kernel or hardware error had previously occurred, the integrity of the kernel space may have been compromised, meaning that any subsequent debug messages generated by the kernel may not be reliable.
Note that correcting the tainting condition alone does not remove the taint state because doing so does not change the fact that the kernel can no longer be relied on to work correctly or produce accurate debugging information. The system must be restarted to clear the taint flags.
More information is available in the Linux kernel documentation, including what each taint flag means and how to troubleshoot a tainted kernel prior to reporting bugs.
A partial list of conditions that can result in the kernel being tainted follows, each with their own flags. Note that some Linux vendors, such as SUSE, add additional taint flags to indicate conditions such as loading a module that is supported by a third party rather than directly by the vendor.
- Loading a proprietary (or non-GPL-compatible) kernel module. As noted above, this is the most common reason for the kernel to become tainted.
- The use of staging drivers, which are part of the kernel source code but are experimental and not fully tested.
- The use of out-of-tree modules that are not included with the Linux kernel source code.
- Forcibly loading or unloading modules. This can happen if one is trying to use a module that is not built for the current version of the kernel. (The Linux kernel module ABI is not stable across versions, or even differently-configured builds of the same version.)
- Running a kernel on certain hardware configurations that are specifically not supported, such as an SMP (multiprocessor) kernel on early AMD Athlon processors not supporting SMP operation.
- Overriding the ACPI DSDT in the kernel. This is sometimes needed to correct for firmware power-management bugs; see this Arch Linux wiki article for details.
- Certain critical error conditions, such as machine check exceptions and kernel oopses.
- Certain serious bugs in the BIOS, UEFI, or other system firmware which the kernel must work around.
해결방안이 궁금해서 몇 가지 찾았습니다. 우선 module verification failed: signature and/or required key missing – tainting kernel 은 Redhat이 제공하는 해답이자만 계정이 없어서 포기했습니다. 앞서 dmesg중 ‘module verification failed’와 관련하여 Kernel module signing facility을 보니까 다음과 같은 내용이 있었습니다.
Non-valid signatures and unsigned modules
If CONFIG_MODULE_SIG_FORCE is enabled or module.sig_enforce=1 is supplied on the kernel command line, the kernel will only load validly signed modules for which it has a public key. Otherwise, it will also load modules that are unsigned. Any module for which the kernel has a key, but which proves to have a signature mismatch will not be permitted to load.Any module that has an unparseable signature will be rejected.
그래서 소스중 makefile의 처음에 ‘CONFIG_MODULE_SIG=n’을 추가해서 다시 컴파일을 했습니다. 구글링하면 정상 동작한다는 글도 있지만 제 경우에는 동일한 메시지가 발생합니다. 좀더 찾아서 수정할 수도 있지만 그럴 마음이 없네요. 결국 Centos를 torrent 사이트를 검색해서 다운로드 받고 설치하였습니다.ㅠㅠㅠㅠㅠ
2.
CentOS에 설치하는 것은 쉽습니다. 제 경우에는 소프트웨어 설치를 위해서 필요한 Repository가 문제였습니다. 예를 들어서 python을 설치하려고 명령어를 입력하면 아래와 같이 응답합니다.
Error: Failed to download metadata for repo ‘appstream’: Cannot prepare internal mirrorlist: No URLs in mirrorlist
그래서 검색을 해보니까 CentOS 8 Stream 으로 배포판을 변경하지 않아서 발생하는 문제입니다. Redhat이 지원을 끊었다는 뜻입니다. 혹시나 해서 방법을 찾아보니까 CentOS 8: Failed to download metadata for repo ‘appstream’에서 Repository 정보를 변경하려고 합니다.
vault.centos.org
이렇게 변경하고 해보니까 역시나 동일합니다. vault도 지원하지 않습니다. 좀더 검색하니까 다른 URL을 알려주는 곳이 있더군요….How to fix dnf after CentOS 8 went EOL에서 알려주는 URL입니다.
vault.epel.cloud
위로 변경하고 확인하니까 다음과 같은 결과가 나옵니다. 정상 동작합니다.
[root@as10]# dnf repolist
repo id repo name
appstream CentOS Linux 8 – AppStream
baseos CentOS Linux 8 – BaseOS
extras CentOS Linux 8 – Extras
Rocky Linux와 Almalinux가 Cenos의 대체재로 많이 사용하는 듯 합니다. 두 배포판의 차이는 특정한 회사의 영향력인 듯 합니다. Almalinux는 CloudLinux의 지원을 받아서 나온 배포판입니다. 저의 경우 아직 Almalinux를 설치해보지 않았는데 설치하려고 합니다. Clear Linux외에 Rocky Linux, Centos로 만들어진 시험환경에 Almalinux 를 추가할 계획입니다.
