Để thêm một câu trả lời phù hợp chính xác với trường hợp của bạn, tôi đã sửa đổi một chút câu trả lời của mình trong " bản sao " được liên kết và đăng lại ở đây.
Phân vùng thứ hai cũng như phân vùng thứ ba của đĩa bên trong của bạn có loại phân vùng sai, dữ liệu của bạn có thể sẽ không bị mất.
Phân vùng OS X có khả năng khởi động (ngoại trừ Recovery HD) hoặc có GUID 48465300-0000-11AA-AA11-00306543ECAC cho phân vùng OS X tiêu chuẩn hoặc phân vùng GUID 53746F72-6167-11AA-AA11-00306543ECAC cho phân vùng CoreStorage. FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF là một loại phân vùng không xác định (nhưng không có phân vùng như 000000-0000-0000 .... một).
Khối đầu tiên của phân vùng OS X tiêu chuẩn không chứa số không, khối đầu tiên của phân vùng CoreStorage chứa một số số không. Để có được 3 khối đầu tiên của phân vùng, bạn phải sử dụng thay thế cho hexdump / xxd (cả hai đều không có trong ổ đĩa khởi động Recovery Mode / OS X Installer). Điều tốt nhất tôi đã tìm thấy là dd if=/dev/diskXsY count=3 | vis -c.
Bảng phân vùng GUID có thể được sửa đổi với gpt. gpt chỉ ghi vào 34 khối đầu tiên và 33 khối cuối cùng của đĩa (512) hoặc 6 khối đầu tiên và 5 khối cuối cùng của đĩa 4k. Sửa đổi bảng phân vùng (thậm chí sai) không làm thay đổi nội dung của bất kỳ ổ đĩa nào trên đĩa của bạn, nếu bạn không khởi tạo hoặc sửa chữa ổ đĩa / đĩa theo yêu cầu. Bạn có thể xác minh nó mặc dù.
- Khởi động vào Chế độ khôi phục Internet hoặc ổ đĩa khởi động Trình cài đặt OS X
- Mở Terminal trong menu tiện ích> Terminal
- Nhận tổng quan với
diskutil list
Nhận tổng quan về đĩa bên trong của bạn với mã định danh đĩa được tìm thấy trong lệnh trước đó. Dưới đây tôi giả sử định danh đĩa của đĩa bên trong của bạn là đĩa0 (thay thế nó bằng cái bạn đã tìm thấy trong môi trường của bạn)
gpt -r show disk0
- Ngắt kết nối đĩa0 với
diskutil umountDisk disk0
vis 3 khối đầu tiên của phân vùng FFFF ...:
dd if=/dev/disk0s2 count=3 | vis -c
Nếu bạn đã có một phân vùng tiêu chuẩn trước đó thì 1024 Byte đầu tiên chỉ chứa không thể in được (số không): \ 0 \ 0 ... Tại ~ Byte 1030, bạn sẽ thấy chuỗi sau: \ 0HFSJ \ 0
Nếu bạn có phân vùng CoreStorage, một số số không trong 512 byte đầu tiên và chuỗi CS ( ...\0CS\^A...) được hiển thị:
\^U\^D\^A\M-s\M^?\M^?\M^?\M^?\^A\0\^P\0\0\0\M-W\^A\a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^Pu\M-\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0CS\^A\0\0\0\^D\0\0\^P\0\0\0\0@\0X\M-7}\^C\0\0\0\0X\M-;}\^C\0\0\0\0X\M-?}\^C\0\0\0\0X\M-C}\^C\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\0\0\0\^B\0\0\0006j v\^R\M-+\^U\M^[\f\M^CdG\M-y\^]...
Bây giờ loại bỏ phân vùng thứ ba, thứ tư và thứ hai:
diskutil umountDisk disk0
gpt remove -i 3 disk0
diskutil umountDisk disk0
gpt remove -i 4 disk0
gpt remove -i 2 disk0
Nếu bạn nhận được thông báo lỗi như "tài nguyên bận", chỉ cần ngắt kết nối lại đĩa hoặc ngắt kết nối các ổ cứng đầu diskutil umount disk0sX.
Thêm lại phân vùng phục hồi với loại thích hợp nhưng cùng số chỉ mục, bắt đầu khối và kích thước trước đó:
gpt add -i 3 -b 227212504 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
Thêm lại phân vùng chính với loại thích hợp nhưng cùng số chỉ mục, bắt đầu khối và kích thước trước đó:
Phân vùng OS X bình thường (nếu bạn đã tìm thấy dấu vết điển hình của phân vùng bình thường trong dd ... visbước):
gpt add -i 2 -b 409640 -s 226802864 -t 48465300-0000-11AA-AA11-00306543ECAC disk0
hoặc (nếu bạn đã tìm thấy dấu vết điển hình của phân vùng CoreStorage):
gpt add -i 2 -b 409640 -s 226802864 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Đĩa của bạn cuối cùng sẽ trông như thế này nếu bạn đã tìm thấy phân vùng OS X tiêu chuẩn:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 226802864 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
227212504 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
228482040 8496103
236978143 32 Sec GPT table
236978175 1 Sec GPT header
hoặc điều này, nếu bạn đã tìm thấy một khối CoreStorage:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 226802864 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
227212504 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
228482040 8496103
236978143 32 Sec GPT table
236978175 1 Sec GPT header
Cuối cùng xác minh / sửa chữa đĩa với diskutil verifyDisk disk0và / hoặc diskutil verifyVolume disk0s2. Nếu cần sửa chữa, hãy sử dụng sửa chữa (thay vì xác minh) làm tiền tố trong các lệnh trên nhưng liên hệ với tôi trước khi sửa chữa và gửi cho tôi thông báo lỗi .
Các nghiên cứu sâu hơn thông qua các phiên TeamViewer cho thấy phân vùng EFI và phân vùng Recovery HD bị hỏng. Khối lượng chính được mã hóa. Recovery HD chứa khóa FileVault trung gian đặc biệt sau đó. Nếu thiếu khóa, hệ thống chính sẽ không khởi động. Có thể mở khóa ổ đĩa mặc dù với diskutil cs unlockVolume ....
Sau khi cài đặt macOS đầy đủ vào ổ đĩa ngón tay cái và khởi động vào nó, phân vùng EFI và Recovery HD của một ổ đĩa không phải FileVault khác (thực tế là của một máy ảo Sierra) đã được đưa vào ổ đĩa bị hỏng. Vẫn được khởi động từ ổ ngón tay cái, âm lượng FileVault được hoàn nguyên về âm lượng tiêu chuẩn bằng cách nhấp chuột phải vào âm lượng trong Finder, chọn "Giải mã âm lượng" và nhập mật khẩu người dùng hợp lệ. Đây phải là mật khẩu của tài khoản người dùng đủ điều kiện trên ổ đĩa FileVault. Các phương pháp khác để giải mã âm lượng như diskutil cs revert lvUUIDhoặc diskutil cs decryptVolume lvUUID- chỉ được thử nghiệm trong một máy ảo - dường như không hoạt động. Điều này có thể là một hạn chế của VM mặc dù.
Để mở rộng phân vùng chính (đĩa0s2) lên kích thước đầy đủ, hãy sử dụng Disk Utility hoặc diskutil resizeVolume ...lệnh.
Âm lượng ban đầu không xuất hiện trong Tùy chọn hệ thống> Đĩa khởi động, nhưng altviệc mở rộng máy Mac đã tiết lộ âm lượng chính. Điều này có lẽ đã ban phước lại cho boot.efi của âm lượng. Âm lượng (bây giờ là tiêu chuẩn) lại xuất hiện trong Startup Disk.
