Rocky Linux 부팅 장애 복구기 + DNS 문제까지(/usr/lib64)

1. 문제 요약 (Summary)

운영 환경에서 /usr/lib64 디렉토리를 변경한 이후, 다음과 같은 연쇄 장애가 발생했다.

• 시스템 부팅 실패 (/sbin/init, /bin/sh 실행 불가)
• rescue 복구 이후 로그인 실패
• 패키지 복구 시도 중 dnf DNS 오류 발생
• 추가로 파일시스템이 read-only 상태로 전환

이 장애는 단순 디렉토리 변경이 아니라,
리눅스 런타임(동적 라이브러리), 인증(PAM), 네트워크(DNS), 파일시스템 계층까지 영향을 준 복합 장애였다.

 

---

2. 장애 흐름 (End-to-End Flow)

/usr/lib64 변경
 → 동적 라이브러리 로딩 실패
 → init/systemd 실행 실패
 → 부팅 중단

rescue 모드에서 lib64 복구
 → 부팅 가능 상태 복구

로그인 실패
 → PAM / glibc 불일치

dnf 실행 시도
 → DNS resolution 실패

추가로 filesystem read-only 상태
 → 패키지 설치 불가

---

 

3. 원인 분석 (Root Cause)

 

3-1. /usr/lib64의 역할

/usr/lib64는 단순 디렉토리가 아니라:

• glibc (libc.so.6)
• PAM 라이브러리
• systemd 의존 라이브러리
• 대부분의 ELF 바이너리 런타임 의존성

이 포함된 핵심 실행 환경 경로이다.

 

3-2. 실행 구조 관점

리눅스에서 바이너리 실행 흐름

binary (e.g. /bin/ls)
 → ELF header
 → INTERP (/lib64/ld-linux-x86-64.so.2)
 → shared libraries (/usr/lib64/*.so)
 → 실행

 

즉, /usr/lib64가 깨지면:

• /bin/sh
• /sbin/init
• /usr/bin/*

모두 실행 불가

 

3-3. “No such file or directory”의 실제 의미

다음 에러는 파일이 없는 것이 아니라

Failed to execute /bin/sh: No such file or directory

 

👉 실제 의미

• 실행 파일 존재
• 의존 라이브러리 로딩 실패

3-4. login 실패 원인

부팅 이후 login 실패는 다음 흐름에서 발생

login
 → PAM (/etc/pam.d)
 → libpam.so
 → libc.so.6

 

👉 glibc/PAM mismatch 또는 손상으로 인증 실패

 

3-5. dnf DNS 오류 원인

Could not resolve host: mirrors.rockylinux.org

 

가능한 원인

• /etc/resolv.conf 비정상
• 네트워크 인터페이스 비활성화
• rescue/chroot 환경에서 네트워크 미초기화

3-6. read-only filesystem 발생 원인

Read-only file system

 

가능한 원인

• 비정상 종료 후 filesystem dirty 상태
• 커널 보호 모드로 read-only 전환
• XFS/EXT4 journal 오류

 

---

4. 복구 절차 (Recovery Procedure)

4-1. 부팅 복구 (GRUB → rescue)

GRUB에서 커널 옵션 수정

rd.break

 

이후

mount -o remount,rw /sysroot
chroot /sysroot

 

4-2. lib64 원복

mv /usr/lib64_backup /usr/lib64

 

4-3. 필수 검증

ls -l /lib64
# 정상: lib64 -> usr/lib64

ls /usr/lib64/libc.so.6

 

4-4. ld cache 재생성

ldconfig

 

4-5. 패키지 복구 (핵심)

복구 대상

glibc
pam
bash
coreutils
iproute
iputils

 

네트워크 가능 시

dnf reinstall -y glibc pam bash coreutils iproute iputils

 

네트워크 불가 시 (권장)

다른 서버에서

dnf download --resolve glibc pam bash coreutils iproute iputils

 

복구 서버에서

rpm -Uvh --force *.rpm

 

4-6. DNS 복구

echo "nameserver 8.8.8.8" > /etc/resolv.conf

 

4-7. 네트워크 확인

ip a
ip route
ping -c 3 8.8.8.8
ping -c 3 google.com

---

4-8. read-only filesystem 복구

상태 확인

mount | grep " / "

 

---

rw 전환

mount -o remount,rw /

 

---

실패 시

ext4

fsck -y /dev/sdaX

 

xfs

xfs_repair /dev/mapper/rocky-root

 

---

4-9. 최종 검증

rpm -V glibc
ldconfig

 

---

5. 장애 대응 핵심 포인트 (Key Insights)

5-1. OS 영역은 “파일”이 아니라 “상태”다

• /usr/lib64는 복사/이동 대상이 아님
• 패키지 관리 시스템(RPM) 기준으로 관리해야 함

---

5-2. 장애는 계층적으로 봐야 한다

1. 부팅 (init)
2. 로그인 (PAM)
3. 패키지 (dnf)
4. 네트워크 (DNS)
5. 파일시스템 (rw/ro)

---

5-3. dnf 오류는 항상 패키지 문제가 아니다

Could not resolve host
→ DNS 문제

 

---

5-4. read-only 상태에서는 어떤 복구도 불가능

• rpm 설치 불가
• 설정 변경 불가

👉 반드시 filesystem 먼저 복구

---

6. 재발 방지 전략 (Prevention)

6-1. OS 핵심 경로 보호

다음 경로는 직접 수정 금지

/usr/lib64
/lib64
/bin
/sbin
/etc

 

---

6-2. 실험 환경 분리

/opt
/app
/home

에서 수행

---

6-3. 폐쇄망 대응 준비

• local repo 구성
• ISO 기반 repo 확보
• 필수 rpm bundle 준비

---

6-4. 사전 검증

rpm -qf /usr/lib64/libc.so.6
ldd /bin/ls

---

7. 결론

이번 장애는 단순한 디렉토리 변경이 아니라,
리눅스 실행 구조 전체(ELF loader, glibc, PAM, DNS, filesystem)가 연결된 복합 장애였다.

핵심은 다음 두 가지였다:

1. 문제를 단일 원인이 아닌 계층별로 분리해서 분석
2. 복구 순서를 정확히 유지 (부팅 → 로그인 → 패키지 → 네트워크 → FS)

 

---

최종 한 줄 정리

👉 /usr/lib64 손상은 OS 런타임 붕괴이며, 복구는 라이브러리·인증·네트워크·파일시스템 순으로 접근해야 한다