dd를 사용하여 luks 헤더를 복사하면 내가 읽고 있는 드라이브에 오류가 발생하는 이유는 무엇입니까?

dd를 사용하여 luks 헤더를 복사하면 내가 읽고 있는 드라이브에 오류가 발생하는 이유는 무엇입니까?

문제 요약./dev/nvme0n1p1USB 플래시 드라이브 파티션으로 만든 다음 블록 장치 헤더의 키를 삭제하여 luks 암호화된 블록 장치와 함께 분리된 luks 헤더를 사용하고 싶습니다 . 나는 가지고있다제한된 세부 사항어떻게 해야 할지 모르겠지만 제 계획은 (1) 플래시 드라이브 파티션의 크기를 /dev/sda3헤더의 크기로 설정하는 것입니다. 그런 다음 (2) dd if=/dev/nvme0n1p1 of=/dev/sda3 bs=4096 count=4096새 파티션의 공간을 헤더 정보로 덮어씁니다. (3) 옵션에 헤더 파일을 입력 /etc/crypttab하고 새로운 initramfs를 생성합니다. 이것이 효과가 있기를 바랍니다. 그러나 -command를 실행한 후 dd(아직 crypttab을 편집하지 않음) initramfs를 다시 빌드하려고 시도했지만 다음 오류가 발생합니다.

$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64
cryptsetup: ERROR: nvme0n1p1_crypt: Source mismatch
update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64
cryptsetup: ERROR: nvme0n1p1_crypt: Source mismatc

내 질문은 다음과 같습니다. (1) 이러한 오류가 발생하는 이유는 무엇입니까? 데이터를 복사하면 내가 읽고 있는 파일 시스템에 오류가 발생하는 이유를 이해할 수 없습니다. (2) 지참하지 않은 경우 dd.

세부 사항 및 연구. Google과 Stack Exchange를 검색했는데 가장 관련성이 높은 것은 다음과 같습니다.이것. 명령을 실행하면 다음 메시지가 나타납니다.

$ dmsetup info -c --noheadings -o devnos_used -- "nvme0n1p1_crypt"
259:1

가이드위에 링크한 내용은 (나에게) 이 작업을 수행해야 한다고 제안하는 것 같습니다.

답변1

initramfs 및 crypttab을 업데이트해야 한다고 언급할 때 이 암호화된 블록 장치가 시스템 부팅 프로세스의 일부라고 가정합니까? 이 경우 파티션에서 헤더를 직접 복사하는 경우 드라이브를 마운트 해제해야 합니다. 이는 드라이브가 마운트되지 않도록 USB 라이브 부팅 환경에서 이 모든 작업을 수행하는 경우, 특히 드라이브가 마운트되지 않은 경우에 이상적입니다. 헤더가 복사되는 파티션이 기본 시스템입니다.

chroot이것이 당신이 하고 있는 일이고 현재 USB 라이브 부팅 환경(오류를 설명할 수 있음)에서 이 작업을 수행하려고 한다고 가정하고, 입력 한 대로 업데이트하려는 시스템의 부팅 파티션 initramfs를 바인드 마운트했는지 확인하세요. 업데이트하려면 시스템 부분에 들어가세요.

Buuuuuut.... crypttab을 변경하지 않은 경우 initramfs를 업데이트할 필요가 없으므로 적용되지 않을 수 있는 솔루션을 제공하고 싶은지 잘 모르겠습니다. 그러니 백업을 좀 하세요...

USB Live Boot 환경에서 시도해보지 않으셨다면 걱정하지 마시고 옵션 2를 따르세요.가이드dd원본 헤더를 직접 복사하는 대신 cryptsetup파일에 백업 헤더 생성을 사용한 다음 dd지침에 따라 파일을 USB 플래시 드라이브 파티션에 쓸 수 있습니다.

대신 귀하의 필요에 맞게 지침을 조정하고 명확하지 않은 경우를 대비하여 몇 가지 설명을 추가했습니다. 그리고 "$"로 시작하는 각 개행 문자를 식별하여 새 명령의 시작임을 나타냅니다.

 $ sudo -i
\\ just to ensure running everything below as root without a need to add sudo

