RHEL 9 to 10 leapp upgrade

이 문서는 Red Hat Enterprise Linux (RHEL) 9 시스템을 RHEL 10으로 인플레이스(in-place) 업그레이드하는 과정을 요약합니다. Leapp 유틸리티를 사용한 업그레이드 절차, 준비 사항, 실행, 후속 조치 및 문제 해결 방법을 다룹니다.

Leapp 유틸리티는 RHEL 9에서 RHEL 10으로의 인플레이스 업그레이드를 지원합니다. 이 과정은 기존 시스템의 애플리케이션, 데이터, 구성을 유지하면서 운영 체제를 업그레이드하는 것을 목표로 합니다.

계획 및 준비: 업그레이드 경로 확인, 시스템 백업, 필수 리포지토리 설정.

사전 업그레이드 평가: leapp preupgrade 명령을 사용하여 잠재적 문제 식별 및 해결.

업그레이드 실행: leapp upgrade 명령을 사용하여 실제 업그레이드 수행.

업그레이드 후 작업: 시스템 상태 확인, 불필요한 패키지 정리, 보안 설정 복원.

지원되는 아키텍처: 64비트 Intel, 64비트 ARM, IBM Power (little endian), IBM Z. [1]

부트로더: GRUB2만 지원. [1]

백업: 업그레이드 전 전체 시스템 백업은 필수입니다. ReaR(Relax-and-Recover) 사용 권장. [1]

디스크 공간: /boot 파티션 최소 250MB, 루트 파일 시스템 및 기타 Leapp 관련 디렉터리(예: var/lib/leapp)에 충분한 공간 확보. [1]

미지원 구성: NetworkManager를 사용하지 않는 네트워크 구성, 타사 패키지 충돌, 특정 커널 모듈 등은 문제가 될 수 있습니다. [1]

성공적인 업그레이드를 위해서는 철저한 계획이 필요합니다.

특정 RHEL 9 부 버전에서 특정 RHEL 10 부 버전으로의 업그레이드 경로를 확인해야 합니다 (예: RHEL 9.6에서 RHEL 10.0). [1]

Extended Update Support (EUS) 또는 Advanced Update Support (AUS) 서브스크립션을 사용하는 경우, 해당 조건에 맞는 경로를 따라야 합니다. [1]

디스크 공간:

boot 파티션: 최소 250MB의 여유 공간.

var/lib/leapp 디렉터리: 최소 4GB (최대 8GB 권장).

루트 파일 시스템: 최소 4GB의 여유 공간.

메모리: 최소 1GB RAM.

애플리케이션 호환성: 업그레이드 후 애플리케이션이 RHEL 10과 호환되는지 사전에 확인해야 합니다. 특히 RHEL 10에서 제거되거나 변경된 패키지에 의존하는 애플리케이션을 검토합니다.

커널 모듈: 사용자 정의 또는 타사 커널 모듈은 RHEL 10 커널과 호환되지 않을 수 있습니다.

보안 소프트웨어: 안티바이러스 소프트웨어는 업그레이드 과정에서 일시적으로 비활성화하는 것이 좋습니다. [1]

업그레이드 프로세스를 시작하기 전에 시스템을 적절히 준비해야 합니다.

전체 시스템 백업: ReaR 유틸리티 또는 VM 스냅샷을 사용하여 시스템을 백업합니다. [1]

Red Hat 서브스크립션 확인: 유효한 Red Hat 서브스크립션이 필요합니다.
# subscription-manager status
출력에서 “Content Access Mode is set to Simple Content Access”를 확인합니다.

필수 리포지토리 활성화: BaseOS 및 AppStream 리포지토리를 활성화합니다. 64비트 Intel 아키텍처의 예는 다음과 같습니다. 다른 아키텍처는 관련 문서를 참조하십시오.
# subscription-manager repos –enable rhel-9-for-x86_64-baseos-rpms –enable rhel-9-for-x86_64-appstream-rpms
CodeReady Linux Builder (Optional) 또는 Supplementary 리포지토리 활성화도 고려할 수 있습니다.

시스템 릴리스 버전 설정: 업그레이드할 소스 RHEL 9 마이너 버전으로 설정합니다 (예: 9.6).
# subscription-manager release –set 9.6
이 단계는 시스템이 정확한 패키지 세트를 기준으로 업그레이드를 시작하도록 보장하여, 버전 불일치로 인한 문제를 방지합니다.

DNF 버전 잠금 해제: dnf versionlock 플러그인을 사용하여 특정 버전으로 패키지를 잠근 경우, 이를 해제합니다.
# dnf versionlock clear

최신 Leapp 패키지 확인: 최신 leapp 및 leapp-repository 패키지(RHEL 9.6의 경우 leapp 0.19.0, leapp-repository 0.22.0 이상)가 있는지 확인합니다. leapp-repository 패키지에는 leapp-upgrade-el9toel10 RPM이 포함됩니다.
연결되지 않은 시스템의 경우, Red Hat 고객 포털에서 leapp, leapp-deps, python3-leapp, leapp-upgrade-el9toel10, leapp-upgrade-el9toel10-deps 패키지를 다운로드해야 합니다.

Leapp 유틸리티 설치:
# dnf install leapp-upgrade

시스템 전체 업데이트 및 재부팅: 모든 패키지를 최신 RHEL 9 버전으로 업데이트하고 시스템을 재부팅합니다.
# dnf update
# reboot
이는 시스템이 가장 안정적인 최신 상태에서 업그레이드를 시작하도록 합니다.

