8.8. 커널
RHEL 9 커널에서 kdump
가 시작되지 않음
RHEL 9 커널에는 crashkernel=auto
매개 변수가 기본값으로 구성되어 있지 않습니다. 결과적으로 kdump
서비스가 기본적으로 시작되지 않습니다.
이 문제를 해결하려면 crashkernel=
옵션을 필수 값으로 구성합니다.
예를 들어 grubby
유틸리티를 사용하여 256MB의 메모리를 예약하려면 다음 명령을 입력합니다.
# grubby --args crashkernel=256M --update-kernel ALL
결과적으로 RHEL 9 커널은 kdump
를 시작하고 구성된 메모리 크기 값을 사용하여 vmcore
파일을 덤프합니다.
(BZ#1894783)
LUKS 암호화 대상에서 vmcore
를 캡처하지 못했습니다.
Linux 통합 키 설정(LUKS) 암호화 파티션을 사용하여 시스템에서 kdump
를 실행하는 경우 시스템에는 사용 가능한 특정 양의 메모리가 필요합니다. 사용 가능한 메모리가 필요한 메모리 양보다 작으면 systemd-cryptsetup
서비스가 파티션을 마운트하지 못합니다. 결과적으로 두 번째 커널은 LUKS 암호화 대상에서 크래시 덤프 파일(vmcore
)을 캡처하지 못했습니다.
kdumpctl estimate
명령을 사용하면 kdump
에 필요한 권장 메모리 크기인 Recommended crashkernel 값을
쿼리할 수 있습니다.
이 문제를 해결하려면 다음 단계를 사용하여 LUKS 암호화된 대상에서 kdump
에 필요한 메모리를 구성합니다.
크래시커널
추정치를 출력합니다.# kdumpctl estimate
crashkernel
값을 늘려 필요한 메모리 양을 구성합니다.# grubby --args=crashkernel=652M --update-kernel=ALL
변경 사항을 적용하려면 시스템을 재부팅합니다.
# reboot
결과적으로 kdump
는 LUKS 암호화 파티션이 있는 시스템에서 올바르게 작동합니다.
(BZ#2017401)
부팅 시 크래시 커널 메모리 할당 실패
특정 Ampere Altra 시스템에서 사용 가능한 메모리가 1GB 미만인 경우 부팅 중에 kdump
사용을 위해 크래시 커널 메모리를 할당할 수 없습니다. 결과적으로 필요한 메모리가 사용 가능한 메모리보다 많을 때
명령이 kdump 서비스를 시작하지 못합니다.
kdump
ctl
해결 방법으로 크기 요구 사항에 맞게 최소240MB로 crashkernel
매개변수의 값을 줄입니다(예: crashkernel=240M
). 결과적으로 kdump
에 대한 크래시 커널 메모리 할당이 Ampere Altra 시스템에서 실패하지 않습니다.
kTLS는 TLS 1.3을 NIC로 오프로드하는 것을 지원하지 않습니다.
kTLS(커널 전송 계층 보안)는 TLS 1.3을 NIC로 오프로드하는 것을 지원하지 않습니다. 결과적으로 NIC가 TLS 오프로드를 지원하는 경우에도 소프트웨어 암호화가 TLS 1.3과 함께 사용됩니다. 이 문제를 해결하려면 오프로드가 필요한 경우 TLS 1.3을 비활성화합니다. 따라서 TLS 1.2만 오프로드할 수 있습니다. TLS 1.3을 사용하면 TLS 1.3을 오프로드할 수 없기 때문에 성능이 저하됩니다.
(BZ#2000616)
Secure Boot를 사용하여 FADump를 활성화하면 GRUB Out of Memory (OOM)가 발생할 수 있습니다.
Secure Boot 환경에서 GRUB 및 PowerVM은 함께 부팅 메모리용 512MB 메모리 리전(RMA)을 할당합니다. 리전은 부팅 구성 요소 간에 분할되며 구성 요소가 할당을 초과하면 메모리 부족 오류가 발생합니다.
일반적으로 설치된 기본 initramfs
파일 시스템과 vmlinux
기호 테이블은 이러한 오류를 방지하기 위한 제한 내에 있습니다. 그러나 시스템에서 Firmware Assisted Dump(FADump)가 활성화된 경우 기본 initramfs
크기가95MB를 늘리고 초과할 수 있습니다. 결과적으로 모든 시스템을 재부팅하면 GRUB OOM 상태가 됩니다.
이 문제를 방지하려면 Secure Boot 및 FADump를 함께 사용하지 마십시오. 이 문제를 해결하는 방법에 대한 자세한 내용과 방법은 link:https://www.ibm.com/support/pages/node/6846531를 참조하십시오.
(BZ#2149172)
Secure Boot의 시스템은 동적 LPAR 작업을 실행할 수 없습니다.
HMC(Hardware Management Console)에서 이러한 조건 중 하나가 충족되면 사용자가 동적 논리 파티션(DLPAR) 작업을 실행할 수 없습니다.
-
무결성 모드에서 커널
잠금
메커니즘을 암시적으로 활성화하는 Secure Boot 기능이 활성화됩니다. -
커널
잠금
메커니즘은 무결성 또는 기밀성 모드에서 수동으로 활성화됩니다.
RHEL 9에서 커널 잠금
은 /dev/mem
문자 장치 파일을 통해 액세스할 수 있는 시스템 메모리에 대한 RTAS(Run Time Abstraction Services) 액세스를 완전히 차단합니다. 여러 RTAS 호출이 제대로 작동하려면 /dev/mem
에 대한 쓰기 액세스가 필요합니다. 결과적으로 RTAS 호출이 올바르게 실행되지 않고 사용자에게 다음과 같은 오류 메시지가 표시됩니다.
HSCL2957 Either there is currently no RMC connection between the management console and the partition <LPAR name> or the partition does not support dynamic partitioning operations. Verify the network setup on the management console and the partition and ensure that any firewall authentication between the management console and the partition has occurred. Run the management console diagrmc command to identify problems that might be causing no RMC connection.
(BZ#2083106)
dkms
는 64비트 ARM CPU에서 올바르게 컴파일된 드라이버를 사용하여 프로그램 오류에 대한 잘못된 경고를 제공합니다.
동적 커널 모듈 지원(dkms
) 유틸리티는 64비트 ARM CPU의 커널 헤더가 4 킬로바이트 및 64 킬로바이트 페이지 크기가 있는 커널 모두에서 작동하는지 인식하지 못합니다. 결과적으로 커널 업데이트가 수행되고 kernel-64k-devel
패키지가 설치되지 않은 경우 dkms
는 프로그램이 올바르게 컴파일된 드라이버에서 실패한 이유에 대한 잘못된 경고를 제공합니다. 이 문제를 해결하려면 두 가지 유형의 ARM CPU 아키텍처에 대한 헤더 파일이 포함된 kernel-headers
패키지를 설치하고 dkms
및 해당 요구 사항에 국한되지 않습니다.
(JIRA:RHEL-25967)