커널 변경 내용을 적용한 후 Azure Linux 가상 머신이 부팅되지 않습니다.
적용 대상: ✔️ Linux VM
참고 항목
이 문서에서 참조하는 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을 복원하여 부팅 문제를 해결합니다.
직렬 콘솔은 부팅 문제를 해결하는 가장 빠른 방법입니다. 이를 통해 복구 VM에 시스템 디스크를 표시하지 않고도 문제를 직접 해결할 수 있습니다. 배포에 필요한 필수 조건을 충족하는지 확인합니다. 자세한 내용은 Linux용 가상 머신 직렬 콘솔을 참조하세요.
특정 커널 관련 부팅 문제를 식별합니다.
Azure 직렬 콘솔을 사용하여 GRUB 메뉴에서 VM을 중단하고 이전 커널을 선택하여 부팅합니다. 자세한 내용은 이전 커널 버전의 부팅 시스템을 참조하세요.
해당 섹션으로 이동하여 특정 커널 관련 부팅 문제를 해결합니다.
커널 관련 부팅 문제가 해결된 후 최신 커널 버전을 통해 부팅할 수 있도록 VM을 다시 시작합니다.
오프라인문제 해결
팁
VM 의 최근 백업이 있는 경우 백업 에서 VM을 복원하여 부팅 문제를 해결합니다.
Azure 직렬 콘솔이 특정 VM에서 작동하지 않거나 구독의 옵션이 아닌 경우 복구/복구 VM을 사용하여 부팅 문제를 해결합니다. 이렇게 하려면 다음 단계를 수행하세요.
vm 복구 명령을 사용하여 영향을 받는 VM의 OS 디스크 복사본이 연결된 복구 VM을 만듭니다. 크로트를 사용하여 복구 VM에 OS 파일 시스템의 복사본을 탑재합니다.
참고 항목
또는 Azure Portal 사용하여 구조 VM을 수동으로 만들 수 있습니다. 자자세한 내용은 Azure Portal을 사용하여 OS 디스크를 복구 VM에 연결함으로써 Linux VM 문제 해결을 참조하세요.
특정 커널 관련 부팅 문제를 식별합니다.
해당 섹션으로 이동하여 특정 커널 관련 부팅 문제를 해결합니다.
커널 관련 부팅 문제가 해결된 후 다음 작업을 수행합니다.
- 크로트를 종료합니다.
- 복구/복구 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을 만듭니다. 자세한 내용은 Azure Linux ALAR(자동 복구)를 사용하여 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(크로엇 내부) 또는 실행 중인 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를 수동으로 다시 생성
Important
부팅에 문제가 있는 특정 커널 버전을 식별합니다. 해당 커널 패닉 오류에서 버전 정보를 추출할 수 있습니다.
예제로 다음 스크린샷을 참조하세요. 커널 패닉 오류는 커널 버전이 "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_64Important
해당 커널 버전으로 바꿉다
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-azureImportant
해당 커널 버전으로 바꿉다
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-azureImportant
해당 커널 버전으로 바꿉다
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 데이터를 복원하는 방법을 참조 하세요.
중요한 시스템 핵심 라이브러리 및 패키지 누락
중요한 시스템 핵심 라이브러리, 파일 또는 패키지는 시스템에서 삭제되거나 손상됩니다. 이 문제를 해결하려면 영향을 받는 라이브러리, 파일 또는 패키지를 다시 설치합니다. 이 솔루션은 Red Hat/CentOS/SUSE VM과 같은 RPM 기반 배포에서 작동합니다. 다른 Linux 배포의 경우 백업에서 VM을 복원하는 것이 좋습니다.
다시 설치를 수행하려면 다음 단계를 수행합니다.
영향을 받는 VM과 OS 버전 및 생성이 동일한 원시 이미지를 사용하여 구조 VM을 만듭니다.
복구 VM의 크로엇 환경에 액세스하여 문제를 해결합니다.
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 패키지를 수정할 수 있습니다. 이 경우 출력.M.....missing은 . 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_64패키지 glibc-2.28-211.0.1.el8.x86_64 다운로드합니다. OS 공급업체의 공식 웹 사이트나 실행 중인 OS에 따라 패키지 관리 도구를
yumdownloaderzypper install --download-only <packagename>사용하여 복구 VM에서 다운로드할 수 있습니다.도구를 사용하는 예제는 다음과 같습니다.
yumdownloadercd /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의 크로엇 환경에 액세스하여 다시 설치의 유효성을 검사합니다.
sudo chroot /rescue복구 VM을 끄고 OS 디스크를 영향을 받는 VM으로 교환합니다.
잘못된 파일 권한
잘못된 시스템 전체 파일 사용 권한은 사용자 오류(예: 다른 중요한 OS 파일 시스템에서 실행 chmod 777 / 됨)로 인해 수정됩니다. 이 문제를 해결하려면 파일 권한을 복원합니다. 이 솔루션은 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 권한으로 인해 시스템에서 중요한 파일에 액세스하지 못할 수 있습니다. 이 문제를 해결하려면 다음 단계를 따릅니다.
잘못된 SELinux 권한으로 인해 시스템에 문제가 있는지 확인하려면 GRUB linux16 줄에 selinux=0 커널 옵션을 추가하여 SELinux를 사용하지 않도록 설정하여 시스템을 시작합니다.
시스템이 부팅할 수 있는 경우 다음 명령을 실행하여 부팅 시 SELinux 다시 레이블을 트리거하고 시스템을 다시 부팅합니다.
touch /.autorelabelVM이 여전히 부팅할 수 없는 경우 백업에서 전체 VM 복원을 수행합니다. 자세한 내용은 Azure Portal에서 Azure VM 데이터를 복원하는 방법을 참조 하세요.
기타 커널 관련 부팅 문제
이 문서에서는 Azure에서 식별되는 가장 일반적인 Linux 커널 패닉에 대해 설명합니다. 일반적인 커널 패닉 시나리오에 대한 자세한 내용은 Azure Linux VM의 커널 패닉 - 일반적인 커널 패닉 이벤트를 참조 하세요.
부팅되지 않거나 SSH(보안 셸) 시나리오를 발생시킬 수 있는 다른 중요한 커널 패닉이 있습니다.
오프라인 문제 해결에 설명된 대로 크로엇 환경 내의 복구 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/*.confImportant
해당 커널 버전으로 바꿉다
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/*.confImportant
해당 커널 버전으로 바꿉다
5.3.18-150300.38.53-azure.Ubuntu 18.04
lsinitramfs /boot/initrd.img-5.4.0-1077-azure lsmod cat /etc/modprobe.d/*.confImportant
해당 커널 버전으로 바꿉다
5.4.0-1077-azure.
특정 커널 모듈을 제거하려면 다음 명령을 실행하고 필요한 경우 initramfs를 다시 생성합니다 .
rmmod <kernel_module_name>
시스템 서비스에서 특정 커널 모듈을 사용하는 경우 또는 systemctl stop <serviceName> 명령을 실행 systemctl disable <serviceName> 하여 사용하지 않도록 설정합니다.
운영 체제의 최근 구성 변경 내용
문제를 일으킬 수 있는 최근 커널 구성 변경 내용을 식별합니다. 문제를 해결하려면 해당 설정을 조정하거나 구성 변경 내용을 롤백합니다.
다음 명령을 실행하여 다음 파일 중에서 구성된 영구 커널 매개 변수를 찾습니다.
cat /etc/systctl.conf
cat /etc/sysctl.d/*
다음 명령을 실행하여 현재 커널 매개 변수 및 해당 현재 값을 분석합니다.
sysctl -a
참고 항목
크로트 환경이 아닌 실행 중인 시스템에서 이 명령을 실행합니다.
누락된 파일 수
이러한 종류의 문제에 대한 자세한 내용은 중요한 파일 및 디렉터리 누락을 참조 하세요.
파일에 대한 잘못된 권한
이러한 종류의 문제에 대한 자세한 내용은 잘못된 파일 권한을 참조 하세요.
누락된 파티션
이러한 종류의 문제에 대한 자세한 내용은 누락된 파티션을 참조 하세요.
커널 버그
Azure 직렬 콘솔에서 이 문제를 식별합니다. 이러한 종류의 문제는 다음 출력과 같습니다.
[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP
이러한 종류의 커널 패닉은 커널 버그 또는 타사 커널 버그와 관련이 있습니다.
커널 버그를 해결하려면 커널 BUG 문자열을 사용하여 공급업체 기술 자료를 검색하고 시스템이 실행 중인 해당 커널 버전에서 알려진 문제를 찾습니다. 다음은 몇 가지 중요한 공급업체 리소스입니다.
-
이 도구는 커널 크래시 진단에 도움이 되도록 설계되었습니다. 하나 이상의 커널 oops 메시지를 포함하여 텍스트, vmcore-dmesg.txt 또는 파일을 입력하면 커널 크래시 문제를 진단하는 단계를 안내합니다.
-
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_64Important
해당 커널 버전으로 바꿉다
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_64Important
해당 커널 버전으로 바꿉다
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.68Important
해당 커널 버전으로 바꿉다
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 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.