Red Hat Summit10장. 확인된 문제
이 Red Hat Enterprise Linux 10.0 버전은 새로 확인된 다음과 같은 알려진 문제의 영향을 받습니다. 알려진 문제는 해결 될 때까지 모든 향후 릴리스 노트에 나열되며,이 시점에서 해결된 문제로 게시됩니다. 이 섹션에 나열되지 않은 문제가 발생하면 이 페이지의 오른쪽 상단에 있는 버튼을 사용하여 보고하십시오.
10.1. 설치 프로그램 및 이미지 생성
서명된 컨테이너에서 ISO를 빌드할 수 없음
GPG 또는 간단한 서명된 컨테이너에서 ISO 디스크 이미지를 빌드하려고 하면 다음과 유사한 오류가 발생합니다.
manifest - failed Failed Error: cannot run osbuild: running osbuild failed: exit status 1 2024/04/23 10:56:48 error: cannot run osbuild: running osbuild failed: exit status 1
manifest - failed
Failed
Error: cannot run osbuild: running osbuild failed: exit status 1
2024/04/23 10:56:48 error: cannot run osbuild: running osbuild failed: exit status 1이는 시스템이 이미지 소스 서명을 가져오지 못하기 때문에 발생합니다.
해결방법: 컨테이너 이미지에서 서명을 제거하거나 파생된 컨테이너 이미지를 빌드할 수 있습니다. 예를 들어 서명을 제거하려면 다음 명령을 실행합니다.
sudo skopeo copy --remove-signatures containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.4 containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.4
sudo podman run \
--rm \
-it \
--privileged \
--pull=newer \
--security-opt label=type:unconfined_t \
-v /var/lib/containers/storage:/var/lib/containers/storage \
-v ~/images/iso:/output \
quay.io/centos-bootc/bootc-image-builder \
--type iso --local \
registry.redhat.io/rhel9/rhel-bootc:9.4
$ sudo skopeo copy --remove-signatures containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.4 containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.4
$ sudo podman run \
--rm \
-it \
--privileged \
--pull=newer \
--security-opt label=type:unconfined_t \
-v /var/lib/containers/storage:/var/lib/containers/storage \
-v ~/images/iso:/output \
quay.io/centos-bootc/bootc-image-builder \
--type iso --local \
registry.redhat.io/rhel9/rhel-bootc:9.4파생 컨테이너 이미지를 빌드하고 간단한 GPG 서명을 추가하지 않으려면 서명 컨테이너 이미지 제품 설명서를 참조하십시오.
부팅 옵션의 암호화된 DNS 및 사용자 정의 CA로 호스트 이름 확인 실패
원격 설치 URL, 암호화된 DNS 및 Kickstart 파일에서 사용자 정의 CA 인증서와 함께 커널 명령줄의 inst.repo= 또는 inst.stage2= 부팅 옵션을 사용하는 동안 설치 프로그램은 Kickstart 파일을 처리하기 전에 install.img stage2 이미지를 다운로드하려고 합니다. 결과적으로 호스트 이름 확인이 실패하여 stage2 이미지를 가져오기 전에 일부 오류가 표시됩니다. 해결방법: 커널 명령줄 대신 Kickstart 파일에 설치 소스를 정의합니다.
최종 RPM 설치 단계에서 설치 프로그램이 응답하지 않음
최종 단계에서 RPM 설치 프로세스 중에 설치 프로그램이 응답하지 않을 수 있습니다. 문제가 발생하기 전에 반복된 rootfiles.noarch 메시지 구성이 표시될 수 있습니다. 해결방법: 설치 프로세스를 다시 시작합니다.
Jira:RHEL-67865[1]
설치 중에 바로 가기를 사용하여 키보드 레이아웃 전환 비활성화
키보드 레이아웃을 변경하기 위해 중단된 키보드 바로 가기로 인한 혼동을 방지하기 위해 Anaconda에서 이 기능이 비활성화되었습니다. 설치 중에 바로 가기를 사용하여 키보드 레이아웃을 변경할 수 없습니다. 해결방법: 상단 표시줄의 키보드 레이아웃 아이콘을 사용하여 레이아웃을 전환합니다.
LACP를 사용하는 본딩 장치가 작동하는 데 시간이 오래 걸리므로 서브스크립션 오류가 발생합니다.
커널 명령줄 부팅 옵션과 Kickstart 파일을 모두 사용하여 LACP로 본딩 장치를 구성할 때 initramfs 단계에서 연결이 생성되지만 Anaconda에서 다시 활성화됩니다. 결과적으로 rhsm Kickstart 명령을 통해 시스템 서브스크립션 실패로 인한 일시적인 중단이 발생합니다.
해결방법: 네트워크 작동을 유지하기 위해 Kickstart 네트워크 구성에 --no-activate 를 추가합니다. 결과적으로 시스템 서브스크립션이 성공적으로 완료됩니다.
Jira:RHELDOCS-19853[1]
services Kickstart 명령이 firewalld 서비스를 비활성화하지 못합니다.
Anaconda의 버그로 인해 --disabled=firewalld 명령이 Kickstart에서 firewalld 서비스를 비활성화하지 못하도록 합니다. 해결방법: 대신 firewall --disabled 명령을 사용합니다. 결과적으로 firewalld 서비스가 올바르게 비활성화됩니다.
ostreecontainer를 사용할 때 /boot 파티션이 생성되지 않은 경우 설치 프로그램이 실패합니다.
ostreecontainer Kickstart 명령을 사용하여 부팅 가능한 컨테이너를 설치할 때 /boot 파티션이 생성되지 않으면 설치에 실패합니다. 이 문제는 설치 프로그램에 컨테이너 배포를 진행하기 위해 전용 /boot 파티션이 필요하기 때문에 발생합니다.
해결방법: /boot 파티션이 Kickstart 파일에 정의되어 있거나 설치 프로세스 중에 수동으로 생성되도록 합니다.
'ignoredisk' 명령이 'iscsi' 명령 앞에 있을 때 알 수 없는 디스크 오류와 함께 Kickstart 설치에 실패합니다.
ignoredisk 명령이 iscsi 명령 앞에 배치되면 kickstart 방법을 사용하여 RHEL을 설치할 수 없습니다. 이 문제는 iscsi 명령이 명령 구문 분석 중에 지정된 iSCSI 장치를 연결하는 반면 ignoredisk 명령은 장치 사양을 동시에 확인하기 때문에 발생합니다. iscsi 명령으로 연결하기 전에 ignoredisk 명령이 iSCSI 장치 이름을 참조하는 경우 "알 수 없는 디스크" 오류와 함께 설치에 실패합니다.
해결방법: iscsi 명령이 Kickstart 파일의 ignoredisk 명령 앞에 iSCSI 디스크를 참조하고 성공적으로 설치되었는지 확인합니다.
Anaconda에서 USB CD-ROM 드라이브를 설치 소스로 사용할 수 없습니다.
USB CD-ROM 드라이브가 소스이고 Kickstart ignoredisk --only-use= 명령이 지정되면 설치에 실패합니다. 이 경우 Anaconda에서 이 소스 디스크를 찾아서 사용할 수 없습니다.
해결방법: harddrive --partition=sdX --dir=/ 명령을 사용하여 USB CD-ROM 드라이브에서 설치합니다. 이로 인해 설치에 실패하지 않습니다.
드라이버 디스크 메뉴가 콘솔에 사용자 입력을 표시하지 못했습니다
드라이버 디스크와 함께 커널 명령행에서 inst.dd 옵션을 사용하여 RHEL 설치를 시작하면 콘솔에 사용자 입력이 표시되지 않습니다. 결과적으로 애플리케이션이 사용자 입력에 응답하지 않고 응답을 중지하지만 사용자에게 혼동되는 출력이 표시됩니다. 그러나 이 동작은 기능에 영향을 미치지 않으며 Enter 를 누른 후 사용자 입력이 등록됩니다.
해결방법: 예상되는 결과를 보려면 콘솔에 사용자 입력이 없는 것을 무시하고 입력 추가 완료 시 Enter 키를 누릅니다.
s390x 및 ppc64le 아키텍처에서 Anaconda가 제대로 작동하지 않을 수 있습니다
RHEL의 이미지 모드는 이미 지원되는 x86_64 및 ARM 아키텍처 외에도 pp64le 및 s390x 아키텍처를 지원합니다. 그러나 Anaconda는 s390x 및 ppc64le 아키텍처에서 올바르게 작동하지 않을 수 있습니다.
Jira:RHELDOCS-19496[1]
Anaconda 설치 프로그램이 복구 모드에서 응답하지 않는 것으로 나타납니다.
복구 모드로 부팅하고 쉘 옵션으로 선택할 때 Anaconda 설치 프로그램이 고정되는 것처럼 보이는 문제가 발생할 수 있습니다. 눈에 보이는 응답의 부족에도 불구하고 설치 프로그램은 여전히 작동하고 입력에 반응합니다. 그러나 프롬프트가 화면에 표시되지 않아 혼동이 발생합니다.
Continue 또는 Skip을
눈에 보이는 프롬프트가 없는 경우에도 설치 프로그램이 계속 작동하므로 작업을 정상적으로 계속 진행합니다.
Jira:RHEL-58834[1]
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}