Clonezilla는 잘못된/업데이트되지 않은 UUID로 디스크 복제를 생성합니다.

[원래 질문 https://stackoverflow.com/questions/73959107/clonezilla-generates-disk-clone-with-wrong-unupdated-uuids]

최근에 clonezilla(디스크 대 디스크)를 사용하여 SSHD(1TB)를 NVMe(2TB)에 복제했습니다. SSHD 드라이브에서 Fedora 36 x64를 사용하여 안정적이고 대체 안정적입니다. M.2 NVMe v1.4만 연결된 경우 시스템이 두 번 모두 부팅되지 않습니다.

그 결과 어떤 초안(일부 사람들이 보고한 것처럼 그냥 해야 함 dracut --regenerate-all -f)이나 유사한 어떤 것도 사용할 수 없는 비상 쉘이 탄생했습니다. 또한 비상 쉘도 나열하지 않는 Live USB의 문제 해결 메뉴도 포함되어 있습니다.

Gnome 디스크를 확인한 결과 어떤 이유로 새 드라이브가 EFI/CSM 파티션(NVMe 디스크에서)을 올바르게 마운트했지만 SATA3 SSHD 디스크에서 /boot 및 /home을 마운트한 것으로 나타났습니다.

FC36 Live USB를 사용하여 파티션을 마운트하려고 했지만 실패하여 시도했지만 모든 옵션 btrfs check --repair이 btrfs filesystem rescue어떤 식으로든 실패했습니다.

• M.2 NVMe 연결을 끊고 SATA3 SSHD를 유지하면 SSHD를 사용하는 시스템이 Fedora 36으로 부팅됩니다.
• SATA3 SSHD를 분리하고 M.2 NVMe를 유지하면 시스템에서 UUID가 있는 장치를 찾을 수 없다고 비명을 지르고 쓸모없는 비상 쉘에 던져집니다.

두 디스크의 모든 파티션은 동일한 UUID를 갖습니다. 내 생각에는 복제된 M.2 NVMe 디스크에 잘못된 물리적 장치를 가리키는 추가 장치 UUID가 있는 것 같지만, 관련 구성을 식별 및/또는 변경할 수 있는 Linux 스토리지에 대한 깊은 이해가 없습니다. 아마도 다음과 같은 것Linux는 원래 파티션 대신 복제된 파티션을 마운트합니다., 하지만 파티션이 btrfs 파일 시스템을 사용하기 때문에 나 자신도 안전하지 않다고 느낍니다.

내가 발견한 다른 문제:

• 부팅 복구 디스크 X32 및 X64를 사용하는 경우(https://sourceforge.net/projects/boot-repair-cd/), nvme에서 풀링 문제가 발생했습니다(https://bugzilla.kernel.org/show_bug.cgi?id=204887) 따라서 시작할 수 없습니다.

복제 후 M.2 NVMe를 설치 및 부팅할 수 있도록 데이터 손실 없이 알려진 솔루션이 있습니까?

감사합니다!

---

업데이트: FC36 Live USB에서 Blivet GUI를 확인하는 것이 Clonezilla가 btrfs 볼륨을 엉망으로 만들고 다음 위치를 생성한 것처럼 더 가까워 보입니다.

• 동일한 이름(예: "myLabel")을 가진 파티션이 /dev/nvme0n1p3(~2TB, NVMe) 및 /dev/sdc3(~1TB, SSHD) 모두에 존재합니다. 내 NVMe에서 Clonezillas가 생성한 파티션이 태그 일치를 통해 기존 파티션에 연결되어 일종의 "통합" 볼륨을 형성하는 것 같습니다. 이는 시스템이 SATA3 드라이브 없이는 부팅되지 않지만 NVMe 드라이브 없이는 부팅할 수 있는 이유에 대한 타당한 설명처럼 느껴집니다.

인용하다:파일 시스템 UUID(2개의 동일한 UUID)를 변경하는 방법은 무엇입니까?

---

업데이트 #2:

포기하고 FC36 Live USB를 통해 다시 설치했는데 몇 가지 문제가 발생했습니다.

• 아나콘다에서 시스템이 무작위로 정지됩니다.
• 부트로더 설치 중 시스템 충돌(자동 파티션 설정 및 부팅 파티션 유지를 통한 재설치에 성공, 설치 프로그램이 성공적으로 완료될 수 있음)
• 그래도 빈 추가 파티션이 있습니다(EFI와 CSM은 분명히 재사용되지 않습니다).