$ mkdir /tmp/header_backup
$ mount -t tmpfs -o size=512m tmpfs /tmp/header_backup
\\ this user just took extra precaution by writing the backup header file to ramdisk
\\ which is unnecessary so u could just skip straight to the next step and designate
\\ somewhere normal like /home/USER/Documents if you wanted

$ cryptsetup luksHeaderBackup /dev/nvme0n1p1 --header-backup-file /tmp/header_backup/header.luks
$ dd if=/tmp/header_backup/header.luks of=/dev/sda3
$ umount /tmp/header_backup

\\ Then update crypttab, using your preferred text editor, here i use nano
\\ Here you're just appending the header option so if nvme0n1p1 is listed
\\ and shows as nvme0n1p1_crypt, then simply add it after the last option

$ nano /etc/crypttab

nvme0n1p1_crypt {UUID of /dev/nvme0n1p1} none luks,discard,header=/dev/sda3

\\ for nano, ctrl+x then Y then Enter & Enter again to exit and confirm saving
\\ At this point you're going to have 2 devices sharing the same UUID so
\\ you can address this by changing the one for the USB drive since it got
\\ changed when you copied the header to it, and saves you from updating fstab

$ cryptsetup luksUUID /dev/sda3 --uuid $(uuidgen)
\\ THEN you can run...

$ update-initramfs -u -k all

/dev/nvme0n1p1원래 LUKS 드라이브이고 /dev/sda3헤더를 저장하려는 USB 드라이브 파티션 임이 확실합니다 .


이제 질문을 검토하려면 다음 단계를 따르세요.

내 질문은 다음과 같습니다. (1) 이러한 오류가 발생하는 이유는 무엇입니까? 데이터를 복사하면 내가 읽고 있는 파일 시스템에 오류가 발생하는 이유를 이해할 수 없습니다.

이 명령을 정확히 실행하는 위치에 따라 두 가지 가능성을 생각할 수 있습니다. 예를 들어 현재 시스템에서 부팅하고 있습니까 nvme0n1p1? 아니면 저장된 시스템과 완전히 분리된 USB-Live Boot 시스템에서 변경을 하시겠습니까 nvme0n1p1? 전자의 경우 헤더를 파티션에 쓰기 전에 마운트 해제가 없을 수 있습니다 /dev/sda3. 이는 USB 파티션이 마운트되어 있는 동안 USB 파티션의 메타데이터를 변경하고 실제 부팅 파일 설정을 변경하지 않고 런타임에 시스템을 혼란스럽게 합니다 update-initramfs. 또는 후자의 경우, 실행하기 전에 nvme0n1p1의 시스템에 제대로 chroot하지 않았 update-initramfs으므로 업데이트 중인 시스템이 아니라 Live-Boot에 설치된 부팅 드라이브를 읽고 있습니다. 두 경우 모두 crypttab파티션의 매핑된 이름을 참조해야 합니다. 드라이브는 표시되거나 사용된 장치 매핑 이름이 아니라 UUID로 마운트되므로 거기 에 있는 모든 항목 crypttab이 표시된 내용과 일치해야 합니다.fstabfstabcrypttab

하지만 다시 한 번 기억하세요.

(2) dd를 사용하지 않고 플래시 드라이브에 헤더를 쓰는 올바른 방법은 무엇입니까?

작성하는 다른 방법이 있지만 수행하는 방식은 정확하지만 해당 명령으로 수행하지 않는 작업(예: 파티션에 쓰기 전에 파티션을 마운트 해제하거나 파티션에서 직접 쓰는 경우)에 문제가 있을 수 있습니다. 다른 하나의 장치, 두 장치 모두 umount편집됨)

도움이 된다면 연결한 마지막 가이드를 따르고(위 명령을 수정했습니다), 귀하의 것이 그들의 것이며 /dev/nvme0n1p1귀하의 답변에 있는 /dev/sda4귀하의 것도 /dev/sda3그들의 것임을 기억하십시오. /dev/sdb질문의 방식과 혼동하지 않도록 원래는 /dev/sda3USB 파티션을 헤더로 언급했지만 나중에 자체 질문에 답변을 추가할 때 변경되었습니다.

관련 정보