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,nofail 0 2
* nofail마운트 옵션을 사용하면 볼륨을 마운트하는 중 오류가 발생하더라도 인스턴스를 부팅할 수 있습니다. (16.04 이전의 Ubuntu 버전을 포함한 Debian 계열의 경우는 nobootwait 마운트 옵션을 추가해야 합니다.)mount 해제
sudo umount /rescue
복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리한 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
손상된 인스턴스에 볼륨 연결
복구 인스턴스에서 보조 볼륨을 분리한 다음 원본 인스턴스에 루트볼륨으로 연결합니다.
/dev/xvda 인 루트 볼륨에 연결하셔야 합니다.
정상적으로 동작하는지 확인합니다.
