OCI Linux 인스턴스에서 구성 변경 후 부트 실패 해결

소개

이 사용지침서에서는 커스터마이징 OCI(Oracle Cloud Infrastructure) 이미지에서 부팅 실패를 해결하는 과정을 안내합니다. 이 문제는 구성 변경 후 또는 기본 장치 매핑 변경으로 인한 간단한 재부팅으로 인해 발생할 수 있습니다.

솔루션을 자세히 살펴보기 전에 먼저 커스터마이징 이미지가 무엇인지 이해해 보겠습니다.

OCI의 사용자정의 이미지는 운영체제 구성, 설치된 소프트웨어 및 환경 설정을 캡처하는 인스턴스의 부트 볼륨의 스냅샷입니다. 커스터마이징 이미지는 일반적으로 여러 인스턴스 또는 리전에 걸쳐 사전 구성된 환경을 복제하여 대규모의 일관성을 보장하는 데 사용됩니다.

이러한 이미지는 특히 인스턴스의 원래 하드웨어에 긴밀하게 연결된 경우 위험을 초래할 수 있습니다. 이식성을 염두에 두고 설계되지 않은 경우 구성을 변경할 때(예: VM.Standard3에서 VM.Standard4 인스턴스로 전환) 문제가 발생할 수 있습니다. 기본 하드웨어 변경이 장치 매핑 방식에 영향을 줄 수 있기 때문입니다.

이 블로그에서는 고객이 Oracle Cloud Marketplace의 Rocky Linux 이미지를 사용하는 경우 발생하는 실제 부팅 실패 시나리오에 대해 간략하게 설명합니다. 이 예제는 Rocky Linux에만 적용되지만 근본 원인 및 해결 방법은 구성에서 정적 장치 이름을 사용하는 사용자 정의 Linux 기반 이미지에 광범위하게 적용됩니다.

목표

이 가이드는 OCI 사용자가 마운트 구성을 수정하고 이미지 이식성을 개선하여 구성 변경 또는 재부팅으로 인한 커스터마이징 Linux 이미지에서 부팅 실패를 식별하고 해결할 수 있도록 지원합니다.

필수 조건

작업 1: 문제 이해

  1. OCI 구성 변경이 기본 하드웨어 및 장치 이름 지정에 미치는 영향을 검토합니다.
  2. /etc/fstab의 정적 장치 이름(예: /dev/sdX)은 구성 변경 후 또는 재부트 후에도 부적합해질 수 있습니다.
    • 구성이 변경되면 OS에서 연결된 블록 볼륨에 새 이름을 지정할 수 있습니다. 예를 들어, /dev/sdb인 디스크는 이제 /dev/sdc로 표시될 수 있습니다.
    • /etc/fstab가 이러한 정적 이름을 사용하는 경우 부트 시 볼륨 마운트가 실패할 수 있습니다.
    • 이러한 상황을 방지하려면 /etc/fstab에서 볼륨의 UUID 또는 /dev/disk/by-uuid/ 경로와 같은 영구 식별자를 사용하십시오.

작업 2: 증상 및 오류 식별

  1. 직렬 콘솔 또는 시스템 로그(journalctl -xb)에서 다음과 같은 오류를 확인합니다.

    • Welcome to emergency mode! After logging in, type “journalctl -xb”...
    • Failed to mount /mnt/data: No such device
    • Duplicate mount point /mnt/data detected
    • Cannot mount /dev/sdX: No such file or directory
    • systemd[1]: Failed to mount /mnt/data.
    • systemd[1]: Dependency failed for Local File Systems.
    • systemd[1]: Job local-fs.target/start failed with result ‘dependency’.

작업 3: 구조/비상 모드로 부트

  1. 인스턴스의 직렬 콘솔에 액세스합니다.
  2. Rescue 또는 비상 모드로 부트하여 진단 및 수정 조치를 수행합니다.

작업 4: 올바른 장치 이름 식별

  1. blkid 또는 lsblk 명령을 실행하여 현재 블록 장치 및 해당 UUID를 나열합니다.

작업 5: 부트 볼륨 수동 마운트

  1. 올바른 장치 이름을 사용하여 부트 볼륨을 마운트합니다.

    • mount /dev/sdXn /mnt
    • chroot /mnt

작업 6: /etc/fstab 편집

  1. 편집기를 사용하여 /etc/fstab 열기(예: vi /etc/fstab)

    • 모든 /dev/sdX 항목을 blkid에서 발견된 해당 영구 UUID 값으로 바꿉니다.
    • 중복된 마운트 항목을 제거합니다. 주: 1회 수정 영구 식별자를 사용한 후에는 이후 구성을 변경해도 이 문제가 발생하지 않습니다.

작업 7: 종료 및 재부트

  1. chroot 환경 exit를 종료합니다.
  2. 필요한 경우 볼륨을 마운트 해제합니다.
  3. 인스턴스 재부팅.

OCI 구성 변경 후 부트 실패를 방지하기 위한 예방 팁

  1. 영구 식별자 사용: 항상 /dev/sdX와 같은 장치 이름 대신 UUID= 또는 LABEL=를 사용하여 /etc/fstab에 디스크를 지정합니다. 이렇게 하면 하드웨어 변경에도 불구하고 마운트 지점의 일관성이 유지됩니다.
  2. blkid 감사 수행: 구성 변경 전후에 blkid를 실행하여 장치-UUID 매핑이 올바른지 확인합니다.
  3. 변경 전 백업: 문제가 발생할 경우 복구를 사용으로 설정하려면 구성을 수정하기 전에 항상 인스턴스 또는 부트 볼륨을 백업하십시오.
  4. 비운용에서 구성 변경 테스트: 특히 하드 코딩된 마운트가 있을 수 있는 마켓플레이스 또는 사용자정의 이미지를 사용하는 경우 먼저 비운용 환경에서 구성 변경을 테스트합니다.

결론

이 문제는 Rocky Linux에서 관찰되었지만 디스크 마운트에 대한 모범 사례를 따르지 않으면 Linux 기반 사용자 정의 이미지에 잠재적으로 영향을 줄 수 있습니다. 좋은 소식은 이것이 일회성 수정이라는 것입니다. /etc/fstab가 UUID 또는 LABEL과 같은 영구 식별자를 사용하도록 업데이트된 후에는 향후 OCI 구성이 변경되거나 재부팅도 부트 실패로 이어지지 않습니다. 구성을 사전에 검증하면 구성 간에 원활하고 안정적으로 전환할 수 있습니다.

승인

추가 학습 자원

docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.