파일 컴퓨터 오류로 인한 Linux 가상 머신 부팅 문제 해결

아티클
04/01/2024

적용 대상: ✔️ Linux VM

이 문서에서는 파일 시스템 오류로 인한 Linux VM(가상 머신) 부팅 문제를 해결하기 위한 지침을 제공합니다.

증상

SSH(Secure Shell Protocol)를 사용하여 Azure Linux VM(가상 머신)에 연결할 수 없거나 Azure Portal의 VM 에이전트 상태가 준비되지 않았습니다. Azure Portal에서 부팅 진단을 실행하거나 직렬 콘솔에 연결하는 경우 다음 예제와 유사한 로그 항목이 표시됩니다.

참고 항목

모든 예제가 있는 것은 아닙니다.
탑재 실패가 항상 VM이 비상 모드로 전환되는 것은 아닙니다. 특정 중요한 파일 시스템에 문제가 있는 경우 VM은 긴급 모드를 사용하지 않을 수 있습니다.

예제 1: ext4 파일 시스템 탑재 실패

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.

예제 2: LVM(ext Logical Volume Manager) 디바이스 탑재 실패

[   14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[   14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.

예제 3: xfs 파일 시스템 탑재 실패

[    8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[    8.553867] XFS (sdc1): Unmount and run xfs_repair
[    8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[    8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0  XAGI............
[    8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d  ...@...........=
[    8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff  ...`............
[    8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[    8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.

예제 4: 응급 모드로 부팅

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

원인

위의 로그 항목은 디스크 손상을 나타냅니다. 특정 상황에서 디스크 손상으로 인해 VM이 완전히 부팅되지 않습니다. Linux 커널 문제, 드라이버 오류, 기본 물리적 또는 가상 하드웨어의 오류 등과 같은 다양한 문제로 인해 디스크가 손상될 수 있습니다.

해결

파일 시스템 오류로 인한 Linux VM 부팅 문제를 해결하려면 디스크 손상을 복구하여 VM을 복구합니다. 디스크 손상을 복구하려면 다음 단계를 수행합니다.

손상된 디스크를 식별합니다.
파일 시스템 유형을 식별합니다.
복구 모드(온라인 또는 오프라인)를 선택합니다.
선택한 복구 모드에 따라 복구 환경을 준비합니다.
- 온라인 복구를 위한 환경 준비
- 오프라인 복구를 위한 환경 준비
명령줄 도구를 사용하여 디스크에서 문제가 있는 파일 시스템을 복구합니다.
- ext4 파일 시스템 복구
- xfs 파일 시스템 복구
참고 항목
- 복구된 디스크에서 데이터 손실이 발생할 수 있으므로 중요한 데이터를 백업하는 것이 중요합니다.
- 디스크를 변경하기 전에 스냅샷을 만들어 오류 상태인 경우에도 디스크의 현재 상태를 유지합니다. 디스크 손상을 수정하면 디스크의 데이터가 변경되어 위험이 발생합니다.

손상된 디스크 식별

손상된 디스크를 확인하려면 직렬 콘솔 또는 부팅 진단을 사용하여 VM에 대한 직렬 로그를 다운로드하고 부팅하는 동안 로그 항목을 검사한 다음 실패하는 디스크 또는 탑재를 호출하는 특정 오류를 찾습니다.

다음은 세 가지 로그 항목 예제입니다. 이 예제에서는 손상된 디바이스를 보고하는 괄호로 된 텍스트를 기록해 둡니다.

다음 예제에서 손상된 디바이스는 다음과 같습니다 sdc1.

[   14.285807] XFS (sdc1): Mounting V5 Filesystem
[   14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[   14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.

다음 예제에서는 파일 시스템 오류가 발생하는 파티션은 다음과 같습니다 sda1.

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.

다음 예제에서 손상된 디바이스는 .입니다 dm-2. LVM 볼륨을 나타내는 Linux 디바이스 매퍼 디바이스입니다.

[   18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.

호출되는 디스크 디바이스에서 X가 a-z의 문자이고 N이 선택적 파티션 번호인 "sdXN" 형식의 이름을 사용하는 경우 디스크가 원시이며 /dev/sdXN 경로를 사용하여 작동할 수 있음을 의미합니다.

탑재되는 디스크 디바이스가 /dev/mapper/vgname/lvname, /dev/vgname/lvname 또는 dm-N과 같은 이름을 사용하는 경우 LVM 디바이스가 사용됨을 의미합니다. 사용 중인 모든 디스크 물리적 볼륨(PV)을 인식합니다.

LVM 볼륨 그룹(VG)이 OS 디스크 및 데이터 디스크 수를 포함하는 것은 지원되지 않습니다. 이러한 시나리오의 경우 데이터 손실 위험이 높습니다. 그러나 여러 데이터 디스크는 LVM VG에서 허용됩니다.

Azure 디스크 개체에 대한 OS 디스크 참조의 매핑을 결정하는 경우:

마켓플레이스 이미지의 경우 루트 파일 시스템(/), /boot 및 /boot/efi가 OS 디스크에 있습니다.
LVM 기반 이미지의 경우 /home, /tmp, /usr, /var, /var/log 및 /opt와 같은 다른 많은 시스템 탑재가 존재할 수 있습니다.
애플리케이션용으로 만든 추가 파일 시스템은 데이터 디스크(예: /data, /datadisk 또는 /sap)에 있습니다. 오류가 발생하더라도 시스템이 부팅할 수 있도록 올바르게 구성합니다. 데이터 디스크가 비상 모드로 부팅되는 디바이스인 경우 부팅 실패 방지를 참조하세요.

파일 시스템 형식 식별

초기 식별을 수행하는 동안 디스크 유형을 확인하는 유일한 방법은 손상된 디스크 식별에서 이전에 검사한 대로 직렬 로그를 사용하는 것입니다. 디스크 디바이스가 직렬 로그에 보고되면 파일 시스템에 대한 Linux 커널 모듈에서 오류가 표시됩니다. 위치 EXT4-fs 또는 XFS 지정된 각 줄을 확인합니다. 다른 파일 시스템 형식의 경우 로그는 동일한 영역에 있습니다. 로그 항목에 기록된 파일 시스템은 /etc/fstab 파일에 의해 결정됩니다. 복구를 수행할 때 지정된 형식이 올바른지 확인합니다.

대화형 셸에 액세스할 수 있으면 다음과 같이 플래그를 -f 사용하여 명령을 실행 lsblk 하여 디바이스, 경로(파일 시스템이 탑재된 경우) 및 디스크 자체에서 읽은 파일 시스템 유형을 표시합니다.

[root@localhost ~]# lsblk -f
NAME              FSTYPE      LABEL UUID                                   MOUNTPOINT
sda
|-sda1            vfat              93DA-8C20                              /boot/efi
|-sda2            xfs               d5da486e-fdfe-4ad8-bc01-aa72b91fd47d   /boot
|-sda3
`-sda4            LVM2_member       pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
  |-rootvg-tmplv  xfs               9098eb05-0176-4997-8132-9152a7bef207   /tmp
  |-rootvg-usrlv  xfs               2f9ff36c-742d-4914-b463-d4152801b95d   /usr
  |-rootvg-optlv  xfs               aeacea8e-3663-4569-af25-c52357f8a0a3   /opt
  |-rootvg-homelv xfs               a79e43dc-7adc-41b4-b6e1-4e6b033b15c0
  |-rootvg-varlv  xfs               c7cb68e9-7865-4187-b3bd-e9a869779d86   /var
  `-rootvg-rootlv xfs               d8dc4d62-ada5-4952-a0d9-1bce6cb6f809   /
sdb
`-sdb1            ext4              1dac7c4c-bf8e-4964-8a59-7359eef53d0a   /mnt
sdc               LVM2_member       CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp     xfs               733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1            ext4              704d9fb1-2207-4bb9-998c-029f776dc6d2   /opt/data

출력의 몇 가지 중요한 점은 다음과 같습니다.

ASCII 아트 디스플레이를 사용하면 이름과 같은 rootvg-rootlv rootvg-homelv개체가 포함된 sda4에 대한 LVM2_MEMBER FSTYPE이 있기 때문에 LVM 볼륨이 있음을 알 수 있습니다.
rootvg-homelv 가 탑재되지 않습니다. 이 값은 빈 MOUNTPOINT 필드로 표시됩니다.
rootvg-homelv 에는 파일 시스템 형식 XFS가 있습니다. 부팅하는 동안 EXT4 탑재 오류와는 대조적입니다. 파일 시스템 형식이 일치하지 않는 경우 fstab의 내용이 아닌 출력을 신뢰 lsblk 합니다.

복구 모드 선택

복구 VM을 사용하여 긴급 모드 또는 단일 사용자 모드 또는 오프라인을 통해 온라인으로 VM을 복구할 수 있습니다.

온라인 복구에 대한 요구 사항

VM에 대한 직렬 콘솔 액세스입니다.
긴급 모드를 사용하는 경우 직렬 콘솔에 긴급 모드 프롬프트가 표시되어야 하고, 루트 계정의 잠금을 해제해야 하며, 암호를 알고 있어야 합니다.
단일 사용자 모드를 사용하는 경우 루트 암호가 필요하지 않습니다. 단일 사용자 모드는 루트(/) /usr 와 같은 필수 시스템 파티션 이외의 파일 시스템이 손상되었을 때 사용될 수 있습니다.

오프라인 복구에 대한 요구 사항

온라인 복구에 대한 직렬 콘솔 요구 사항을 충족할 수 없는 경우 복구 VM을 사용하여 오프라인 복구를 수행합니다. 오프라인 복구를 수행하려면 Azure에서 VM을 만들고 디스크를 관리하는 기능이 필요합니다. 또는 손상된 디스크에 대한 Azure 수준 액세스와 함께 작동하는 Linux VM을 사용할 수 있습니다.

온라인 복구를 위한 환경 준비

비상 모드가 다음과 같이 로그인 프롬프트에 표시되면 루트 암호를 입력합니다.

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):

다음 출력과 같이 루트 암호를 알 수 없거나 루트 계정이 잠긴 경우 단일 사용자 모드를 사용합니다.

Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

온라인 복구 환경을 사용할 수 없는 경우 오프라인 복구를 진행합니다.

오프라인 복구를 위한 환경 준비

단일 디스크 VM에서 또는 실패한 탑재가 루트 파일 시스템(/)와 같은 시스템 파티션이거나 /usr디스크를 복구하는 가장 신뢰할 수 있는 방법은 복구 VM을 사용하여 디스크에 액세스하는 것입니다. 복구 VM을 자동으로 또는 수동으로 만들 수 있습니다.

구조 VM의 자동화된 생성은 Azure Virtual Machine 복구를 참조 하세요. 복구 VM을 수동으로 만들려면 복구 VM 만들기를 참조 하세요. 두 경우 모두 복구 유틸리티가 작동하려면 파일 시스템을 탑재하지 않아야 하므로 문제 디스크에서 볼륨을 탑재하지 마세요.

파일 시스템 복구 수행

파일 시스템을 복구하기 전에 다음 단계가 완료되었는지 확인합니다.

문제 디스크 및 파티션 또는 LVM 볼륨 구조가 식별되었습니다.
파일 시스템 형식이 결정되었습니다.
(선택 사항) 문제 디스크의 복사본 또는 스팬된 LVM 볼륨 그룹의 디스크가 복구 VM에 연결되었습니다.
대화형 셸에 대한 액세스는 디스크에 대한 액세스를 사용하여 보호되었습니다.

파일 시스템 복구를 수행하려면 파일 시스템 유형에 따라 ext4 파일 시스템 복구 또는 XFS 파일 시스템 복구로 이동합니다.

어떤 복구 모드를 사용하든 파일 시스템 복구를 수행하는 명령은 동일합니다. 긴급 포탄에는 제한 사항이 있을 수 있습니다. 긴급 모드 환경에서 명령을 사용할 수 없거나 알 수 없는 파일 시스템 유형 에 대한 오류가 있는 경우 오프라인 복구를 위한 환경을 준비합니다.

파일 시스템을 복구하는 명령은 모든 오류를 수정하지 않을 수 있습니다. 디스크 손상을 해결하지만 데이터 손실은 여전히 발생할 수 있습니다. 명령 출력에 파일 시스템이 정리되어 있다고 표시되면 복구된 디스크를 사용하여 원래 VM을 다시 조립하고 VM을 부팅하여 데이터를 확인합니다.

다음 섹션에서 /dev/sdc1 는 원시 모드의 손상된 파일 시스템이며 VG rootvg 의 LV homelv 는 LVM 볼륨입니다. 모든 인스턴스에서 실제 손상된 파일 시스템에 대해 이러한 값을 대체합니다.

ext4 파일 시스템 복구

명령을 fsck [-y] FILESYSTEM 사용하여 ext4 파일 시스템을 복구합니다. 파일 시스템을 원시 파일 시스템의 디스크 파티션(예 /dev/sdc1: LVM 논리 볼륨 경로 /dev/rootvg/homelv)으로 지정합니다.

다음은 명령 출력 예제입니다.

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#

출력은 파일 시스템을 수정하기 위한 확인이 세 번 요청되었음을 보여 줍니다. 요청이 많은 경우 Ctrl+C를 누르고 플래그를 -y 사용하여 다시 시작하여 fsck 모든 질문에 "예"라고 가정합니다. 파일이 배치 lost+found된 것으로 보고되면 파일을 수동으로 식별하고 적절한 위치에 배치합니다.

일부 오류가 발생하고 이후에 해결되는 경우 명령을 다시 실행 fsck 합니다. 명령이 상태와 fsck 함께 clean 종료될 때까지 반복합니다. 예제로 다음 출력을 참조하세요.

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#

xfs 파일 시스템 복구

XFS 파일 시스템을 복구하는 명령은 다음과 같습니다.

xfs_repair [-n] FILESYSTEM
xfs_repair [-L] FILESYSTEM
mount FILESYSTEM MOUNTPOINT

XFS 파일 시스템을 복구하려면 다음 단계를 수행합니다.

다음과 같이 명령을 사용하여 xfs_repair -n 파일 시스템 오류를 확인합니다.
```
xfs_repair -n /dev/rootvg/homelv
```
확인에 성공하면 다음과 같이 발생한 오류를 수정하는 플래그를 제거 -n 하여 복구 모드를 계속 진행합니다.
```
xfs_repair /dev/rootvg/homelv
```

XFS 파일 시스템의 경우 파일 시스템을 탑재하여 저널화되었지만 커밋되지 않은 변경 내용을 처리합니다. 문제 해결 중에 다음 오류가 발생하면 탑재를 시도하고 결과를 확인합니다.

오류: 파일 시스템에 로그에서 중요한 메타데이터 변경 내용이 있으며 이를 재생해야 합니다.

복구 VM을 사용하는 경우 임시 탑재 지점(예: /recovery)에 대한 디렉터리를 만들고 파일 시스템을 탑재합니다. 복구 환경이 비상 또는 단일 사용자 모드인 경우 파일 시스템을 원하는 위치에 탑재합니다. 다음 명령을 예제로 참조하세요.

mount /dev/rootvg/homelv /recovery

또는

mount /home

파일 시스템을 탑재할 때 저널 변경 내용이 기록되지 않은 경우 플래그를 사용하여 -L 저널을 삭제하고 모든 변경 내용이 성공적으로 완료된 것처럼 파일 시스템을 탑재합니다. 플래그를 -L 사용하면 로그에 불완전한 파일 작업이 삭제되고 있음을 보여 주므로 데이터 손실이 발생합니다.

xfs_repair -L /dev/rootvg/homelv /recovery

부팅 실패 방지

nofail 파일 시스템을 탑재할 때 옵션이 지정된 경우 중요하지 않은 파일 시스템의 손상으로 인해 Linux가 완전히 부팅되지 않을 수 있습니다. 자세한 nofail내용은 디스크 탑재를 참조 하세요. 루트(/) /usr를 제외한 대부분의 탑재는 /var 다음과 같이 nofail수행할 수 있습니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유