10.2. 문제 해결 팁
다음 문제 해결 팁을 참조할 수 있습니다.
업그레이드 전 단계
- 시스템이 업그레이드 계획에 나열된 모든 조건을 충족하는지 확인하십시오.
-
업그레이드 준비에 설명된 모든 단계, 예를 들어 시스템에서 커널(
eth)에서 사용하는 접두사에 따라 이름 기반의 NIC(네트워크 인터페이스 카드)를 두 개 이상 사용하지 않는지 확인합니다. /var/log/leapp/answerfile파일의Leapp에서 요구하는 모든 질문에 답변했는지 확인하십시오. 응답이 누락된 경우Leapp이 업그레이드를 금지합니다. 예제 질문:- PAM 구성에서 pam_pkcs11 모듈을 비활성화합니다.
- PAM 구성에서 pam_krb5 모듈을 비활성화합니다.
- 다음 authselect 호출을 사용하여 PAM 및 nsswitch.conf를 구성합니다.
-
/var/log/leapp/leapp-report.txt에 있는 사전 업그레이드 보고서에서 확인된 모든 문제를 해결했는지 확인합니다. 이를 위해 확장 가능성에 설명된 대로 웹 콘솔을 사용하고 웹 콘솔을 통해 자동 수정 사항을 적용할 수도 있습니다.
예 10.1. Leapp 응답 파일
다음은 편집되지 않은 /var/log/leapp/answerfile 파일의 예입니다.
[remove_pam_pkcs11_module_check] # Title: None # Reason: Confirmation # =================== remove_pam_pkcs11_module_check.confirm ================== # Label: Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted. # Description: PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD. # Type: bool # Default: None # Available choices: True/False # Unanswered question. Uncomment the following line with your answer # confirm =
Label 필드는 대답이 필요한 질문을 지정합니다. 이 예에서 질문은 PAM 구성에서 pam_pkcs11 모듈을 비활성화합니까?입니다.
질문에 답변하려면 confirm 행의 주석을 제거하고 True 또는 False에 대한 답변을 입력합니다. 이 예제에서 선택한 응답은 True 입니다.
[remove_pam_pkcs11_module_check]
...
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True다운로드 단계
RPM 패키지를 다운로드하는 동안 문제가 발생하면
/var/log/leapp/dnf-debugdata/디렉터리에 있는 트랜잭션 디버그 데이터를 검사합니다.참고/var/log/leapp/dnf-debugdata/디렉터리는 비어 있거나 트랜잭션 디버그 데이터가 생성되지 않은 경우 존재하지 않습니다. 이는 필요한 리포지토리를 사용할 수 없는 경우 발생할 수 있습니다.
initramfs 단계
이 단계에서 잠재적인 실패가 Dracut 쉘로 리디렉션됩니다. 저널 로그를 확인합니다.
# journalctl또는
reboot명령을 사용하여 Dracut 쉘에서 시스템을 다시 시작하고/var/log/leapp/leapp-upgrade.log파일을 확인합니다.
업그레이드 후 단계
- 시스템이 성공적으로 업그레이드되었지만 이전 RHEL 7 커널로 부팅된 것처럼 보이는 경우 시스템을 다시 시작하고 GRUB에서 기본 항목의 커널 버전을 확인합니다.
- RHEL 8 시스템의 후 업그레이드 상태 확인에서 권장 단계를 수행했는지 확인하십시오.
SELinux를 강제 모드로 전환한 후 애플리케이션 또는 서비스가 작동하지 않거나 잘못 작동하는 경우 ausearch, journalctl 또는 dmesg 유틸리티를 사용하여 서비스 거부를 검색합니다.
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400
가장 일반적인 문제는 잘못된 레이블 지정으로 인해 발생합니다. 자세한 내용은 SELinux 관련 문제 해결을 참조하십시오.
