rhel_9_to_10_leapp_upgrade

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

rhel_9_to_10_leapp_upgrade [2025/05/28 01:31] – 만듦 koovrhel_9_to_10_leapp_upgrade [2025/05/28 01:34] (현재) – koov
줄 1: 줄 1:
 ====== RHEL 9 to 10 leapp upgrade ====== ====== RHEL 9 to 10 leapp upgrade ======
 +  * https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/upgrading_from_rhel_9_to_rhel_10/index
  
-이 문서는 Red Hat Enterprise Linux (RHEL) 9 시스템을 RHEL 10으로 인플레이스(in-place) 업그레이드하는 과정을 요약합니다. Leapp 유틸리티를 사용한 업그레이드 절차, 준비 사항, 실행, 후속 조치 및 문제 해결 방법을 다룹니다. 
  
-===== 1. 개요 =====+===== 사전준비사항 =====
  
-Leapp 유틸리티는 RHEL 9에서 RHEL 10으로의 인플레이스 업그레이드를 지원합니다. 이 과정은 기존 시스템의 애플리케이션, 데이터, 구성을 유지하면서 운영 체제를 업그레이드하는 것을 목표로 합니다.+<WRAP prewrap> 
 +<code bash> 
 +subscription-manager repos --enable rhel-9-for-x86_64-baseos-rpms --enable rhel-9-for-x86_64-appstream-rpms 
 +subscription-manager release --set 9.6 
 +dnf versionlock clear 
 +dnf install leapp-upgrade 
 +dnf update 
 +reboot 
 +</code> 
 +</WRAP>
  
-==== 1.1. 주요 업그레이드 단계 ====+===== 업그레이드 체크 ===== 
 +<WRAP prewrap> 
 +<code bash> 
 +leapp preupgrade 
 +leapp preupgrade --target <_target_os_version_> 
 +</code> 
 +</WRAP>
  
-계획 및 준비: 업그레이드 경로 확인, 시스템 백업, 필수 리포지토리 설정.+생성된 ''/var/log/leapp/leapp-report.txt'' 파일에서 업그레이드 전 보고서를 검토하고 명령줄을 사용하여 보고된 문제를 수동으로 해결합니다.
  
-사전 업그레이드 평가: leapp preupgrade 명령을 사용하여 잠재적 문제 식별 및 해결.+<WRAP prewrap> 
 +<code bash> 
 +leapp answer --section <question_section>.<field_name>=<answer> 
 +</code> 
 +</WRAP>
  
-업그레이드 실행: leapp upgrade 명령을 사용하여 실제 업그레이드 수행.+===== Cockpit 플러그인 설치 ===== 
 +<WRAP prewrap> 
 +<code bash> 
 +dnf install cockpit-leapp 
 +</code> 
 +</WRAP>
  
-업그레이드 후 작업: 시스템 상태 확인, 불필요한 패키지 정리, 보안 설정 복원. 
  
-==== 1.2. 중요 고려 사항 ==== 
  
