커널 변경 내용을 적용한 후 Azure Linux 가상 머신이 부팅되지 않습니다.
참고
이 문서에서 참조하는 CentOS는 Linux 배포판이며 EOL(수명 종료)에 도달합니다. 사용을 고려하고 그에 따라 계획하십시오. 자세한 내용은 CentOS 수명 종료 지침을 참조하세요.
이 문서에서는 커널 변경 내용을 적용한 후 Linux VM(가상 머신)이 부팅할 수 없는 문제에 대한 솔루션을 제공합니다.
필수 조건
직렬 콘솔이 Linux VM에서 사용하도록 설정되고 작동하는지 확인합니다.
커널 관련 부팅 문제를 식별하는 방법
커널 관련 부팅 문제를 식별하려면 특정 커널 패닉 문자열을 검사. 이렇게 하려면 Azure CLI 또는 Azure Portal 사용하여 부팅 진단 창 또는 직렬 콘솔 창에서 VM의 직렬 콘솔 로그 출력을 봅니다.
커널 패닉은 다음 출력과 같으며 직렬 콘솔 로그의 끝에 표시됩니다.
Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[ 300.206297] Kernel panic - xxxxxxxx
[ 300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G ------------ T 3.xxx.x86_64 #1
온라인 문제 해결
팁
VM의 최근 백업이 있는 경우 백업에서 VM을 복원 하여 부팅 문제를 해결합니다.
직렬 콘솔은 부팅 문제를 resolve 가장 빠른 방법입니다. 이를 통해 복구 VM에 시스템 디스크를 표시하지 않고도 문제를 직접 해결할 수 있습니다. 배포에 필요한 필수 구성 요소를 충족하는지 확인합니다. 자세한 내용은 Linux용 가상 머신 직렬 콘솔을 참조하세요.
Azure 직렬 콘솔을 사용하여 GRUB 메뉴에서 VM을 중단하고 이전 커널을 선택하여 부팅합니다. 자세한 내용은 이전 커널 버전의 부팅 시스템을 참조하세요.
해당 섹션으로 이동하여 특정 커널 관련 부팅 문제를 resolve.
커널 관련 부팅 문제가 해결된 후 최신 커널 버전을 통해 부팅할 수 있도록 VM을 다시 시작합니다.
오프라인 문제 해결
팁
VM의 최근 백업이 있는 경우 백업에서 VM을 복원 하여 부팅 문제를 해결합니다.
Azure 직렬 콘솔이 특정 VM에서 작동하지 않거나 구독의 옵션이 아닌 경우 복구/복구 VM을 사용하여 부팅 문제를 해결합니다. 이렇게 하려면 다음과 같이 하십시오.
vm 복구 명령을 사용하여 영향을 받는 VM의 OS 디스크 복사본이 연결된 복구 VM을 만듭니다. chroot를 사용하여 복구 VM에 OS 파일 시스템의 복사본을 탑재합니다.
참고
또는 Azure Portal 사용하여 구조 VM을 수동으로 만들 수 있습니다. 자세한 내용은 Azure Portal 사용하여 OS 디스크를 복구 VM에 연결하여 Linux VM 문제 해결을 참조하세요.
해당 섹션으로 이동하여 특정 커널 관련 부팅 문제를 resolve.
커널 관련 부팅 문제가 해결된 후 다음 작업을 수행합니다.
- 크로트를 종료합니다.
- 복구/복구 VM에서 파일 시스템의 복사본을 분리합니다.
az vm repair restore명령을 실행하여 복구된 OS 디스크를 VM의 원래 OS 디스크로 교환합니다. 자세한 내용은 Azure Virtual Machine 복구 명령을 사용하여 Linux VM 복구의 5단계를 참조하세요.- Azure 직렬 콘솔을 살펴보거나 VM에 연결하여 VM이 부팅할 수 있는지 확인합니다.
중요한 커널 관련 콘텐츠, 전체
/boot파티션 또는 기타 중요한 콘텐츠가 누락되어 복구할 수 없는 경우 백업에서 VM을 복원하는 것이 좋습니다. 자세한 내용은 Azure Portal Azure VM 데이터를 복원하는 방법을 참조하세요.
이전 커널 버전의 부팅 시스템
Azure 직렬 콘솔 사용
Azure 직렬 콘솔을 사용하여 VM을 다시 시작합니다.
- 직렬 콘솔 창의 맨 위에 있는 종료 단추를 선택합니다.
- VM 다시 시작(하드) 옵션을 선택합니다.
직렬 콘솔 연결이 다시 시작되면 직렬 콘솔 창의 왼쪽 위 모서리에 카운트다운 카운터가 표시됩니다. GRUB 메뉴에서 이스케이프 키를 눌러 VM을 중단합니다.
아래쪽 화살표 키를 눌러 이전 커널 버전을 선택합니다.
GRUB_DEFAULT기본 커널 버전 수동으로 변경에 지시된 대로 /etc/default/grub 파일에서 변수를 변경합니다. 이는 지속적인 변경입니다.
참고
GRUB 메뉴에 커널 버전이 하나만 나열된 경우 오프라인 문제 해결 방법을 따라 복구 VM에서 이 문제를 해결합니다.
복구 VM 사용(ALAR 스크립트)
Azure Cloud Shell 다음 bash 명령을 실행하여 복구 VM을 만듭니다. 자세한 내용은 ALAR(Azure Linux 자동 복구)를 사용하여 Linux VM - 커널 옵션 수정을 참조하세요.
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy다음 명령을 실행하여 손상된 커널을 이전에 설치된 버전으로 바꿉 있습니다.
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair az vm repair restore --verbose -g $RGNAME -n $VMNAME
참고
시스템에 커널 버전이 하나만 설치되어 있는 경우 오프라인 문제 해결 방법을 따라 복구 VM에서 이 문제를 해결합니다.
기본 커널 버전을 수동으로 변경
복구 VM(chroot 내부) 또는 실행 중인 VM에서 기본 커널 버전을 수정하려면 다음 단계를 수행합니다.
참고
커널 다운그레이드 롤백이 완료되면 이전 커널 버전 대신 가장 최근 커널 버전을 선택합니다.
RHEL 7, Oracle Linux 7 및 CentOS 7
다음 명령 중 하나를 실행하여 GRUB 구성 파일에서 사용 가능한 커널 목록의 유효성을 검사합니다.
Gen1 VM:
cat /boot/grub2/grub.cfg | grep menuentryGen2 VM:
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
새 기본 커널을 설정하고 다음 명령을 실행하여 해당 커널 제목을 지정합니다.
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'참고
을 해당 메뉴 항목 제목으로 바꿉 있습니다
Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64.다음 명령을 실행하여 새 기본 커널이 원하는 커널인지 확인합니다.
grub2-editenv list/etc/default/grub 파일의
GRUB_DEFAULT변수 값이 로 설정되어 있는지 확인합니다saved. 수정하려면 GRUB 구성 파일을 다시 생성 하여 변경 내용을 적용해야 합니다.
RHEL 8/9 및 CentOS 8
다음 명령을 실행하여 사용 가능한 커널을 나열합니다.
ls -l /boot/vmlinuz-*다음 명령을 실행하여 새 기본 커널을 설정합니다.
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64참고
을 해당 커널 버전으로 바꿉 있습니다
4.18.0-372.19.1.el8_6.x86_64.다음 명령을 실행하여 새 기본 커널이 원하는 커널인지 확인합니다.
grubby --default-kernel
SLES 12/15, Ubuntu 18.04/20.04
다음 명령을 실행하여 GRUB 구성 파일에서 사용 가능한 커널을 나열합니다.
Gen1 VM:
SLES 12/15:
cat /boot/grub2/grub.cfg | grep menuentryUbuntu 18.04/20.04:
cat /boot/grub/grub.cfg | grep menuentry
Gen2 VM:
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
/etc/default/grub 파일에서 변수 값을
GRUB_DEFAULT수정하여 새 기본 커널을 설정합니다. 시스템에 설치된 최신 커널 버전의 경우 기본값은 0입니다. 사용 가능한 다음 커널은 "1>2"로 설정됩니다.vi /etc/default/grub GRUB_DEFAULT="1>2"참고
변수를 구성하는
GRUB_DEFAULT방법에 대한 자세한 내용은 SUSE 부팅 로더 GRUB2 및 Ubuntu Grub2/Setup을 참조하세요. 참조: 최상위 메뉴 값은 0이고, 첫 번째 최상위 하위 메뉴 값은 1이고, 중첩된 각 메뉴 엔트리 값은 0으로 시작합니다. 예를 들어 "1>2"는 첫 번째 하위 메뉴의 세 번째 메뉴입니다.GRUB 구성 파일을 다시 생성하여 변경 내용을 적용합니다. GRUB 다시 설치 및 해당 Linux 배포 및 VM 생성에 대한 GRUB 구성 파일 다시 생성 의 지침을 따릅니다.
커널 패닉 - 동기화되지 않음: VFS: 알 수 없는 블록에 루트 fs를 탑재할 수 없음(0,0)
이 오류는 최근 시스템 업데이트(커널)로 인해 발생합니다. RHEL 기반 배포판에서 가장 일반적으로 볼 수 있습니다. Azure 직렬 콘솔에서 이 문제를 식별할 수 있습니다. 다음 오류 메시지가 표시됩니다.
"커널 패닉 - 동기화되지 않음: VFS: 알 수 없는 블록에 루트 fs를 탑재할 수 없음(0,0)"
[ 301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G ------------ T 3.10.0-1160.36.2.el7.x86_64 #1 [ 301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 12/07/2018 [ 301.027122] Call Trace: [ 301.027122] [<ffffffff82383559>] dump_stack+0x19/0x1b [ 301.027122] [<ffffffff8237d261>] panic+0xe8/0x21f [ 301.027122] [<ffffffff8298b794>] mount_block_root+0x291/0x2a0 [ 301.027122] [<ffffffff8298b7f6>] mount_root+0x53/0x56 [ 301.027122] [<ffffffff8298b935>] prepare_namespace+0x13c/0x174 [ 301.027122] [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249 [ 301.027122] [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0 [ 301.027122] [<ffffffff82372350>] ? rest_init+0x80/0x80 [ 301.027122] [<ffffffff8237235e>] kernel_init+0xe/0x100 [ 301.027122] [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21 [ 301.027122] [<ffffffff82372350>] ? rest_init+0x80/0x80 [ 301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)"error: 파일 '/initramfs-*.img'을(를) 찾을 수 없습니다."
error: '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' 파일을 찾을 수 없습니다.
이러한 종류의 오류는 initramfs 파일이 생성되지 않았거나, GRUB 구성 파일에 패치 프로세스 후 initrd 항목이 누락되었거나, GRUB 수동 구성이 잘못 구성되었음을 나타냅니다.
서버를 다시 부팅하기 전에 다음 명령 중 하나를 실행하여 커널 업데이트가 있는 경우 GRUB 구성 및 /boot 콘텐츠의 유효성을 검사하는 것이 좋습니다. 업데이트가 완료되고 누락된 initramfs 파일이 없는지 확인하는 것이 중요합니다.
BIOS 기반 - Gen1 시스템
# ls -l /boot # cat /boot/grub2/grub.cfgUEFI 기반 - Gen2 시스템
# ls -l /boot # cat /boot/efi/EFI/*/grub.cfg
Azure Repair VM ALAR 스크립트를 사용하여 누락된 initramfs 다시 생성
Azure Cloud Shell 다음 Bash 명령줄을 실행하여 복구 VM을 만듭니다. 자세한 내용은 Azure Linux ALAR(자동 복구)를 사용하여 Linux VM - initrd 옵션 수정을 참조하세요.
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopyinitrd/initramfs 이미지를 다시 생성하고 initrd 항목이 누락된 경우 GRUB 구성 파일을 다시 생성합니다. 이렇게 하려면 다음 명령을 실행합니다.
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair az vm repair restore --verbose -g $RGNAME -n $VMNAME복원 명령이 실행되면 원래 VM을 다시 시작하고 부팅할 수 있는지 확인합니다.
누락된 initramfs를 수동으로 다시 생성
중요
- 이전 커널 버전을 사용하거나 복구/구조 VM에서 chroot 내부에서 VM을 부팅할 수 있는 경우 누락된 initramfs를 수동으로 다시 생성합니다.
- 복구 VM에서 누락된 initramfs를 수동으로 다시 생성하려면 오프라인 문제 해결 의 1단계가 이미 수행되었으며 이러한 명령이 chroot 내에서 실행되었는지 확인합니다.
부팅에 문제가 있는 특정 커널 버전을 식별합니다. 해당 커널 패닉 오류에서 버전 정보를 추출할 수 있습니다.
예제로 다음 스크린샷을 참조하세요. 커널 패닉 오류는 커널 버전이 "3.10.0-1160.59.1.el7.x86_64"임을 보여줍니다.
다음 명령 중 하나를 실행하여 누락된 initramfs 파일을 다시 생성합니다.
RHEL/CentOS/Oracle Linux 7/8
sudo depmod -a 3.10.0-1160.59.1.el7.x86_64 sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64중요
을 해당 커널 버전으로 바꿉 있습니다
3.10.0-1160.59.1.el7.x86_64.SLES 12/15
sudo depmod -a 5.3.18-150300.38.53-azure sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure중요
을 해당 커널 버전으로 바꿉 있습니다
5.3.18-150300.38.53-azure.Ubuntu 18.04
sudo depmod -a 5.4.0-1077-azure sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure중요
을 해당 커널 버전으로 바꿉 있습니다
5.4.0-1077-azure.
GRUB 구성 파일을 다시 생성합니다. GRUB 다시 설치 및 해당 Linux 배포 및 VM 생성에 대한 GRUB 구성 파일 다시 생성 의 지침을 따릅니다.
위의 단계가 복구 VM에서 수행되는 경우 오프라인 문제 해결의 3단계를 수행합니다. 위의 단계가 Azure 직렬 콘솔에서 수행되는 경우 온라인 문제 해결 방법을 따릅니다.
최신 커널 버전을 통해 VM을 다시 부팅합니다.
커널 패닉 - 동기화되지 않음: init를 죽이려고 시도했습니다.
Azure 직렬 콘솔에서 이 문제를 식별합니다. 다음과 같은 출력이 표시됩니다.
dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
[<ffffffff81558bfa>] ? panic+0xa7/0x18b
[<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
[<ffffffff81086433>] ? do_exit+0x853/0x860
[<ffffffff811a33b5>] ? fput+0x25/0x30
[<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
[<ffffffff81086498>] ? do_group_exit+0x58/0xd0
[<ffffffff81086527>] ? sys_exit_group+0x17/0x20
[<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
[<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152
이러한 종류의 커널 패닉은 다음과 같은 가능한 원인으로 인해 발생합니다.
원인 세부 정보 및 해결 방법은 다음 섹션을 참조하세요. 오프라인 문제 해결에 지시된 대로 크로트 환경 내의 복구/구조 VM에서 명령이 실행되었는지 확인합니다.
중요한 파일 및 디렉터리 누락
중요한 Linux 파일 및 디렉터리에서 인적 오류로 인해 누락되었습니다. 예를 들어 파일이 실수로 삭제되거나 파일 시스템 손상이 발생합니다.
OS 디스크의 복사본을 복구 VM에 연결하고 chroot를 사용하여 해당 파일 시스템을 탑재한 후 OS 디스크 콘텐츠의 유효성을 검사합니다. 출력을 동일한 OS 버전을 실행하는 작업 VM의 출력과 비교할 수 있습니다.
ls -l / ls -l /usr/lib ls -l /usr/lib64 ls -lR / | more백업에서 누락된 파일을 복원합니다. 자세한 내용은 Azure 가상 머신 백업에서 파일 복구를 참조하세요. 누락된 파일 수에 따라 전체 VM 복원을 수행하는 것이 더 나을 수 있습니다. 자세한 내용은 Azure Portal Azure VM 데이터를 복원하는 방법을 참조하세요.
중요한 시스템 핵심 라이브러리 및 패키지 누락
중요한 시스템 핵심 라이브러리, 파일 또는 패키지는 시스템에서 삭제되거나 손상됩니다. 이 문제를 resolve 영향을 받는 라이브러리, 파일 또는 패키지를 다시 설치합니다. 이 솔루션은 Red Hat/CentOS/SUSE VM과 같은 RPM 기반 배포판에서 작동합니다. 다른 Linux 배포의 경우 백업에서 VM을 복원하는 것이 좋습니다.
다시 설치를 수행하려면 다음 단계를 수행합니다.
영향을 받는 VM과 동일한 OS 버전 및 생성이 있는 원시 이미지를 사용하여 구조 VM을 만듭니다.
복구 VM의 chroot 환경에 액세스하여 문제를 해결합니다.
sudo chroot /rescue명령 출력은 아래와 같이 누락되거나 손상된 라이브러리를 나타냅니다.
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory구조 VM의 모든 시스템 패키지 및 해당 상태 확인합니다. 출력을 동일한 OS 버전을 실행하는 정상 VM과 비교합니다.
sudo rpm --verify --all --root=/rescue다음은 명령 출력의 예입니다.
error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE S.5....T. c /etc/dnf/dnf.conf S.5....T. c /etc/ssh/sshd_config .M....... /boot/efi/EFI/BOOT/BOOTX64.EFI .M....... /boot/efi/EFI/BOOT/fbx64.efi .M....... /boot/efi/EFI/redhat/BOOTX64.CSV .M....... /boot/efi/EFI/redhat/mmx64.efi .M....... /boot/efi/EFI/redhat/shimx64-redhat.efi .M....... /boot/efi/EFI/redhat/shimx64.efi missing /run/motd.d .M....... g /var/spool/anacron/cron.daily .M....... g /var/spool/anacron/cron.monthly .M....... g /var/spool/anacron/cron.weekly missing /lib64/libc-2.28.so <------- .M....... /boot/efi/EFI/redhat S.5....T. c /etc/security/pwquality.conf출력 줄
missing /lib64/libc-2.28.so은 2단계의 이전 오류와 관련이 있으며 libc-2.28.so 패키지가 없음을 나타냅니다. 그러나 libc-2.28.so 패키지를 수정할 수 있습니다. 이 경우 출력은 대신missing표시됩니다.M...... libc-2.28.so 패키지는 다음 단계의 예제로 참조됩니다.구조 VM에서 라이브러리 /lib64/libc-2.28.so가 포함된 패키지를 확인합니다.
sudo rpm -qf /lib64/libc-2.28.soglibc-2.28-127.0.1.el8.x86_64참고
출력에는 패키지 이름 및 버전을 포함하여 다시 설치해야 하는 패키지가 표시됩니다. 패키지 버전은 영향을 받는 VM에 설치된 버전과 다를 수 있습니다.
영향을 받는 VM에서 설치된 glibc 패키지 버전을 확인합니다.
sudo rpm -qa --all --root=/rescue | grep -i glibcglibc-common-2.28-211.0.1.el8.x86_64 glibc-gconv-extra-2.28-211.0.1.el8.x86_64 glibc-2.28-211.0.1.el8.x86_64 <---- glibc-langpack-en-2.28-211.0.1.el8.x86_64glibc-2.28-211.0.1.el8.x86_64 패키지를 다운로드합니다. 운영 체제 공급업체의 공식 웹 사이트나 실행 중인 OS에 따라 패키지
yumdownloaderzypper install --download-only <packagename>관리 도구를 사용하여 복구 VM에서 다운로드할 수 있습니다.도구를 사용하는
yumdownloader예제는 다음과 같습니다.cd /tmp sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC. glibc-2.28-211.0.1.el8.x86_64.rpm 8.7 MB/s | 2.2 MB 00:00영향을 받는 패키지를 구조 VM에 다시 설치합니다.
sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefileswarning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:glibc-2.28-211.0.1.el8 ################################# [100%]구조 VM의 chroot 환경에 액세스하여 다시 설치의 유효성을 검사합니다.
sudo chroot /rescue복구 VM을 끄고 OS 디스크를 영향을 받는 VM으로 교환합니다.
잘못된 파일 권한
잘못된 시스템 전체 파일 사용 권한은 사용자 오류(예: 누군가가 또는 다른 중요한 OS 파일 시스템에서 실행 chmod 777/ 됨)로 인해 수정됩니다. 이 문제를 resolve 파일 권한을 복원합니다. 이 솔루션은 Red Hat/CentOS/SUSE VM과 같은 RPM 기반 배포판에서 작동합니다. 다른 Linux 배포의 경우 백업에서 VM을 복원하는 것이 좋습니다.
파일 권한을 복원하려면 OS 디스크의 복사본을 복구 VM에 연결하고 chroot를 사용하여 해당 파일 시스템을 탑재한 후 다음 명령을 실행합니다.
rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key
참고
프로덕션 시스템을 실행하는 경우 이 명령을 실행하지 마세요.
해당 파일 권한을 수동으로 복구한 후에도 문제가 계속 발생하는 경우 백업에서 복원을 수행합니다.
누락된 파티션
, , /opt, /var, /home, /tmp및 / 파일 시스템이 여러 파티션에 분산되어 있는 경우 /usr파티션 크기 조정 작업 중 실수로 인해 발생할 수 있는 파티션 수준의 문제로 인해 데이터에 액세스할 수 없을 수 있습니다.
이 시나리오에서는 원래 파티션 테이블 레이아웃을 각 원래 파티션에 대한 정확한 시작 및 끝 섹터로 문서화하고 새 파일 시스템 만들기와 같이 시스템에서 더 이상 수정하지 않는 경우 fdisk (MBR 파티션 테이블의 경우) 또는 gdisk (GPT 파티션 테이블용)와 같은 도구와 동일한 원래 레이아웃을 사용하여 파티션을 다시 만들어 누락된 파일 시스템에 액세스할 수 있습니다.
이 방법이 작동하지 않으면 백업에서 복원을 수행합니다.
SELinux 문제
잘못된 SELinux 권한으로 인해 시스템에서 중요한 파일에 액세스하지 못할 수 있습니다. 이 문제를 resolve 다음 단계를 수행합니다.
잘못된 SELinux 권한으로 인해 시스템에 문제가 있는지 확인하려면 SELinux=0 커널 옵션을 GRUB linux16 줄에 추가하여 SELinux를 사용하지 않도록 설정하여 시스템을 시작합니다.
시스템이 부팅할 수 있는 경우 다음 명령을 실행하여 부팅 시 SELinux 레이블을 트리거하고 시스템을 다시 부팅합니다.
touch /.autorelabelVM이 여전히 부팅할 수 없는 경우 백업에서 전체 VM 복원을 수행합니다. 자세한 내용은 Azure Portal Azure VM 데이터를 복원하는 방법을 참조하세요.
기타 커널 관련 부팅 문제
이 문서에서는 Azure에서 식별된 가장 일반적인 Linux 커널 패닉에 대해 설명합니다. 일반적인 커널 패닉 시나리오에 대한 자세한 내용은 Azure Linux VM의 커널 패닉 - 일반적인 커널 패닉 이벤트를 참조하세요.
부팅이 없거나 SSH(보안 셸) 시나리오를 유발하지 않을 수 있는 다른 중요한 커널 패닉이 있습니다.
오프라인 문제 해결에 지시된 대로 chroot 환경 내의 복구 VM에서 명령을 실행해야 합니다. 시스템이 이미 이전 커널 버전을 통해 부팅된 경우 온라인 문제 해결에 지시된 대로 루트 권한 또는 sudo를 사용하여 원래 VM에서 이러한 명령을 실행할 수도 있습니다.
최근 커널 업그레이드
최근 커널 업그레이드 후 커널 패닉이 시작되면 이전 커널 버전에서 VM을 부팅합니다. 자세한 내용은 이전 커널 버전의 부팅 시스템을 참조하세요.
Linux 배포 공급업체에서 릴리스한 최신 커널 버전이 이미 있는 경우 검사 설치할 수도 있습니다. 최신 커널 버전을 설치하는 방법에 대한 자세한 내용은 커널 업데이트 프로세스를 참조하세요.
최근 커널 다운그레이드
최근 커널 다운그레이드 후 커널 패닉이 시작되면 설치된 최신 커널로 돌아갑니다. Linux 배포 공급업체에서 릴리스한 최신 커널 버전이 이미 있는 경우 검사 설치할 수도 있습니다. 최신 커널 버전을 설치하는 방법에 대한 자세한 내용은 커널 업데이트 프로세스를 참조하세요.
최신 커널 버전을 통해 시스템을 부팅하려면 기본 커널 버전 수동으로 변경의 지침을 따르지만 GRUB 메뉴에 나열된 첫 번째 커널을 선택합니다. 수동으로 수정할 때 값을 0으로 설정하고 GRUB_DEFAULT 해당 GRUB 구성 파일을 다시 생성할 수 있습니다.
커널 모듈 변경 내용
새 커널 모듈 또는 누락된 커널 모듈과 관련된 커널 패닉이 발생할 수 있습니다. 문제를 일으키는 특정 커널 모듈에 대한 세부 정보를 얻으려면(있는 경우) 해당 커널 패닉 추적을 검사.
/etc/modprobe.d/*.conf 파일에서 로드된 커널 모듈 및 비활성화된 모듈의 유효성을 검사하려면 다음 명령 중 하나를 실행합니다.
RHEL/CentOS/Oracle Linux 7/8
lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img lsmod cat /etc/modprobe.d/*.conf중요
을 해당 커널 버전으로 바꿉 있습니다
3.10.0-1160.59.1.el7.x86_64.SLES 12/15
lsinitrd /boot/initrd-5.3.18-150300.38.53-azure lsmod cat /etc/modprobe.d/*.conf중요
을 해당 커널 버전으로 바꿉 있습니다
5.3.18-150300.38.53-azure.Ubuntu 18.04
lsinitramfs /boot/initrd.img-5.4.0-1077-azure lsmod cat /etc/modprobe.d/*.conf중요
을 해당 커널 버전으로 바꿉 있습니다
5.4.0-1077-azure.
특정 커널 모듈을 제거하려면 다음 명령을 실행하고 필요한 경우 initramfs를 다시 생성합니다 .
rmmod <kernel_module_name>
시스템 서비스에서 특정 커널 모듈을 사용하는 경우 또는 systemctl stop <serviceName> 명령을 실행 systemctl disable <serviceName> 하여 사용하지 않도록 설정합니다.
운영 체제 최근 구성 변경
문제를 일으킬 수 있는 최근 커널 구성 변경 내용을 식별합니다. 문제를 resolve 해당 설정을 조정하거나 구성 변경 내용을 롤백합니다.
다음 명령을 실행하여 다음 파일 중에서 구성된 영구 커널 매개 변수를 찾습니다.
cat /etc/systctl.conf
cat /etc/sysctl.d/*
다음 명령을 실행하여 현재 커널 매개 변수 및 해당 현재 값을 분석합니다.
sysctl -a
참고
chroot 환경이 아닌 실행 중인 시스템에서 이 명령을 실행합니다.
누락 가능한 파일
이러한 종류의 문제에 대한 자세한 내용은 중요한 파일 및 디렉터리 누락을 참조하세요.
파일에 대한 잘못된 권한
이러한 종류의 문제에 대한 자세한 내용은 잘못된 파일 권한을 참조하세요.
누락된 파티션
이러한 종류의 문제에 대한 자세한 내용은 누락된 파티션을 참조하세요.
커널 버그
Azure 직렬 콘솔에서 이 문제를 식별합니다. 이러한 종류의 문제는 다음 출력과 같습니다.
[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP
이러한 종류의 커널 패닉은 커널 버그 또는 타사 커널 버그와 관련이 있습니다.
커널 버그를 해결하려면 커널 BUG 문자열을 사용하여 공급업체 기술 자료를 검색하고 시스템이 실행 중인 해당 커널 버전에서 알려진 문제를 찾습니다. 다음은 몇 가지 중요한 공급업체 리소스입니다.
-
이 도구는 커널 크래시 진단에 도움이 되도록 설계되었습니다. 텍스트, vmcore-dmesg.txt또는 하나 이상의 커널 oops 메시지를 포함하는 파일을 입력하면 커널 크래시 문제를 진단하는 단계를 안내합니다.
-
Red Hat 리소스에 액세스하려면 Microsoft Azure 및 Red Hat 계정을 연결합니다. 자세한 내용은 Microsoft Azure 고객이 Red Hat 고객 포털에 액세스할 수 있는 방법을 참조하세요.
최신 커널 버전에서 이미 수정된 가능한 버그를 제외하려면 모든 시스템을 최신 상태로 유지하는 것이 좋습니다. 자세한 내용은 커널 업데이트 프로세스를 참조하세요.
공급업체에서 추가 분석이 필요한 경우 kdump를 구성하고 사용하도록 설정하여 코어 덤프를 생성합니다.
커널 업데이트 프로세스
사용 가능한 최신 커널 버전을 설치하려면 다음 명령 중 하나를 실행합니다.
RHEL/CentOS/Oracle Linux
yum update kernelSLES 12/15
zypper refresh zypper update kernel*Ubuntu 18.04/20.04
apt update apt install linux-azure
특정 커널 버전을 다시 설치하려면 다음 명령 중 하나를 실행합니다. 다시 설치하려는 동일한 커널 버전에서 부팅되지 않았는지 확인합니다. 자세한 내용은 이전 커널 버전의 부팅 시스템을 참조하세요.
RHEL/CentOS/Oracle Linux
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64중요
을 해당 커널 버전으로 바꿉 있습니다
3.10.0-1160.59.1.el7.x86_64.SLES 12/15
zypper refresh zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64중요
을 해당 커널 버전으로 바꿉 있습니다
kernel-azure-5.3.18-150300.38.75.1.x86_64.Ubuntu 18.04/20.04
apt update apt install --reinstall linux-azure=5.4.0.1091.68중요
을 해당 커널 버전으로 바꿉 있습니다
5.4.0.1091.68.
시스템을 업데이트하고 사용 가능한 최신 변경 내용을 적용하려면 다음 명령 중 하나를 실행합니다.
RHEL/CentOS/Oracle Linux
yum updateSLES 12/15
zypper refresh zypper updateUbuntu 18.04/20.04
apt update apt upgrade
커널 패닉은 다음 항목과 관련이 있을 수 있습니다. 자세한 내용은 런타임 시 커널 패닉을 참조하세요.
- 애플리케이션 워크로드가 변경됩니다.
- 애플리케이션 개발 또는 애플리케이션 버그.
- 성능 관련 문제 등
다음 단계
특정 부팅 오류가 커널 관련 부팅 문제가 아닌 경우 추가 문제 해결 옵션은 Azure Linux Virtual Machines 부팅 오류 문제 해결을 참조하세요.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기