최근에 설치된 Lubuntu KVM 가상 머신의 가상 디스크 이미지 파티션은 다음과 같습니다.
# lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs
0 100% /rofs
... SNIP ...
sr0 iso9660 Ubuntu 19.10 amd64 2019-10-17-12-53-34-00 0 100% /cdrom
vda
└─vda1 crypto_LUKS xxxx-yyyy-zzzz
즉, 암호화된 시스템 파티션( vda1
)이 있고 부팅 파티션은 없습니다. (참고. 암호화된 파티션을 확인/크기 조정하기 위해 라이브 이미지로 부팅했는데 부팅 파티션이 없어서 놀랐습니다.)
질문:부팅 파티션이 없는데도 시스템을 어떻게 부팅할 수 있습니까(부팅을 하기 때문에!)?
후속 질문에 대한 더 나은 이해를 돕기 위해:
- KVM이 복호화 자체를 관리하기 때문에 부팅이 작동합니까?
- 아니면 호스트 시스템에도 적용됩니까?
- 독립형 설정에서도 작동한다면 이와 같은 독립형 암호화 파티션이 아닌 (암호화되지 않은) 부팅 파티션을 만드는 이유는 무엇입니까?
cryptsetup
KVM이 암호 해독을 관리하는 경우 암호화된 장치를 생성하기 위해 KVM에 올바른/호환 버전이 설치되어 있는지 어떻게 확인합니까 ? 버전이 일치하지 않으면 어떻게 되나요?- KVM이 암호 해독을 관리하는 경우 전체 디스크 암호화로 Lubuntu를 설치할 때 설치 프로그램이 Lubuntu가 가상 머신에서 실행 중임을 확인하고 암호화된 파티션을 생성하는 것으로 충분하다고 결정했다고 가정합니다. 그렇습니까? 그렇다면 부팅 파티션이 포함된 "일반" 설정을 원하는지 묻지 않는 이유는 무엇입니까?
참고: 실제로 시작 시 암호화된 디스크를 여는 GUI는 매우 간단합니다. 이것은 텍스트 기반 GUI입니다.싱글암호화된 파티션을 열기 위해 암호를 입력하려고 시도했지만 전혀 피드백이 없습니다(별표는 입력한 문자 수를 최소한 표시하지 않는 것 같습니다). 이전에는 Lubuntu가 Ubuntu보다 단순했기 때문에 그 이유를 추측했지만 이제는 (위에서 언급한 대로) KVM이 암호 해독 자체를 관리하는 것으로 의심됩니다.
답변1
여러 가지 가능성이 있습니다:
MBR/DOS 파티션, 암호화된 디스크 지원이 포함된 GRUB 및 LUKS 1(또는 PBKDF2 암호화가 포함된 LUKS 2)을 사용하는 경우 부팅 파티션이 필요하지 않습니다. GRUB의 향후 버전은 LUKS 2를 완전히 지원할 수도 있지만, 제가 아는 한 아직 완전히 구현되지는 않았습니다.argon2i는 아직 지원되지 않습니다).
커널/initramfs는 외부에 저장될 수 있으며
-kernel -initrd
적절한 옵션을 qemu에 전달하여 qemu/KVM에 의해 직접 로드될 수 있습니다. 이 경우 qemu 자체가 부트로더 역할을 하므로 가상 머신 내에 부팅 파티션이 필요하지 않습니다.커널 이미지는 첫 번째 파티션 앞의 특정 장치 오프셋에 존재할 수 있습니다. 파티션/파일 시스템/파일이 아니라 원시 데이터로 장치에 직접 기록되며 부트로더는 이를 찾을 위치를 알고 있습니다. 이 방법은 일반적으로 임베디드 장치에서만 발견됩니다.
이와 같이 별도의 암호화된 파티션이 아닌 (암호화되지 않은) 부팅 파티션을 만드는 이유는 무엇입니까?
문제는 부트로더가 결국 어딘가로 이동해야 한다는 것입니다. 따라서 MBR/DOS 파티션을 사용하면 분할되지 않은 공간에서 많은 작업이 발생합니다. 물론 이것은 작동합니다... 서로 다른 두 가지가 동일한 오프셋에 데이터를 배치하고 서로 덮어쓰려고 시도하기 전까지는 말이죠.
우리는 이들을 적절하게 분할하는 것이 더 나을 것이라고 결정했습니다. 따라서 GPT를 사용하면 EFI 파티션을 얻거나 GRUB는 핵심 이미지 등을 위한 BIOS_grub 파티션을 얻습니다.
이상적으로는 파티션 외부 어딘가에 모든 것이 숨겨져 있기 때문에 어떻게 작동하는지 머리를 긁적이기보다는 파티션 테이블을 보고 그것이 어떻게 설정되어 있는지 이해할 수 있습니다.