-지원되는 아키텍처: 64비트 Intel, 64비트 ARM, IBM Power (little endian), IBM Z. [1] +===== 업그레이드 수행 ===== 
- +<WRAP prewrap> 
-부트로더: GRUB2만 지원. [1] +<code bash> 
- +leapp upgrade --target <_target_os_version_> 
-백업: 업그레이드 전 전체 시스템 백업은 필수입니다. ReaR(Relax-and-Recover) 사용 권장. [1] +</code> 
- +</WRAP>
-디스크 공간: /boot 파티션 최소 250MB, 루트 파일 시스템 및 기타 Leapp 관련 디렉터리(예: //var/lib/leapp//)에 충분한 공간 확보. [1] +
- +
-미지원 구성: NetworkManager를 사용하지 않는 네트워크 구성, 타사 패키지 충돌, 특정 커널 모듈 등은 문제가 될 수 있습니다. [1] +
- +
-===== 2. 업그레이드 계획 ===== +
- +
-성공적인 업그레이드를 위해서는 철저한 계획이 필요합니다. +
- +
-==== 2.1. 지원되는 업그레이드 경로 ==== +
- +
-특정 RHEL 9 부 버전에서 특정 RHEL 10 부 버전으로의 업그레이드 경로를 확인해야 합니다 (예: RHEL 9.6에서 RHEL 10.0). [1] +
- +
-Extended Update Support (EUS) 또는 Advanced Update Support (AUS) 서브스크립션을 사용하는 경우, 해당 조건에 맞는 경로를 따라야 합니다. [1] +
- +
-==== 2.2. 시스템 요구 사항 및 제한 사항 확인 ==== +
- +
-디스크 공간: +
- +
-//boot// 파티션: 최소 250MB의 여유 공간. +
- +
-//var/lib/leapp// 디렉터리: 최소 4GB (최대 8GB 권장). +
- +
-루트 파일 시스템: 최소 4GB의 여유 공간. +
- +
-메모리: 최소 1GB RAM. +
- +
-애플리케이션 호환성: 업그레이드 후 애플리케이션이 RHEL 10과 호환되는지 사전에 확인해야 합니다. 특히 RHEL 10에서 제거되거나 변경된 패키지에 의존하는 애플리케이션을 검토합니다. +
- +
-커널 모듈: 사용자 정의 또는 타사 커널 모듈은 RHEL 10 커널과 호환되지 않을 수 있습니다. +
- +
-보안 소프트웨어: 안티바이러스 소프트웨어는 업그레이드 과정에서 일시적으로 비활성화하는 것이 좋습니다. [1] +
- +
-===== 3. 업그레이드 준비 ===== +
- +
-업그레이드 프로세스를 시작하기 전에 시스템을 적절히 준비해야 합니다. +
- +
-==== 3.1. 업그레이드를 위한 RHEL 9 시스템 준비 ==== +
- +
-전체 시스템 백업: 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 유틸리티가 업그레이드 과정 전체에서 접근할 수 있도록 영구 로컬 마운트 지점에 저장되었는지 확인합니다. +
- +
-==== 3.2. 업그레이드를 위한 Satellite 등록 시스템 준비 ==== +
- +
-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" +
- +
-===== 4. 업그레이드 전 보고서 검토 ===== +
- +
-시스템의 업그레이드 가능성을 평가하기 위해 leapp preupgrade 명령을 사용하여 사전 업그레이드 프로세스를 시작합니다.[1] 이 단계에서 Leapp 유틸리티는 시스템 데이터를 수집하고, 업그레이드 가능성을 평가하며, 업그레이드 전 보고서를 생성합니다. 이 보고서는 잠재적 문제를 요약하고 권장 해결책을 제시하여 업그레이드 진행 여부 결정에 도움을 줍니다. +
- +
-중요 사항 [1]: +
- +
-사전 평가는 시스템 구성을 변경하지 않지만, //var/lib/leapp// 디렉터리에 상당한 공간(최대 4GB 이상)을 사용합니다. 공간 부족 시 보고서가 불완전할 수 있으므로 충분한 공간을 확보하거나 해당 디렉터리를 별도 파티션으로 이동하는 것이 좋습니다. +
- +
-보고서에 업그레이드 차단 요소(inhibitor)가 없더라도 전체 보고서를 검토해야 합니다. 여기에는 업그레이드된 시스템이 올바르게 작동하도록 하기 위해 업그레이드 전에 완료해야 할 권장 조치가 포함되어 있습니다. +
- +
-사전 보고서는 전체 업그레이드 프로세스를 시뮬레이션하는 것이 아니므로, 모든 잠재적 문제를 식별하지 못할 수 있습니다 (예: 손상된 패키지 다운로드 문제). +
- +
-==== 4.1. 명령줄에서 업그레이드 가능성 평가 ==== +
- +
-명령줄을 사용하여 사전 업그레이드 단계에서 잠재적인 업그레이드 문제를 식별합니다.[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이 특정 시스템 구성에 대해 사용자의 확인을 받아야 할 때 사용되며, 답변 없이는 업그레이드가 진행되지 않으므로 주의 깊게 확인하고 응답해야 합니다. +
- +
-이전 단계를 반복하여 사전 업그레이드 보고서를 다시 실행하고 모든 중요 문제가 해결되었는지 확인합니다. +
- +
-==== 4.2. 웹 콘솔(Cockpit-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단계를 반복하여 보고서를 다시 실행하고 모든 중요 문제가 해결되었는지 확인합니다. +
- +
-===== 5. 업그레이드 수행 ===== +
- +
-준비 단계를 완료하고 업그레이드 전 보고서에서 발견된 문제를 모두 검토하고 해결한 후, 시스템에서 실제 인플레이스 업그레이드를 수행할 수 있습니다.[1] +
- +
-==== 5.1. RHEL 9에서 RHEL 10으로 업그레이드 실행 ==== +
- +
-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 시스템에서 업그레이드 후 작업 수행"에 설명된 모든 업그레이드 후 작업을 수행합니다. +
- +
-===== 6. 업그레이드 후 상태 확인 ===== +
- +
-RHEL 10으로 인플레이스 업그레이드를 수행한 후, 시스템이 올바른 상태인지 확인해야 합니다.[1] 이를 통해 시스템에 영향을 미칠 수 있는 중요한 오류를 식별하고 수정할 수 있습니다. +
- +
-==== 6.1. RHEL 10 시스템의 업그레이드 후 상태 확인 ==== +
- +
-다음은 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를 사용하여 서버에 연결을 시도합니다. +
- +
-애플리케이션 업그레이드 후 상태 확인: 경우에 따라 수동으로 마이그레이션 및 구성 변경을 수행해야 할 수 있습니다. 예를 들어, 데이터베이스 마이그레이션은 관련 문서 지침을 따릅니다. +
- +
-이러한 확인 과정을 통해 업그레이드가 성공적으로 완료되었는지, 시스템의 핵심 기능들이 정상적으로 작동하는지를 점검할 수 있습니다. +
- +
-===== 7. RHEL 10 시스템에서 업그레이드 후 작업 수행 ===== +
- +
-인플레이스 업그레이드 후, 불필요한 패키지를 제거하고, 호환되지 않는 리포지토리를 비활성화하며, 복구 커널 및 초기 RAM 디스크를 업데이트하여 RHEL 10 시스템을 정리해야 합니다.[1] 이러한 후속 조치는 시스템을 최적화하고 안정성을 확보하는 데 중요합니다. +
- +
-==== 7.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." +
- +
-===== 8. 보안 정책 적용 ===== +
- +
-인플레이스 업그레이드 과정에서 SELinux 정책은 permissive 모드로 전환됩니다. 또한, 주요 릴리스 간 보안 프로필 변경이 있을 수 있습니다. 시스템 보안을 복원하려면 SELinux를 다시 enforcing 모드로 전환하고 시스템 전체 암호화 정책을 확인해야 합니다. 특정 보안 프로필을 준수하도록 시스템을 수정하거나, 일부 보안 관련 구성 요소의 사전 업데이트 단계가 필요할 수 있습니다.[1] +
- +
-==== 8.1. SELinux 모드를 강제(Enforcing) 모드로 변경 ==== +
- +
-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 +
- +
-==== 8.2. 시스템 전체 암호화 정책 ==== +
- +
-시스템 전체 암호화 정책은 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 +
-사용자 지정 암호화 정책은 업그레이드 시 유지되지만, 새로운 위협에 대응하기 위해 검토 및 업데이트를 고려해야 합니다. +
- +
-==== 8.3. 보안 기준 강화 시스템 업그레이드 (OpenSCAP 사용) ==== +
- +
-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 +
- +
-==== 8.4. USBGuard 정책 확인 ==== +
- +
-USBGuard는 허용/금지된 USB 장치 목록을 사용하여 시스템을 보호합니다. 업그레이드 전에 생성된 규칙 세트가 있다면, RHEL 10에서 정책을 다시 생성하고 이전 정책과 비교하여 필요한 조정을 수행해야 합니다.[1] +
- +
-프로세스 [1]: +
- +
-//etc/usbguard// 디렉터리의 *.conf 파일 백업. +
- +
-usbguard generate-policy를 사용하여 새 정책 파일 생성 (현재 연결된 USB 장치에 대한 규칙만 생성). +
- +
-새로 생성된 규칙과 이전 정책의 규칙을 비교하여, 필요한 경우 기존 규칙을 수정합니다. 차이가 없다면 RHEL 9 정책 파일을 그대로 사용할 수 있습니다. +
- +
-==== 8.5. Fapolicyd 데이터베이스 업데이트 ==== +
- +
-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 버전에 맞게 재빌드해야 할 수 있습니다. +
- +
-===== 9. 문제 해결 ===== +
- +
-RHEL 9에서 RHEL 10으로 업그레이드하는 과정에서 발생할 수 있는 문제 해결을 위한 팁과 리소스는 다음과 같습니다.[1] +
- +
-==== 9.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로 거부 로그를 검색합니다. (일반적으로 잘못된 레이블링 문제) +
- +
-==== 9.2. 중요 로그 파일 위치 ==== +
- +
-^ 파일 경로                                       ^ 설명                                                                                                ^ +
-| //var/log/leapp/leapp-report.txt// (.json도 사용 가능) | 사전 업그레이드 평가 보고서, 차단 요소 및 권장 사항 목록 | +
-| //var/log/leapp/answerfile// | Leapp 진행을 위해 사용자 입력이 필요한 질문 | +
-| //var/log/leapp/leapp-upgrade.log// | 주 업그레이드 단계(initramfs, 패키지 설치) 로그 | +
-| //var/log/leapp/dnf-debugdata// | 상세 DNF 트랜잭션 데이터 (leapp이 //--debug//로 실행된 경우) | +
-| journalctl | 업그레이드 중 Leapp, DNF, 커널 메시지를 포함한 시스템 전체 로그 | +
-[1] +
- +
-이러한 로그 파일들은 문제 발생 시 원인을 파악하고 해결책을 찾는 데 결정적인 단서를 제공합니다. 특히 leapp-report.txt는 업그레이드 시도 전에 반드시 검토해야 할 가장 중요한 정보원입니다. +
- +
-==== 9.3. 알려진 문제 ==== +
-다음은 업그레이드 시 발생할 수 있는 몇 가지 알려진 문제입니다.[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). +
- +
-==== 9.4. 지원 받기 ==== +
-지원이 필요한 경우, RHEL 9를 제품으로 선택하여 지원 케이스를 열고 시스템에서 sosreport를 제공합니다.[1] +
- +
-sosreport 생성: # sosreport +
- +
-===== 10. 결론 ===== +
- +
-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으로 성공적으로 업그레이드하여 최신 기능과 향상된 보안을 활용할 수 있을 것입니다. +
- +
-===== 부록 A: 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 환경에서는 이 설정이 수동으로 이루어지므로 각별한 주의가 필요하며, 부정확하거나 불완전한 리포지토리 설정은 업그레이드 실패의 주요 원인이 됩니다.+
  
  
  • rhel_9_to_10_leapp_upgrade.1748395905.txt.gz
  • 마지막으로 수정됨: 2025/05/28 01:31
  • 저자 koov