최근에 설치한 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이 암호 해독 자체를 관리하므로 부팅이 작동합니까?
- 아니면 호스트 시스템에서도 작동합니까?
- 독립 실행형 설정에서도 작동한다면 왜 이렇게 독립 실행형 암호화 파티션이 아닌 (암호화되지 않은) 부팅 파티션을 생성해야 할까요?
- 암호 해독을 관리하는 것이 KVM이라면
cryptsetup
암호화된 장치를 생성하는 데 사용된 올바른/호환 가능한 버전이 KVM에 설치되어 있는지 어떻게 확인합니까? 버전이 맞지 않으면 어떻게 되나요? - 암호 해독을 관리하는 것이 KVM이라면 전체 디스크 암호화로 Lubuntu를 설치할 때 설치 프로그램이 Lubuntu가 VM에서 실행 중임을 확인하고 단일 암호화 파티션을 생성하는 것으로 충분하다고 결정했다고 가정합니다. 이것이 사실입니까? 그렇다면 부팅 파티션을 사용하여 "일반" 설정을 원하는지 묻지 않은 이유는 무엇입니까?
참고: 실제로 부팅 시 암호화된 디스크를 여는 GUI는 다소 스파르타적입니다. 내가 가지고 있는 텍스트 기반 GUI입니다.하나의 싱글전혀 피드백 없이 암호문을 입력하여 암호화된 파티션을 열려고 시도합니다(별표는 입력한 문자 수를 표시하지 않는 것으로 나타납니다). 그 이유를 추측하기 전에는 Lubuntu가 Ubuntu보다 간단하기 때문이었지만 지금은 (위에 쓰여진 대로) KVM이 암호 해독 자체를 관리한다고 의심합니다.
답변1
여러 가지 가능성이 있습니다:
MBR/DOS 파티셔닝, 암호화 디스크 지원이 포함된 GRUB 및 LUKS 1(또는 PBKDF2 암호 문구가 포함된 LUKS 2)을 사용하는 경우 부팅 파티션이 필요하지 않습니다. GRUB의 향후 버전은 LUKS 2를 완전히 지원할 수도 있지만 아직까지는 지원되지 않습니다(아직 argon2i는 지원되지 않습니다).
kernel/initramfs는 외부에 저장될 수 있으며
-kernel -initrd
qemu에 적절한 옵션을 전달하여 qemu/KVM에 의해 직접 로드될 수 있습니다. 이 경우 qemu 자체가 부트 로더 역할을 하므로 VM 내부에 부트 파티션이 필요하지 않습니다.커널 이미지는 첫 번째 파티션 앞의 특정 장치 오프셋에 존재할 수 있습니다. 파티션/파일 시스템/파일이 아니라 장치에 원시 데이터로 직접 기록되며 부트로더는 이를 찾을 위치를 알고 있습니다. 이 접근 방식은 일반적으로 임베디드 장치에서만 볼 수 있습니다.
왜 이렇게 독립형 암호화 파티션이 아닌 (암호화되지 않은) 부팅 파티션을 생성해야 할까요?
문제는 부트로더가 결국 어딘가로 가야 한다는 것입니다. 따라서 MBR/DOS 파티셔닝을 사용하면 많은 작업이 파티셔닝되지 않은 공간에서 진행됩니다. 물론 작동할 수 있습니다. 어쨌든 서로 다른 두 개체가 데이터를 동일한 오프셋에 배치하고 서로 덮어쓰려고 하기 전까지는 말이죠.
이를 위해 적절한 파티션을 갖는 것이 더 좋다고 결정되었습니다. 따라서 GPT를 사용하면 EFI 파티션을 얻을 수 있고/또는 GRUB는 핵심 이미지에 대한 bios_grub 파티션을 얻을 수 있습니다.
이상적으로는 파티션 테이블을 보고 그것이 어떻게 설정되어 있는지 알 수 있으며, 머리를 긁적이지 않고 여기에서 어떻게 작동하는지 물어볼 수 있습니다. 모든 것이 파티션 외부 어딘가에 숨겨져 있기 때문입니다.