저는 AWS에서 Amazon Linux를 사용하고 있으며 규정 준수를 위해 단일 EBS 볼륨(블록 디바이스)에 여러 파일 시스템을 설정하려고 합니다. 이를 위해 실행 중인 EC2 인스턴스에 EBS 볼륨을 탑재하고 일련의 명령을 실행한 후 탑재 해제하고 스냅샷을 생성한 다음 AMI로 변환했습니다.
기존 파티션을 제거하고 다시 추가하는 "기본" 명령 세트를 사용하여 이 모든 작업을 수행할 수 있습니다. 그러나 두 번째 파티션을 추가하면 더 이상 해당 AMI에서 EC2 인스턴스를 시작할 수 없습니다. 대신 AWS의 "인스턴스 스크린샷 가져오기" 기능을 사용하면 EC2 인스턴스가 시작되지 않고 다음이 표시됩니다.
EBS 볼륨이 마운트된 호스트 EC2 인스턴스에서 다음 명령을 실행하면,모든 것이 예상대로 작동합니다:
# Make a tar of the current EBS Volume
umount -l /mnt/ebs-volume
mount -o ro /dev/xvdf1 /mnt/ebs-volume
tar -cf /tmp/ebs.tar --exclude='./dev/*' --exclude='./proc/*' --exclude='./sys/*' /mnt/ebs-volume
umount /mnt/ebs-volume
# Replace the old partition with one new partition and format it as ext4
sgdisk --delete 1 /dev/xvdf
sgdisk --new 1:0:+7800M /dev/xvdf && sgdisk --change-name 1:Linux
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf1 && e2label /dev/xvdf1 /
# Mount the new partition and restore the snapshot
mount /dev/xvdf1 /mnt/ebs-volume
cd / && tar -xf /tmp/ebs.tar --acls --selinux --xattrs && rm /tmp/ebs.tar
# I don't make any updates to the /etc/fstab file
하지만 이 명령을 실행하면EC2 인스턴스를 시작할 수 없습니다위에 표시된 대로:
# Make a tar of the current EBS Volume
umount -l /mnt/ebs-volume
mount -o ro /dev/xvdf1 /mnt/ebs-volume
tar -cf /tmp/ebs.tar --exclude='./dev/*' --exclude='./proc/*' --exclude='./sys/*' /mnt/ebs-volume
umount /mnt/ebs-volume
# Replace the old partition with two new partitions and format them as ext4
sgdisk --delete 1 /dev/xvdf
sgdisk --new 1:0:+7800M /dev/xvdf && sgdisk --change-name 1:Linux
sgdisk --new 2:0:+100M /dev/xvdf
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf1 && e2label /dev/xvdf1 /
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf2
# Mount the new partitions and restore the snapshot
mount /dev/xvdf1 /mnt/ebs-volume
mkdir -p /mnt/ebs-volume/boot && mount /dev/xvdf2 /mnt/ebs-volume/boot
cd / && tar -xf /tmp/ebs.tar --acls --selinux --xattrs && rm /tmp/ebs.tar
# I now execute commands that write the below /etc/fstab file to the volume at /mnt/ebs-volume/etc/fstab
/etc/fstab:
LABEL=/ / ext4 defaults,noatime 1 1
/dev/xvda2 /boot ext4 defaults,noatime 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
별도의 파일 시스템을 추가하면 /boot
이 오류가 발생하는 이유는 무엇입니까? /etc/fstab
이 새 구성이 이제 더 이상 원래 구성과 동일하지 않다고 생각하기 때문에 내 파일이나 다른 파일에 뭔가가 누락된 것 입니까 ?
답변1
이를 완전히 설명하려면 PC 부팅 순서에 대한 이전 기록이 필요할 수 있습니다. (UEFI를 사용하는 최신 PC는 이 작업을 다르게 수행하지만 논리는 유사합니다.)
PC에 처음으로 하드 드라이브가 탑재되었던 1980년대를 되돌아보겠습니다.
BIOS는 하드 드라이브의 첫 번째 섹터를 로드합니다. 여기에는 코드와 파티션 테이블의 조합인 MBR(마스터 부트 레코드)이 포함됩니다. 이 모든 것을 수용할 수 있는 길이는 512바이트이므로 인코딩이 빡빡합니다.
MBR은 파티션 테이블을 보고 어떤 파티션이 활성화되어 있고 어디서 시작되는지 알아냅니다. 그런 다음중학교시스템을 부팅하고 이 파티션에 저장합니다. (역사적으로 이는 보조 부트 로더가 디스크의 첫 번째 504Mb 내에 있어야 함을 의미합니다.) 이 코드는 파일 시스템을 이해하고 운영 체제(보통 IO.SYS, MSDOS.SYS, COMMAND.COM)를 로드할 수 있습니다. 그러면 DOS가 시작됩니다. 일반적으로 새 PC에는 이 마스터 부트 섹터를 마운트하려면 "fdisk /mbr"이 필요합니다.
실제로 부팅 프로세스를 유연하게 만들고 대체 부팅 로더를 허용하는 것은 MBR의 소프트웨어입니다. Linux용 초기 부트 로더는 LILO("Linux 로더")였습니다. 메인 로더와 보조 로더가 있습니다. 표준 Linux 파일 시스템을 이해하고 Linux 및 DOS(Windows는 물론)를 이중 부팅할 수 있습니다.
그런 다음 GRUB(그리고 GRUB2)가 등장했습니다. 하지만 모두 기본/보조 부트로더 프로세스를 따릅니다.
지금 당신이 하고 있는 일은이동하다/boot 파티션 수정 시 부팅 프로세스를 지원합니다. (다소 어리석은) 메인 부트로더는 스마트 부분을 어디서 찾을 수 있는지 모릅니다. 따라서 가상 머신을 시작할 수 없습니다.
당신이 해야 할 일은 MBR에 보조 로더를 찾을 위치를 알려주어야 하는 이전 "fdisk /mbr" 프로세스와 동등한 최신 작업입니다.
이를 수행하는 방법은 사용하는 부트로더에 따라 다릅니다. "grub-install", "grub2-install" 또는 "lilo"일 수 있습니다. OS 변형에 따라 다릅니다(CentOS, Ubuntu, Debian, Amazon... 모두 다를 수 있음).
나는 당신에게 이것을 말하지 않습니다무엇빌드를 수정하세요. 하지만 적어도 지금은 이해하셔야 합니다.왜운영 체제를 시작할 수 없습니다!
답변2
AWS의 부팅 볼륨은 약간 특별하다는 점에 유의하세요. 이를 확인하고 이유를 설명할 수 있는 곳을 찾을 수 없었지만 루트 볼륨은 sda1(xvda1)로 연결되어 있습니다. 끝에 파티션 번호 1을 기록해 두십시오.http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html. 이것이 BIOS가 파티션 테이블과 더 많은 파티션을 포함하는 파티션에서 부팅할 수 없는 이유일 수 있다고 생각합니다.
여러 파티션이 필요한 경우 여러 볼륨을 사용하는 것을 피할 수 없을 것 같습니다(루트 파티션의 큰 파일에 연결된 루프 장치와 같은 추악한 트릭을 사용하지 않고 :D).