rpmnew 및 rpmsave 파일 검토 (선택 사항): 생성된 rpmnew 및 rpmsave 파일을 검토, 수정 후 제거합니다.

구성 관리 시스템 비활성화: Puppet, Salt, Chef, Ansible 등의 구성 관리 시스템이 업그레이드 프로세스를 방해하지 않도록 leapp preupgrade 명령 실행 전에 비활성화하고, 업그레이드 완료 후 다시 활성화합니다. 구성 관리 시스템을 사용한 사전 업그레이드 및 업그레이드 프로세스 자동화는 Red Hat에서 지원하지 않습니다.

ISO 이미지 사용 시 확인: ISO 이미지를 사용하여 업그레이드하는 경우, ISO 이미지에 대상 OS 버전(예: RHEL 10.0)이 포함되어 있고, Leapp 유틸리티가 업그레이드 과정 전체에서 접근할 수 있도록 영구 로컬 마운트 지점에 저장되었는지 확인합니다.

Satellite에 등록된 시스템을 RHEL 10으로 인플레이스 업그레이드하기 전에, Satellite 서버에서 다음 준비 단계를 수행해야 합니다.[1] 이 절차와 “3.1. 업그레이드를 위한 RHEL 9 시스템 준비”에 설명된 단계를 모두 완료해야 합니다.

사전 요구 사항 [1]:

Satellite 서버에 대한 관리자 권한이 있어야 합니다.

Satellite가 전체 또는 유지 관리 지원 버전이어야 합니다.

프로세스 [1]:

서브스크립션 매니페스트 가져오기: RHEL 9 및 RHEL 10 리포지토리가 포함된 서브스크립션 매니페스트를 Satellite 서버로 가져옵니다.

필수 리포지토리 활성화 및 동기화: Satellite 서버에서 필요한 모든 RHEL 9 및 RHEL 10 리포지토리를 활성화하고, 소스 및 대상 OS 버전의 최신 업데이트와 동기화합니다. 필수 리포지토리는 콘텐츠 보기에 포함되고 연결된 활성화 키에서 활성화되어야 합니다.

중요: RHEL 10 리포지토리의 경우, 각 리포지토리의 대상 OS 버전(예: RHEL 10.0)을 활성화해야 합니다. RHEL 10의 일반 버전 리포지토리만 활성화하면 인플레이스 업그레이드가 차단될 수 있습니다.

Intel 아키텍처(EUS 미사용) 예시 (소스 OS 버전 9.6, 대상 OS 버전 10.0):

Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) (rhel-9-for-x86_64-appstream-rpms x86_64 9.6)

Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) (rhel-9-for-x86_64-baseos-rpms x86_64 9.6) (문서에는 RHEL 8로 오타가 있으나, RHEL 9가 맞습니다 [1])

Red Hat Enterprise Linux 10 for x86_64 - AppStream (RPMs) (rhel-10-for-x86_64-appstream-rpms x86_64 10.0) (문서에는 rhel-9-for-x86_64-appstream-rpms x86_64 <target_os_version>로 오타가 있으나, rhel-10이 맞습니다 [1])

Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs) (rhel-10-for-x86_64-baseos-rpms x86_64 10.0) (문서에는 rhel-9-for-x86_64-baseos-rpms x86_64 <target_os_version>로 오타가 있으나, rhel-10이 맞습니다 [1])
정확한 리포지토리 목록과 버전은 부록 A와 B를 참조하십시오.[1] Satellite 환경에서 올바른 리포지토리 설정은 Leapp이 필요한 패키지에 접근하는 데 매우 중요하며, 설정 오류는 업그레이드 실패의 일반적인 원인이 됩니다.

콘텐츠 호스트 연결: 콘텐츠 호스트를 필요한 RHEL 9 및 RHEL 10 리포지토리가 포함된 콘텐츠 뷰에 연결합니다.

검증 [1]:

Satellite 웹 UI 또는 hammer CLI 명령을 사용하여 올바른 RHEL 9 및 RHEL 10 리포지토리가 올바른 콘텐츠 뷰에 추가되었는지 확인합니다.
# hammer repository list –search 'content_label ~ rhel-9' –content-view <content_view_name> –organization –lifecycle-environment <lifecycle_environment>
# hammer repository list –search 'content_label ~ rhel-10' –content-view <content_view_name> –organization –lifecycle-environment <lifecycle_environment>

콘텐츠 뷰와 연결된 활성화 키에 올바른 RHEL 10 리포지토리가 활성화되었는지 확인합니다 (Satellite 웹 UI > Content > Lifecycle > Activation Keys).

호스트에서 예상되는 모든 RHEL 9 리포지토리가 활성화되었는지 확인합니다.
# subscription-manager repos –list-enabled | grep “^Repo ID”

시스템의 업그레이드 가능성을 평가하기 위해 leapp preupgrade 명령을 사용하여 사전 업그레이드 프로세스를 시작합니다.[1] 이 단계에서 Leapp 유틸리티는 시스템 데이터를 수집하고, 업그레이드 가능성을 평가하며, 업그레이드 전 보고서를 생성합니다. 이 보고서는 잠재적 문제를 요약하고 권장 해결책을 제시하여 업그레이드 진행 여부 결정에 도움을 줍니다.

중요 사항 [1]:

사전 평가는 시스템 구성을 변경하지 않지만, var/lib/leapp 디렉터리에 상당한 공간(최대 4GB 이상)을 사용합니다. 공간 부족 시 보고서가 불완전할 수 있으므로 충분한 공간을 확보하거나 해당 디렉터리를 별도 파티션으로 이동하는 것이 좋습니다.

