Question?
인스턴스의 Data EBS를 분리 후 인스턴스 부팅이 안되는 현상이 있어서 문의 남겨드립니다.
시스템 로그를 확인하니 "Dependency failed for ~~" 이라는 메세지가 출력 됩니다.
Answer!
ec2의 /etc/fstab 파일이 손상되어 부팅이 안될 가능성이 높습니다.
해결 방법에 대한 테스트와 안내 도와드리겠습니다 :)
[사전 준비] 운영 중인 EC2 AMI 생성
-
테스트 용도의 새로운 EC2 생성을 위해 이미지를 생성합니다.
-
AMI 로 인스턴스 시작합니다.
해당 AMI 로 손상된 인스턴스(가정)
hanna-wordpress-test인스턴스를 생성합니다. -
손상된 인스턴스에 새로운 ebs 추가하기
추가 후 인스턴스에 접속하여 정상적으로 추가 되었는지 확인합니다.sudo lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 ├─nvme0n1p1 xfs / f6646b81-f2a6-46ca-9f3d-c746cf015379 / └─nvme0n1p128 nvme1n1
-
nvme1n1 볼륨에서 파일 시스템을 생성
sudo mkfs -t xfs /dev/nvme1n1 meta-data=/dev/nvme1n1 isize=512 agcount=4, agsize=524288 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 -
탑재 지점 디렉토리 생성 후 nvme1n1 마운트
sudo mount /dev/nvme1n1 /data
-
마운트 확인
sudo mount -v tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=200116k,mode=700,uid=1000,gid=1000) /dev/nvme1n1 on /data type xfs (rw,relatime,attr2,inode64,noquota) lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 ├─nvme0n1p1 xfs / f6646b81-f2a6-46ca-9f3d-c746cf015379 / └─nvme0n1p128 nvme1n1 xfs a8e632e3-21ed-4166-abd1-bdfc75de43d4 /data
-
/etc/fstab 파일 손상
# 정상적인 파일UUID=f6646b81-f2a6-46ca-9f3d-c746cf015379 / xfs defaults,noatime 1 1 UUID-a8e632e3-21ed-4166-abd1-bdfc75de43d4 /data xfs defaults,nofail 0 2
볼륨을 다른 인스턴스로 이동한 후와 같이 이 볼륨을 연결하지 않고 인스턴스를 부팅하는 경우
nofailmount 옵션을 사용하면 볼륨을 마운트하는 동안 오류가 발생하더라도 인스턴스를 부팅할 수 있습니다.# 손상된 파일UUID=f6646b81-f2a6-46ca-9f3d-c746cf015379 / xfs defaults,noatime 1 1 UUID-a8e632e3-21ed-4166-abd1-bdfc75de43d /data xfs defaults,noatime 0 2
예를 들어 UUID 의 숫자 하나를 제거 합니다.
-
손상된 인스턴스 부팅 후 확인
sudo reboot
인스턴스 중지 후 재시작을 하면 상태 검사에 실패하는 것을 확인하실 수 있습니다.
시스템 로그에서 마운트 과정에서 실패한 오류를 확인합니다.
"Dependency failed for ~~" 이라는 메세지를 확인합니다.
-
복구용 인스턴스 생성
손상된 인스턴스와 동일한 가용 영역(ap-northeast-2a)에서 새 인스턴스를 시작합니다.
복구 인스턴스를 사용하여 수동으로 오류 수정
사전 준비 때 만든 인스턴스를 복구 인스턴스(
hanna-wordpress-recover)로 사용합니다.손상된 인스턴스(
hanna-wordpress-test) 중지-
손상된 인스턴스에서 EBS 루트 볼륨 (
/dev/xvda또는/dev/sda1)을 분리합니다. 루트 볼륨의 디바이스 이름(/dev/xvda또는/dev/sda1)을 기록해 둡니다. -
복구 인스턴스에 보조 디바이스(
/dev/sdf)로 볼륨을 연결한다.-
분리한 볼륨을 연결하기
-
볼륨을 연결할 인스턴스를 선택하기
이 때 동일한 가용 영역에 있는 인스턴스만 표시되므로 복구 인스턴스를 생성할 때, 손상된 인스턴스와 동일한 가용 영역에 생성하도록 합니다.
-
볼륨이 제대로 연결되었는지 확인.
복구 인스턴스에 손상된 인스턴스의 볼륨이 정상적으로 연결된 것을 확인합니다.
-
-
복구 인스턴스에 SSH 접속합니다.
-
복구 인스턴스에 연결된 새 볼륨의 탑재 지점 디렉터리(
/rescue)를 생성합니다.sudo mkdir /rescue
-
생성한 디렉터리에 볼륨을 확인 후 탑재합니다.
-
볼륨 확인
sudo lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 ├─nvme0n1p1 xfs / a79c006f-96af-49dc-a71a-2779441678a3 / └─nvme0n1p128 nvme1n1 ├─nvme1n1p1 xfs / f6646b81-f2a6-46ca-9f3d-c746cf015379 └─nvme1n1p128
✅ T2 유형은 NEBS 볼륨을 NVMe 블록 디바이스로 표시하는, Nitro 기반의 인스턴스 이므로 볼륨이 위와 같이 표시된다.
✅ nvme1n1 이 추가로 연결한 볼륨이다.
✅ uuid 가 다른 볼륨을 확인할 수 있음
✅ 두 볼륨 모두 동일한 스냅샷에서 생성된 경우 또는 두 번째 스냅샷이 기본 볼륨에서 생성된 경우에는 두 볼륨이 UUID를 공유합니다.
b. 볼륨 마운트c. 마운트 확인mkdir /rescue sudo mount -t xfs /dev/nvme1n1p1 /rescue
lsblk nvme0n1 259:0 0 8G 0 disk ├─nvme0n1p1 259:1 0 8G 0 part / └─nvme0n1p128 259:2 0 1M 0 part nvme1n1 259:3 0 20G 0 disk ├─nvme1n1p1 259:4 0 20G 0 part /rescue └─nvme1n1p128 259:5 0 1M 0 part
-
볼륨 확인
해결 방법
2. 탑재 실패
시스템 로그에 "Failed to mount" 또는 "Dependency failed"와 같은 오류가 표시되는 경우 /etc/fstab 파일에 잘못된 탑재 지점 항목이 있을 수 있습니다
[시스템 로그]
/etc/fstab의 탑재 지점 항목이 올바른지 확인합니다.
모범 사례는 fsck 또는 xfs_repair 도구를 실행하여 파일 시스템 오류를 수정하는 것입니다. 파일 시스템에 불일치가 있는 경우 fsck 또는 xfs_repair 도구가 이를 수정합니다.
-
XFS 파일 시스템의 경우:
-
정상
sudo xfs_repair 명령어를 사용하면 아래와 같이 출력됩니다.$ sudo xfs_repair /dev/nvme1n1p1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done
-
비정상
sudo xfs_repair /dev/nvme1n1p1 xfs_repair: /dev/nvme1n1p1 contains a mounted filesystem xfs_repair: /dev/nvme1n1p1 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library
-
정상
-
/etc/fstab 수정
# sudo vi /rescue/etc/fstab # UUID=f6646b81-f2a6-46ca-9f3d-c746cf015379 / xfs defaults,noatime 1 1 UUID=a8e632e3-21ed-4166-abd1-bdfc75de43d4 /data xfs defaults,noatime 2 0
-
mount 해제
sudo umount /rescue
복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리한 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
손상된 인스턴스에 볼륨 연결
-
복구 인스턴스에서 보조 볼륨을 분리한 다음 원본 인스턴스에 루트볼륨으로 연결합니다.
/dev/xvda 인 루트 볼륨에 연결하셔야 합니다.
정상적으로 동작하는지 확인합니다.
