9.2. 문제 해결 팁
다음 문제 해결 팁을 참조할 수 있습니다.
업그레이드 전 단계
- 시스템이 업그레이드 계획에 나열된 모든 조건을 충족하는지 확인하십시오.
-
업그레이드 준비에 설명된 모든 단계를 예를 들어 시스템에서 커널(
eth
)에서 사용하는 접두사에 따라 이름 기반의 NIC(네트워크 인터페이스 카드)를 두 개 이상 사용하지 않는지 확인합니다. /var/log/leapp/answerfile
파일의Leapp
에서 요구하는 모든 질문에 답변했는지 확인하십시오. 응답이 누락된 경우Leapp
이 업그레이드를 금지합니다. 예를 들어 다음과 같습니다.- 시스템에 VDO 장치가 있습니까?
-
/var/log/leapp-report.txt에 있는 사전 업그레이드 보고서에서
확인된 모든 문제를 해결했는지 확인합니다. 이를 위해 확장 가능성에 설명된 대로 웹 콘솔을 사용하고 웹 콘솔을 통해 자동 수정 사항을 적용할 수도 있습니다.
예 9.1. LeApp 응답 파일
다음은 대답되지 않은 질문 하나가 있는 편집되지 않은 /var/log/leapp/answerfile
파일의 예입니다.
[check_vdo] # Title: None # Reason: Confirmation # ============================= check_vdo.confirm ============================= # Label: Are all VDO devices, if any, successfully converted to LVM management? # Description: Enter True if no VDO devices are present on the system or all VDO devices on the system have been successfully converted to LVM management. Entering True will circumvent check of failures and undetermined devices. Recognized VDO devices that have not been converted to LVM management can still block the upgrade despite the answer.All VDO devices must be converted to LVM management before upgrading. # Reason: To maximize safety all block devices on a system that meet the criteria as possible VDO devices are checked to verify that, if VDOs, they have been converted to LVM management. If the devices are not converted and the upgrade proceeds the data on unconverted VDO devices will be inaccessible. In order to perform checking the 'vdo' package must be installed. If the 'vdo' package is not installed and there are any doubts the 'vdo' package should be installed and the upgrade process re-run to check for unconverted VDO devices. If the check of any device fails for any reason an upgrade inhibiting report is generated. This may be problematic if devices are dynamically removed from the system subsequent to having been identified during device discovery. If it is certain that all VDO devices have been successfully converted to LVM management this dialog may be answered in the affirmative which will circumvent block device checking. # Type: bool # Default: None # Available choices: True/False # Unanswered question. Uncomment the following line with your answer # confirm =
Label
필드는 대답이 필요한 질문을 지정합니다. 이 예에서 문제는 모든 VDO 장치가 LVM 관리로 성공적으로 변환됩니까?
질문에 대답하려면 마지막 줄의 주석 처리를 제거하고 True
또는 False
응답을 입력합니다. 이 예에서 선택한 답변은 True
입니다.
[check_vdo]
...
# 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
파일을 확인합니다.
post-upgrade 단계
- 시스템을 성공적으로 업그레이드하고 이전 RHEL 8 커널로 부팅한 것처럼 보이는 경우 시스템을 다시 시작하고 GRUB에서 기본 항목의 커널 버전을 확인합니다.
- RHEL 9 시스템의 업그레이드 후 상태 확인을 위한 권장 단계를 따르십시오.
SELinux를 강제 모드로 전환한 후 애플리케이션 또는 서비스가 작동하지 않거나 잘못 작동하는 경우 ausearch, journalctl 또는 dmesg 유틸리티를 사용하여 거부를 검색합니다.
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400
가장 일반적인 문제는 잘못된 레이블 지정으로 인해 발생합니다. 자세한 내용은 SELinux 관련 문제 해결을 참조하십시오.