보고서에 업그레이드 차단 요소(inhibitor)가 없더라도 전체 보고서를 검토해야 합니다. 여기에는 업그레이드된 시스템이 올바르게 작동하도록 하기 위해 업그레이드 전에 완료해야 할 권장 조치가 포함되어 있습니다.

사전 보고서는 전체 업그레이드 프로세스를 시뮬레이션하는 것이 아니므로, 모든 잠재적 문제를 식별하지 못할 수 있습니다 (예: 손상된 패키지 다운로드 문제).

명령줄을 사용하여 사전 업그레이드 단계에서 잠재적인 업그레이드 문제를 식별합니다.[1]

사전 요구 사항 [1]:

“3장. 업그레이드 준비” 단계가 완료되어야 합니다.

제한되지 않은 SELinux 역할(unconfined_r)로 root에 로그인해야 합니다. sudo 사용 시 sudo -r unconfined_r -t unconfined_t leapp preupgrade와 같이 실행합니다.

프로세스 [1]:

RHEL 9 시스템에서 사전 업그레이드 단계를 수행합니다:
# leapp preupgrade –target <target_os_version>
<target_os_version>을 대상 OS 버전(예: 10.0)으로 대체합니다. 지정하지 않으면 지원되는 기본 대상 버전이 사용됩니다 (표 1.1 참조 [1]).

사용자 지정 리포지토리: etc/yum.repos.d 디렉터리의 사용자 지정 리포지토리를 사용하려면 –enablerepo <repository_id1> –enablerepo <repository_id2>… 옵션으로 활성화합니다.

RHSM 미사용/RHUI 사용: –no-rhsm 옵션을 추가합니다.

EUS/AUS 서브스크립션: –channel <channel_name> (예: eus, aus) 옵션을 추가합니다.

