그래서 어떻게든 내 디스크의 파티션 테이블이 이상해졌습니다. 다음 번에 시스템을 부팅할 때 시스템이 부팅되지 않았고 BIOS에서 반복적으로 쫓겨났고 실행 가능한 부팅 옵션이 없었습니다. BIOS는 여전히 디스크를 올바르게 감지했기 때문에 무슨 일이 일어나고 있는지 확인하기 위해 LiveDVD를 부팅했습니다.
따라서 운영 체제가 있는 디스크 /dev/sdb, 128GB SSD에는 파티션 테이블이 없습니다. gpart와 fdisk 모두 비어 있는 것으로 보고합니다. fdisk는 디스크 레이블 유형을 gpt로 보고합니다.
testdisk를 실행해 보았는데 파티션 테이블 유형이 EFI GPT 대신 Intel로 식별되었습니다. 두 가지 유형의 파티션을 모두 검색해 보았지만 Intel만 성공했습니다.
그래서,첫 번째 질문: 인텔 파티션 유형이 MBR인가요? 디스크 레이블이 GPT인데도 EFI GPT가 작동하지 않는 이유는 무엇입니까?
시작 시 도구는 다음 파티션만 찾습니다.
Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63
Partition Start End Size in sectors
1 P EFI GPT 0 0 2 15566 29 63 250069679
빠른 검색(또는 전체 검색)을 실행하면 도구에서 일부 파티션을 찾습니다. 그 중 5개는 의미가 있습니다.
FAT32 0 32 33 33 69 36 532480 [SYSTEM]
Linux 33 69 37 163 207 44 2097152
Linux Swap 163 240 14 931 97 62 12328960
Linux 931 97 63 9038 187 45 130244608
Linux 9038 187 46 15565 209 4 104857600
두 번째 질문표시된 값과 관련하여 시작 열에 3개의 값(예: 0 32 33)과 끝 열에 3개의 값(예: 33 69 36)이 있는데, 이 값을 어떻게 해석합니까?
명령을 사용하여 이 파티션 내부를 보면 다음을 P: list file볼 수 있습니다.
첫 번째 파티션에는 다음과 같은 EFI 콘텐츠가 포함됩니다.
drwxr-xr-x 0 0 0 31-Jan-2019 19:26 EFI
drwxr-xr-x 0 0 0 13-Mar-2019 18:29 System
-rwxr-xr-x 0 0 0 21-May-2019 10:55 mach_kernel;5ce3af18
-rwxr-xr-x 0 0 34 13-Mar-2019 18:29 mach_kernel
drwxr-xr-x 0 0 0 26-Oct-2018 00:52 8310a92cdfe04b36b5a63736b6419b48
efi두 번째 파티션은 , grub2, vmlinuzs 등을 포함하는 부팅 파티션입니다. 네 번째 파티션에는 홈 폴더가 포함되고 마지막 파티션에는 루트 디렉터리가 포함됩니다.
파일을 볼 수 있었기 때문에 /etc/lvm/을 복원했는데 /etc/fstab, 이는 실제로 시스템이 LVM으로 구성되었음을 보여줍니다.
파티셔닝이 어떤 방식으로든 확장/논리적인지 확실하지 않으며, 그것이 GPT에 적합한지, MBR에만 국한되지 않는지조차 모르겠습니다.
세 번째 질문, testdisk가 특정 파티션을 인식할 수 있다는 점을 고려하면 이 값을 사용하여 파티션 테이블을 복원해 볼 수 있지만 LVM은 어떻습니까? GPT는 어떻습니까? 이러한 파티션이 올바르게 식별된 것으로 나타나면 이전 상황을 어떻게 복원할 수 있습니까?
감사합니다!
편집: 확장 파티션에 대해 질문한 이유는 분명히 모든 기본 파티션을 만들 수 없고(이로 인해 MBR이라고 생각하게 됨) 확장 파티션이 필요하지만 만들 수 없기 때문입니다.
편집 2: 심층 검색을 통해 찾은 모든 파티션은 다음과 같습니다.
Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63
Partition Start End Size in sectors
>* FAT32 0 32 33 33 69 36 532480 [SYSTEM] *
P Linux 33 69 37 163 207 44 2097152 *
P Linux Swap 163 240 14 931 97 62 12328960 *
D Linux 931 97 63 9038 187 45 130244608 *
D Linux 4873 98 26 12980 188 8 130244608
D Linux 4875 43 33 12982 133 15 130244608
D Linux 9038 187 46 15565 209 4 104857600 *
D FAT12 9695 133 39 9695 198 39 4096
D HPFS - NTFS 15502 117 40 15566 19 5 1021952
파일이 포함된 파티션은 첫 번째(EFI), 두 번째(/boot), 네 번째(/home), 일곱 번째(/)입니다. 나는 *줄 끝에 분명히 합법적인 파티션을 표시했습니다.
편집하다
결국 드라이브를 복사하고 dd, OS를 다시 설치하고, 이전 파티션을 마운트하여 데이터를 복구했습니다.그래서.
답변1
계속하기 전에 dd심각한 문제가 발생한 경우 복구하는 데 사용할 수 있는 디스크 이미지를 생성( )하세요.
귀하의 게시물을 읽으신 것으로 보입니다.테스트 디스크가이드. 그렇지 않다면 읽어 보는 것이 가장 좋습니다.
질문 1
Testdisk사용 가능한 파티션 유형은 자동으로 인식되어야 하며 파티션을 찾는다는 사실은 INTEL걱정할 필요가 없습니다. 파티션을 찾았고 검사를 통해 내용을 확인했으며 복구하려는 파티션입니다. 이는 testdisk동일한 스키마를 사용하여 복구된 파티션 테이블에 쓸 파일을 찾는다는 점을 잊지 마십시오 . 그래서 모든 것이 좋아 보입니다.
질문 2
당신이 보면가이드관심 있는 숫자가 시작 및 끝 열의 첫 번째 숫자임을 확인할 수 있습니다. 연속된 경우 파티션 사이에 간격이 없으며 일관성 있는 파티션 패턴의 일부가 될 가능성이 높습니다. 이것은 좋은 일이며 testdisk디스크에서 생성/추론되는 파티션 테이블을 사용하여 파일 수준으로 드릴다운할 수 있다는 사실은 자신감을 불러일으킵니다.
제가 걱정하는 유일한 점은 시작 주소와 끝 주소가 동일하고 연속적이지 않다는 것입니다. 즉, testdisk유효하지 않은 테이블에 쓰도록 요청하면 질식해야 합니다.
질문 3....해야 할까요...?
LVM은 이 수준에서는 표시되지 않지만 복구된 운영 체제가 LVM 모듈을 로드하고 복구된 시스템에서 LVM 레이아웃을 읽을 때 부팅 시 선택됩니다.
GPT / MBR은 단지 다릅니다체재파티션 테이블. 파일을 찾을 때 사용되므로 testdisk복구할 때 사용해야 합니다.
귀하의 입장에서 나는 준비가 되었음을 알기 때문에 귀하가 나열한 패턴을 기반으로 테이블을 수정하겠습니다.영상문제가 발생하면 원본 디스크로 복원하고 다시 시도할 수 있습니다.
위로가 된다면 ping을 할 1TB 드라이브가 있었고 무엇을 해야할지 결정하는 데 비슷한 고통을 겪었습니다. 결국 선택한 기본 모드에서는 모든 것이 순조롭게 진행되었지만 testdisk만일의 경우를 대비해 백업을 준비했습니다.
선택할 수 있는 파티션이 많은 경우 전체 출력을 게시하는 것이 좋습니다. 그런 다음 좀 더 구체적인 도움을 얻을 수 있습니다.
편집하다
솔직히 말해서 저는 5 파티션/MBR 수수께끼 때문에 약간 혼란스럽습니다.
제가 제공할 수 있는 최선의 방법은 귀하의 경우 이미지를 복사하고 각 이미지에서 둘 이상의 파티션을 MBR로 복구하려고 시도한 다음(이미지를 SSD가 아닌 테스트 디스크에 마운트하여) 하는 것입니다. GPT 아키텍처를 사용하여 새 미디어에 디스크의 원래 파티션을 다시 구축합니다. 작동하는 경우 전체 Shebang을 SSD로 다시 마이그레이션하십시오. 모든 것을 설치하기 위해 다시 마이그레이션하는 경우 grubGUID를 다시 설치하고 사용해야 fstab하지만 이는 로켓 과학이 아닙니다.
무엇보다도 걱정 없이 이미지 사본에 원하는 것을 시도해 볼 수 있습니다. 원본 드라이브와 이미지 하나를 안전하게 보관하세요.