답변:
네, 아주 쉽습니다.
/dev/sda1이것은 물론 대체 EBS 볼륨이 부팅 가능하다는 것을 전제로합니다. 부팅 가능한 OS 이미지를 포함해야합니다.
/dev/sda도 /dev/sda1나를 위해 일한,하지만 /dev/xvda했다.
/dev/sda-작동하지 않았습니다. /dev/sda1, dev/sdf-작동했지만 인스턴스가 부팅되지 않았습니다. /dev/xvda일했다.
aws ec2 describe-instances --instance-id i-XXXXXXX | grep -i rootDeviceName제 경우에는/dev/xvda
선택한 답변에 주석을 추가 할 충분한 담당자가 없지만 저를 위해 /dev/sda1작동하지 않았고 (루트로 첨부하지 않았 음) working (루트로 첨부)을 사용 했음을 지적하고 싶습니다 /dev/xvda. 인스턴스는 HVM을 사용하는 최신 t2.micro 인스턴스 중 하나입니다.
/dev/sda1AWS가 인스턴스 시작을 거부합니다. 대체 루트 장치 이름을 사용하도록 구성해야하는 다른 설정이 있습니까?
/dev/sda유효하지만 /dev/sda1괜찮습니다.
수락 된 답변의 댓글 스레드에서 Diomidis Spinellis의 댓글에 대해 자세히 설명하려면 새 루트 기기로 전환하려는 기기의 파일 시스템 레이블을 확인하는 것이 중요합니다. 자체 서버 마이그레이션 문제를 해결하는 동안 인스턴스가 부팅되기 전에 다음을 수행해야했습니다.
e2label명령을 사용 하여 새 루트 장치 용으로 만든 ext2 / ext3 / ext4 파일 시스템의 레이블을 변경합니다.
먼저 현재 루트 장치의 파일 시스템 레이블을 확인하십시오.
$ sudo e2label /dev/xvda1
cloudimg-rootfs
동일한 파일 시스템 레이블을 갖도록 새 장치를 설정하십시오.
$ sudo e2label /dev/xvdg 'cloudimg-rootfs'
제 경우 레이블은 cloudimg-rootfs. 때로는 단순히 /.
e2label의 작동 방식을 이해하는 것이 중요합니다. 자세한 내용 man e2label은 컴퓨터를 확인 하거나 http://linux.die.net/man/8/e2label 을 방문 하십시오 .
aws 권장 솔루션입니다. 중지 한 후 원래 인스턴스에서 루트 볼륨을 분리 할 수 있습니다. 루트 볼륨은 / dev / sda1에 연결됩니다. 분리되면 새 인스턴스에 연결하십시오. 볼륨이 연결된 후 OS에서 마운트해야 할 수 있습니다. 마운트되면 그 안에있는 데이터를 볼 수 있습니다.
새 키 추가를 완료 한 후 분리하고 / dev / sda1에서 원래 인스턴스에 연결할 수 있습니다.
변경하기 전에 루트 볼륨의 스냅 샷을 생성하는 것이 좋습니다.
솔루션을 시도하기 전에 중요하지 않은 인스턴스 또는 스팟 인스턴스를 시도하십시오.
CloudFormation을 통해이 작업을 수행하려면 다음을 수행해야합니다.
스택을 배포하십시오. 그러면 인스턴스가 다시 생성되므로 탄력적 IP 주소를 사용하고 있는지 또는 DNS 액세스 권한이 있는지 확인하십시오.
이 해결 방법을 수행해야하는 이유는 CF가 EC2 BlockDeviceMappings에서 루트 볼륨 크기를 조정하거나 루트 볼륨의 SnapshotId를 조정하는 것을 허용하지 않기 때문입니다.
볼륨이 마운트되면 번호가 붙은 후위가 붙습니다. 예를 들어 /dev/sda마운트되면 /dev/sda1, /dev/sda2만든 파티션에 따라 마운트됩니다 . 루트 디바이스 자체를 마운트 할 때 디바이스가 이미 마운트되었다고 가정하므로 /dev/sda1볼륨 마운트를 루트 디바이스로 제공해야합니다 . 참고 : 연결된 루트 볼륨이 없어야합니다.
다음 단계를 따르십시오. 1) 볼륨으로 이동하여 작업에서 볼륨 연결을 선택합니다. 2) 인스턴스를 선택합니다. 3) 루트로 마운트하려면 디바이스 이름을 /dev/sda1
4) 인스턴스를 시작합니다.
/dev/sda1실제로!