RHEL for Real Time/NFV: 관련 리포지토리를 –enablerepo 옵션으로 활성화합니다 (예: # leapp preupgrade –enablerepo rhel-10-for-x86_64-rt-rpms).

var/log/leapp/leapp-report.txt 파일의 보고서를 검토하고 보고된 모든 문제를 수동으로 해결합니다. 보고서에는 다음과 같은 위험 요소 수준이 포함됩니다:

높음 (High): 시스템 상태 악화 가능성이 매우 높음.

중간 (Medium): 시스템 및 애플리케이션에 영향 가능.

낮음 (Low): 시스템에는 영향 없으나 애플리케이션에 영향 가능.

정보 (Info): 정보 제공, 시스템/애플리케이션 영향 없음.
차단 요소(Inhibitor)로 표시된 문제는 해결 전까지 업그레이드를 진행할 수 없습니다.

Leapp 유틸리티가 수동 답변을 요구하는 질문을 생성한 경우 (보고서에 “Missing required answers in the answer file” 메시지 확인):

var/log/leapp/answerfile 파일을 열어 질문을 검토합니다.

파일을 수동으로 편집하여 confirm 줄의 주석(#)을 제거하고 답변을 True 또는 False로 입력합니다.
또는 다음 명령으로 답변할 수 있습니다:
# leapp answer –section <question_section>.<field_name>=
이 answerfile은 Leapp이 특정 시스템 구성에 대해 사용자의 확인을 받아야 할 때 사용되며, 답변 없이는 업그레이드가 진행되지 않으므로 주의 깊게 확인하고 응답해야 합니다.

이전 단계를 반복하여 사전 업그레이드 보고서를 다시 실행하고 모든 중요 문제가 해결되었는지 확인합니다.

웹 콘솔(Cockpit)의 cockpit-leapp 플러그인을 사용하여 사전 업그레이드 단계에서 문제를 식별하고 자동 수정을 적용할 수 있습니다.[1]

사전 요구 사항 [1]:

“3장. 업그레이드 준비” 단계가 완료되어야 합니다.

제한되지 않은 SELinux 역할로 root에 로그인해야 합니다.

프로세스 [1]:

cockpit-leapp 플러그인을 설치합니다:
# dnf install cockpit-leapp

웹 콘솔에 root 또는 sudo 권한이 있는 사용자로 로그인합니다.

RHEL 9 시스템에서 명령줄 또는 웹 콘솔 터미널을 통해 사전 업그레이드 단계를 수행합니다 (4.1절의 leapp preupgrade 명령어 및 옵션과 동일).

웹 콘솔 탐색 메뉴에서 Upgrade Report를 선택하여 보고된 모든 문제를 검토합니다. 차단 문제는 해결 전까지 업그레이드를 막습니다. 문제의 상세 내용을 보려면 해당 행을 선택합니다.

“Missing required answers in the answer file” 항목이 있는 경우:

해당 행을 선택하여 세부 정보 창을 엽니다. 기본 답변은 수정 명령 끝에 표시됩니다.

기본 답변을 확인하려면 Add to Remediation Plan (나중에 실행) 또는 Run Remediation (즉시 실행)을 선택합니다.

다른 답변을 선택하려면 터미널에서 leapp answer –section <question_section>.<field_name>= 명령을 실행합니다.

일부 문제에는 자동 해결을 위한 수정 명령이 제공됩니다.

단일 수정 명령 실행: 문제의 세부 정보 창에서 Run Remediation 클릭.

수정 계획에 추가: 문제의 세부 정보 창에서 Add to Remediation Plan 클릭.

전체 수정 계획 실행: 보고서 오른쪽 상단의 Remediation plan 링크를 클릭한 후 Execute Remediation Plan을 클릭하여 추가된 모든 명령을 실행합니다.
웹 콘솔을 사용하면 보고서 내용을 시각적으로 확인하고, 가능한 경우 자동화된 해결책을 바로 적용할 수 있어 복잡한 문제 해결 과정을 단순화할 수 있습니다.

보고서 검토 및 모든 문제 해결 후, 3-7단계를 반복하여 보고서를 다시 실행하고 모든 중요 문제가 해결되었는지 확인합니다.

준비 단계를 완료하고 업그레이드 전 보고서에서 발견된 문제를 모두 검토하고 해결한 후, 시스템에서 실제 인플레이스 업그레이드를 수행할 수 있습니다.[1]

Leapp 유틸리티를 사용하여 RHEL 9에서 RHEL 10으로 업그레이드를 수행하는 절차는 다음과 같습니다.[1]

사전 요구 사항 [1]:

“3장. 업그레이드 준비” 단계(시스템 전체 백업 포함)가 완료되어야 합니다.

“4장. 업그레이드 전 보고서 검토” 단계가 완료되고 보고된 모든 문제가 해결되어야 합니다.

업그레이드 실패를 방지하기 위해 안티바이러스 소프트웨어를 일시적으로 비활성화해야 합니다.

프로세스 [1]:

시스템 백업 확인: 시스템 전체 백업 또는 가상 머신 스냅샷이 있는지 다시 한번 확인합니다. 재해 복구 절차를 통해 업그레이드 전 상태로 시스템을 복구할 수 있어야 합니다.

Relax-and-Recover (ReaR) 유틸리티 사용.

LVM 스냅샷 또는 RAID 분할 사용 (VM의 경우 전체 VM 스냅샷). Boom 유틸리티로 스냅샷 및 롤백 부팅 항목 관리 가능.
LVM 스냅샷만으로는 특정 업그레이드 실패 시 시스템 복구가 불가능할 수 있으므로, ReaR을 사용한 전체 백업이 더 안전한 방법입니다. 이 단계는 업그레이드 중 예기치 않은 심각한 문제가 발생했을 때 시스템을 이전 상태로 되돌릴 수 있는 유일한 방법이므로 매우 중요합니다.

RHEL 9 시스템에서 업그레이드 프로세스를 시작합니다:
# leapp upgrade –target <target_os_version>
<target_os_version>을 대상 OS 버전(예: 10.0)으로 대체합니다. 옵션은 leapp preupgrade와 유사합니다:

사용자 지정 리포지토리: –enablerepo <repository_id1>…

RHSM 미사용/RHUI 사용: –no-rhsm

ISO 이미지 사용: –no-rhsm –iso <file_path> (예: home/rhel9.iso)

EUS/AUS 서브스크립션: –channel <channel_name> (leapp preupgrade 시 사용한 값과 동일해야 함)

RHEL for Real Time/NFV: –enablerepo rhel-10-for-x86_64-rt-rpms

업그레이드 프로세스 시작 시, Leapp은 “4장. 업그레이드 전 보고서 검토”에 설명된 사전 업그레이드 단계를 다시 수행합니다.

시스템이 업그레이드 가능하면, Leapp은 필요한 데이터를 다운로드하고 업그레이드를 위한 RPM 트랜잭션을 준비합니다.

시스템이 안정적인 업그레이드 매개변수를 충족하지 못하면, Leapp은 업그레이드 프로세스를 종료하고 var/log/leapp/leapp-report.txt 파일에 문제 설명과 권장 해결책을 제공합니다.

시스템 수동 재부팅:
# reboot
이 단계에서 시스템은 RHEL 10 기반 초기 RAM 디스크 이미지(initramfs)로 부팅됩니다. Leapp은 모든 패키지를 업그레이드하고 RHEL 10 시스템으로 자동 재부팅합니다.
또는, leapp upgrade 명령에 –reboot 옵션을 추가하여 이 수동 단계를 생략할 수 있습니다.
실패 발생 시, “9장. 문제 해결”에 설명된 대로 로그 및 알려진 문제를 조사합니다.

RHEL 10 시스템에 로그인하고 “6장. 업그레이드 후 상태 확인”에 설명된 대로 상태를 확인합니다.

업그레이드 보고서 및 “7장. RHEL 10 시스템에서 업그레이드 후 작업 수행”에 설명된 모든 업그레이드 후 작업을 수행합니다.

RHEL 10으로 인플레이스 업그레이드를 수행한 후, 시스템이 올바른 상태인지 확인해야 합니다.[1] 이를 통해 시스템에 영향을 미칠 수 있는 중요한 오류를 식별하고 수정할 수 있습니다.

다음은 RHEL 10으로 인플레이스 업그레이드 후 권장되는 확인 절차입니다.[1]

사전 요구 사항 [1]:

“5장. 업그레이드 수행”에 설명된 단계에 따라 시스템이 업그레이드되었고 RHEL 10에 로그인할 수 있어야 합니다.

프로세스 [1]:
업그레이드가 완료되면 시스템이 필요한 상태인지 최소한 다음 사항을 확인합니다:

현재 OS 버전 확인:
# cat /etc/redhat-release
예상 출력: Red Hat Enterprise Linux release 10.0 (Coughlan) (또는 해당하는 RHEL 10.x 버전)

OS 커널 버전 확인:
# uname -r
예상 출력 예시: 6.12.0-55.2.1.el10.x86_64. 여기서 .el10이 중요하며, 버전이 너무 낮지 않은지 확인합니다 (예: 6.12.0 이상).
커널 버전 확인은 시스템이 실제로 새로운 RHEL 10 커널로 부팅되었는지 확인하는 중요한 단계입니다. 이전 버전 커널로 부팅되었다면 업그레이드가 불완전하거나 부팅 설정에 문제가 있을 수 있습니다.

Red Hat Subscription Manager 사용 시:

설치된 제품 확인:
# subscription-manager list –installed
출력에서 “Product Name: Red Hat Enterprise Linux for x86_64”, “Version: 10.0”, “Status: Subscribed” 등을 확인합니다.

릴리스 버전 확인: 업그레이드 직후 릴리스 버전이 예상 대상 OS 버전으로 설정되었는지 확인합니다.
# subscription-manager release
예상 출력: Release: 10.0

네트워크 서비스 작동 확인: 예를 들어, SSH를 사용하여 서버에 연결을 시도합니다.

애플리케이션 업그레이드 후 상태 확인: 경우에 따라 수동으로 마이그레이션 및 구성 변경을 수행해야 할 수 있습니다. 예를 들어, 데이터베이스 마이그레이션은 관련 문서 지침을 따릅니다.

이러한 확인 과정을 통해 업그레이드가 성공적으로 완료되었는지, 시스템의 핵심 기능들이 정상적으로 작동하는지를 점검할 수 있습니다.

인플레이스 업그레이드 후, 불필요한 패키지를 제거하고, 호환되지 않는 리포지토리를 비활성화하며, 복구 커널 및 초기 RAM 디스크를 업데이트하여 RHEL 10 시스템을 정리해야 합니다.[1] 이러한 후속 조치는 시스템을 최적화하고 안정성을 확보하는 데 중요합니다.

다음은 RHEL 10으로 인플레이스 업그레이드 후 권장되는 주요 작업 목록입니다.[1]

사전 요구 사항 [1]:

“5장. 업그레이드 수행”에 따라 시스템이 업그레이드되었고 RHEL 10에 로그인할 수 있어야 합니다.

“6장. 업그레이드 후 상태 확인”에 따라 인플레이스 업그레이드 상태가 확인되어야 합니다.

프로세스 [1]:

Leapp 관련 패키지 제외 목록에서 제거: etc/dnf/dnf.conf 구성 파일의 exclude 목록에서 snactor 패키지를 포함한 나머지 Leapp 관련 패키지를 제거합니다. 업그레이드 중에는 중요한 파일이 제거되거나 업데이트되는 것을 방지하기 위해 Leapp 패키지가 자동으로 이 목록에 추가됩니다.

수동 제거: etc/dnf/dnf.conf 파일을 편집하여 해당 Leapp 패키지를 exclude 목록에서 제거합니다.

모든 패키지 제외 목록에서 제거:
# dnf config-manager –save –setopt exclude=“”

남아있는 RHEL 9 패키지 제거:

남아있는 RHEL 9 패키지 찾기:
# rpm -qa | grep -e '.el' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
(문서에는 \.el로 되어 있으나, RHEL 9에서 업그레이드했으므로 \.el9 또는 더 넓게 \.el를 사용할 수 있습니다. 여기서는 문서대로 표기합니다.)

RHEL 10 시스템에서 나머지 RHEL 9 패키지 제거 (DNF 사용 권장):
# dnf remove $(rpm -qa | grep '.el' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)')
이 명령은 이전 버전의 잔여 패키지를 정리하여 시스템을 깨끗하게 유지하고 잠재적인 충돌을 방지합니다.

나머지 Leapp 종속성 패키지 제거:
# dnf remove leapp-deps-el10 leapp-repository-deps-el10

업그레이드 관련 데이터 제거 (선택 사항):
# rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp
(문서에는 var/log/leapp/root/tmp_leapp_py3/var/lib/leapp로 되어있으나, 일반적으로 var/log/leapp 전체와 var/lib/leapp을 의미할 수 있습니다. 여기서는 문서 경로를 따르되, var/log/leapp도 포함하는 것이 일반적입니다.)
중요: 이 데이터를 제거하면 Red Hat 지원팀이 업그레이드 후 문제를 조사하고 해결하는 데 제한이 있을 수 있습니다.

RHEL 10과 호환되지 않는 DNF 리포지토리 비활성화: RHSM으로 관리되는 리포지토리는 자동으로 처리됩니다.
# dnf config-manager –set-disabled <repository_id>

복구 커널 및 초기 RAM 디스크 업데이트: 이전 복구 커널 및 initramfs를 현재 커널 및 디스크로 교체합니다.

기존 복구 커널 및 initramfs 제거:
# rm /boot/vmlinuz-rescue /boot/initramfs-rescue.img
(문서에는 boot/initramfs-*rescue*로 되어있으나, 일반적으로 .img 확장자가 붙습니다.)

새 복구 커널 및 initramfs 재설치:
# /usr/lib/kernel/install.d/51-dracut-rescue.install add “(uname−r)”“”/boot/vmlinuz−(uname -r)
(문서에는 “/boot” “/boot/vmlinuz-$(uname -r)” 인수가 있으나, install.d 스크립트는 보통 커널 버전만 받거나, 부트 경로를 생략할 수 있습니다. 여기서는 문서의 인수 구조를 따르되, 실제 사용 시 확인이 필요할 수 있습니다.)

IBM Z 아키텍처인 경우 zipl 부트 로더 업데이트:
# zipl
이 작업은 시스템 장애 시 복구 환경이 최신 상태를 반영하도록 보장합니다.

기존 구성 파일 확인 (선택 사항):

rpmnew, rpmsave, leappsave 파일을 검토, 수정 후 제거합니다.

더 이상 유효하지 않은 etc/dnf/modules.d 디렉터리의 RHEL 9 DNF 모듈 구성 파일을 제거합니다.

보안 정책 재평가 및 재적용: 특히 SELinux 모드를 enforcing으로 변경합니다 (8장 참조).

검증 [1]:

이전에 제거된 복구 커널 및 initramfs 파일이 현재 커널용으로 생성되었는지 확인:
# ls /boot/vmlinuz-rescue /boot/initramfs-rescue.img
# lsinitrd /boot/initramfs-(uname−r)−rescue.img∣grep−qm1“(uname -r)/kernel/” && echo “OK” || echo “FAIL”
(파일 이름은 시스템에 따라 약간 다를 수 있습니다.)

복구 부팅 항목이 기존 복구 파일을 참조하는지 grubby로 확인:
# grubby –info /boot/vmlinuz-$(uname -r)-rescue
(파일 이름은 시스템에 따라 약간 다를 수 있습니다.)

grubby –info ALL 출력을 검토하여 RHEL 9 부팅 항목이 없는지 확인합니다.

boot/loader/entries 파일에 이전 RHEL 관련 파일이 없는지 확인:
# grep -r “.el9” “/boot/loader/entries/” || echo “Everything seems ok.”

인플레이스 업그레이드 과정에서 SELinux 정책은 permissive 모드로 전환됩니다. 또한, 주요 릴리스 간 보안 프로필 변경이 있을 수 있습니다. 시스템 보안을 복원하려면 SELinux를 다시 enforcing 모드로 전환하고 시스템 전체 암호화 정책을 확인해야 합니다. 특정 보안 프로필을 준수하도록 시스템을 수정하거나, 일부 보안 관련 구성 요소의 사전 업데이트 단계가 필요할 수 있습니다.[1]

Leapp 유틸리티는 업그레이드 중 SELinux 모드를 permissive로 설정합니다. 시스템이 성공적으로 업그레이드되면 SELinux 모드를 수동으로 enforcing으로 변경해야 합니다.[1] 이는 시스템 보안을 원래 상태로 복원하는 중요한 단계입니다.

사전 요구 사항 [1]:

시스템이 업그레이드되었고 “6장. 업그레이드 후 상태 확인”의 검증을 수행했습니다.

프로세스 [1]:

SELinux 거부(denial)가 없는지 확인합니다 (예: ausearch 유틸리티 사용):
# ausearch -m AVC,USER_AVC -ts boot
이는 가장 일반적인 시나리오이며, 모든 가능한 SELinux 거부 확인은 관련 문서를 참조하십시오.

etc/selinux/config 파일을 텍스트 편집기로 엽니다:
# vi /etc/selinux/config

SELINUX=enforcing 옵션을 구성합니다:
SELINUX=enforcing
SELINUXTYPE=targeted (일반적으로 기본값)

변경 사항을 저장하고 시스템을 재시작합니다:
# reboot

검증 [1]:

시스템 재시작 후 getenforce 명령이 Enforcing을 반환하는지 확인합니다:
$ getenforce
Enforcing

시스템 전체 암호화 정책은 TLS, IPSec, SSH, DNSSec, Kerberos 프로토콜을 포함하는 핵심 암호화 하위 시스템을 구성합니다. 인플레이스 업그레이드 프로세스는 RHEL 9에서 사용한 암호화 정책을 보존합니다 (예: RHEL 9에서 DEFAULT 정책을 사용했다면 RHEL 10에서도 DEFAULT 사용). 그러나 RHEL 10 암호화 정책은 더 엄격하고 안전한 기본값을 포함할 수 있으므로, 정책 내용을 확인하는 것이 좋습니다.[1]

현재 정책 확인:
$ update-crypto-policies –show

정책 변경 (예: FUTURE 정책으로 설정):
# update-crypto-policies –set FUTURE
사용자 지정 암호화 정책은 업그레이드 시 유지되지만, 새로운 위협에 대응하기 위해 검토 및 업데이트를 고려해야 합니다.

RHEL 10으로 성공적으로 업그레이드한 후, OpenSCAP 제품군에서 제공하는 자동 수정을 사용하여 시스템을 PCI-DSS, OSPP 등과 같은 보안 기준선에 맞게 강화할 수 있습니다. RHEL 주요 버전 간에는 보안 권장 사항이 다를 수 있으며, Leapp은 강화된 RHEL 9 시스템의 완전한 강화를 직접적으로 유지하지 않을 수 있습니다.[1]

참고/중요 [1]:

RHEL 9와 RHEL 10 스캔에는 동일한 SCAP 콘텐츠를 사용할 수 없습니다.

자동 수정은 기본 구성의 RHEL 시스템을 지원합니다. 업그레이드 후 시스템 구성이 변경되었으므로, 자동 수정 실행만으로 시스템이 필요한 보안 프로필을 완전히 준수하지 못할 수 있으며 수동 수정이 필요할 수 있습니다.

PCI-DSS 프로필 적용 예시 [1]:
사전 요구 사항: scap-security-guide 패키지가 RHEL 10 시스템에 설치되어 있어야 합니다.

적절한 데이터 스트림 .xml 파일 찾기:
$ ls /usr/share/xml/scap/ssg/content/
(예: ssg-rhel10-ds.xml)

선택한 프로필에 따라 시스템 수정:
# oscap xccdf eval –profile <profile_ID> –remediate /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
<profile_ID>를 원하는 프로필 ID로 대체합니다 (예: pci-dss).
주의: –remediate 옵션은 신중하게 사용해야 하며, 시스템을 사용할 수 없게 만들 수 있습니다. Red Hat은 자동 롤백 방법을 제공하지 않습니다.

시스템 재시작:
# reboot
검증: 시스템이 프로필과 호환되는지 확인하고 결과를 HTML 파일로 저장:
$ oscap xccdf eval –report pcidss_report.html –profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

USBGuard는 허용/금지된 USB 장치 목록을 사용하여 시스템을 보호합니다. 업그레이드 전에 생성된 규칙 세트가 있다면, RHEL 10에서 정책을 다시 생성하고 이전 정책과 비교하여 필요한 조정을 수행해야 합니다.[1]

프로세스 [1]:

etc/usbguard 디렉터리의 *.conf 파일 백업.

usbguard generate-policy를 사용하여 새 정책 파일 생성 (현재 연결된 USB 장치에 대한 규칙만 생성).

새로 생성된 규칙과 이전 정책의 규칙을 비교하여, 필요한 경우 기존 규칙을 수정합니다. 차이가 없다면 RHEL 9 정책 파일을 그대로 사용할 수 있습니다.

fapolicyd는 사용자 정의 정책에 따라 애플리케이션 실행을 제어합니다. 드물게 fapolicyd 신뢰 데이터베이스 형식 문제가 발생할 수 있습니다. 이 경우 데이터베이스를 재구축해야 합니다.[1]

데이터베이스 재구축 프로세스 [1]:

서비스 중지: # systemctl stop fapolicyd

데이터베이스 삭제: # fapolicyd-cli –delete-db

서비스 시작: # systemctl start fapolicyd
사용자 정의 신뢰 파일을 추가한 경우, fapolicyd-cli -f update 또는 fapolicyd-cli -f update로 업데이트하고, fapolicyd-cli –update 또는 서비스 재시작으로 변경 사항을 적용합니다. 사용자 정의 바이너리는 새 RHEL 버전에 맞게 재빌드해야 할 수 있습니다.

RHEL 9에서 RHEL 10으로 업그레이드하는 과정에서 발생할 수 있는 문제 해결을 위한 팁과 리소스는 다음과 같습니다.[1]

사전 업그레이드 단계 [1]:

시스템이 “2장. 업그레이드 계획”의 모든 조건을 충족하는지 확인합니다.

“3장. 업그레이드 준비”의 모든 단계를 따랐는지 확인합니다.

var/log/leapp/answerfile에 Leapp이 요구하는 모든 질문에 답변했는지 확인합니다. 답변 누락 시 업그레이드가 차단됩니다. (예시: VDO 장치 관련 질문 [1])

var/log/leapp/leapp-report.txt의 사전 업그레이드 보고서에서 식별된 모든 문제를 해결했는지 확인합니다.

다운로드 단계 [1]:

RPM 패키지 다운로드 중 문제 발생 시 var/log/leapp/dnf-debugdata 디렉터리의 트랜잭션 디버그 데이터를 검사합니다. (이 디렉터리는 –debug 옵션으로 leapp upgrade 실행 시에만 존재하거나, 필수 리포지토리 부재 시 비어있을 수 있습니다.)

Initramfs 단계 [1]:

이 단계에서 실패 시 Dracut 쉘로 리디렉션됩니다. journalctl로 저널 로그를 확인하거나, reboot 후 var/log/leapp/leapp-upgrade.log 파일을 확인합니다.

업그레이드 후 단계 [1]:

시스템이 성공적으로 업그레이드된 것처럼 보이지만 이전 RHEL 9 커널로 부팅된 경우, 시스템을 재시작하고 GRUB의 기본 항목 커널 버전을 확인합니다.

“6장. 업그레이드 후 상태 확인”의 권장 단계를 따랐는지 확인합니다.

SELinux를 enforcing 모드로 전환 후 애플리케이션/서비스 오작동 시 ausearch, journalctl, dmesg로 거부 로그를 검색합니다. (일반적으로 잘못된 레이블링 문제)

[1]

이러한 로그 파일들은 문제 발생 시 원인을 파악하고 해결책을 찾는 데 결정적인 단서를 제공합니다. 특히 leapp-report.txt는 업그레이드 시도 전에 반드시 검토해야 할 가장 중요한 정보원입니다.

다음은 업그레이드 시 발생할 수 있는 몇 가지 알려진 문제입니다.[1] 이러한 문제들을 사전에 인지하고 있으면, 발생 시 신속하게 대처하거나 예방 조치를 취하는 데 도움이 됩니다.

타사 장치 드라이버: RHEL 9 시스템이 Red Hat에서 제공하지만 RHEL 10에서는 사용할 수 없는 장치 드라이버를 사용하는 경우 Leapp이 업그레이드를 차단합니다. 그러나 Leapp이 etc/leapp/files/device_driver_deprecation_data.json 파일에 데이터가 없는 타사 장치 드라이버를 사용하는 경우, Leapp은 해당 드라이버를 감지하지 못하고 업그레이드를 진행하여 업그레이드 후 시스템 부팅에 실패할 수 있습니다.

중복 패키지 이름: 시스템에 설치된 타사 패키지(Red Hat 서명 안 됨) 이름이 Red Hat 제공 패키지 이름과 동일하면 인플레이스 업그레이드가 실패합니다. 해결 방법은 업그레이드 전 타사 패키지를 제거하거나 Red Hat 제공 패키지로 교체하는 것입니다.

소프트웨어 RAID: 소프트웨어 RAID(Redundant Array of Independent Disks)가 있는 시스템에서 인플레이스 업그레이드가 실패할 수 있습니다 (BZ#1957192).

NIC 이름 변경: 일부 시스템(예: 네트워크 본딩)에서는 NIC 이름이 RHEL 9와 RHEL 10 간에 업데이트되어야 할 수 있습니다. 이 경우 LEAPP_NO_NETWORK_RENAMING=1 환경 변수를 설정하고 업그레이드한 후 네트워크 구성을 수동으로 확인/수정합니다 (BZ#1919382).

etc/fstab의 공유되지 않은 마운트 지점: etc/fstab에 정의된 마운트된 파일 시스템에 공유 전파 플래그가 설정되지 않으면 업그레이드가 실패할 수 있습니다. mount -o remount –make-shared <mountpoint>로 다시 마운트하여 해결합니다 (RHEL-23449).

HTTP 프록시: subscription-manager를 rhsm.conf에 구성하는 대신 –proxy 옵션으로 사용하면 Leapp이 프록시를 감지하지 못해 업그레이드가 실패합니다 (BZ#1689294). etc/dnf/dnf.conf의 DNF 프록시 구성도 RHEL 10 DNF에 맞게 etc/leapp/files/dnf.conf에서 조정해야 할 수 있습니다.

Kerberos 클라이언트: 더 이상 사용되지 않는 etc/ssl/certs/ca-certificates.crt를 루트 인증서에 사용하도록 구성된 경우 업그레이드 후 Kerberos 클라이언트가 중단될 수 있습니다. 대신 etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem 파일을 사용합니다 (RHEL-65265).

지원이 필요한 경우, RHEL 9를 제품으로 선택하여 지원 케이스를 열고 시스템에서 sosreport를 제공합니다.[1]

sosreport 생성: # sosreport

RHEL 9에서 RHEL 10으로의 인플레이스 업그레이드는 Leapp 유틸리티를 통해 체계적으로 진행될 수 있는 과정입니다. 성공적인 업그레이드를 위해서는 다음 사항들이 중요합니다:

철저한 계획 및 사전 검토: 지원되는 경로 확인, 시스템 요구 사항 및 제한 사항(특히 애플리케이션 호환성, 부트로더, 미지원 소프트웨어)을 사전에 파악하고 대비해야 합니다.[1]

시스템 준비의 중요성: 최신 패키지 상태 유지, 정확한 리포지토리 설정(특히 Satellite 환경), 시스템 백업은 필수적입니다.[1] 리포지토리 구성 오류는 흔한 실패 원인이므로, 부록 A와 B에 명시된 정확한 버전의 리포지토리를 활성화하는 것이 중요합니다.[1]

leapp preupgrade 보고서 활용: 업그레이드 전 보고서를 통해 잠재적 문제를 식별하고, 제시된 해결책(필요시 answerfile 수정 포함)을 적용하여 실제 업그레이드 단계에서의 위험을 최소화해야 합니다.[1]

단계별 실행 및 검증: leapp upgrade 명령 실행 후 재부팅 과정과 업그레이드 후 OS 버전, 커널, 서브스크립션 상태 등을 꼼꼼히 확인해야 합니다.[1]

업그레이드 후 작업 및 보안 강화: 불필요한 패키지 정리, 복구 커널 업데이트, SELinux 모드 변경 및 기타 보안 정책 적용은 시스템 안정성과 보안을 위해 반드시 수행해야 할 작업입니다.[1]

문제 해결 능력: 주요 로그 파일 위치를 숙지하고, 알려진 문제에 대한 이해를 바탕으로 문제 발생 시 신속하게 대응할 수 있어야 합니다.[1]

이 가이드에 설명된 절차와 권장 사항을 따르면 RHEL 9 시스템을 RHEL 10으로 성공적으로 업그레이드하여 최신 기능과 향상된 보안을 활용할 수 있을 것입니다.

인플레이스 업그레이드 시 Leapp 유틸리티는 소스(RHEL 9) 및 대상(RHEL 10) 운영 체제의 패키지에 접근해야 합니다. 이를 위해 올바른 리포지토리 설정이 매우 중요합니다.[1]

Red Hat CDN (RHSM 직접 등록 시): 일반적으로 Leapp이 필요한 RHEL 9 및 RHEL 10 리포지토리를 자동으로 처리합니다.

Red Hat Satellite 환경:

RHEL 9 리포지토리: 업그레이드 전, Satellite 서버에서 해당 아키텍처의 RHEL 9 BaseOS 및 AppStream 리포지토리를 소스 OS 버전(예: 9.6)으로 활성화하고 동기화해야 합니다.

RHEL 10 리포지토리: 마찬가지로, 해당 아키텍처의 RHEL 10 BaseOS 및 AppStream 리포지토리를 대상 OS 버전(예: 10.0)으로 활성화하고 동기화해야 합니다.

중요: 단순히 주 버전(예: “RHEL 9”)만 활성화하고 특정 부 버전(예: “9.6”)을 지정하지 않으면 업그레이드가 차단될 수 있습니다.

정확한 리포지토리 이름과 ID는 문서의 부록 A(RHEL 9 리포지토리)와 부록 B(RHEL 10 리포지토리)에서 확인할 수 있습니다.[1] Satellite 환경에서는 이 설정이 수동으로 이루어지므로 각별한 주의가 필요하며, 부정확하거나 불완전한 리포지토리 설정은 업그레이드 실패의 주요 원인이 됩니다.