I assumed I wanted a 1TB partition, split over blocks of 512k - so 1000000000000 / 512 = 1953125000Īfter creating the partition at that size, it didn't work, so I ran a verifyVolume on the APFS Container diskutil verifyVolume disk0s2Īnd that failed with warning: nx_block_count is 244139436, while device block count is 234379555 I initially created the new partition with the incorrect size. The KEY part here is working out the correct Size - in my case - 1953115488.ĭavid explains how to find the correct values in this post here. You are a legend!įor anyone else who has this issue - this is what I did:įirst remove the 2 incorrect partitions sudo gpt remove -i 2 /dev/disk0Īnd then add back in the new APFS partition sudo gpt add -i 2 -b 409640 -s 1953115488 -t apfs /dev/disk0 Thanks to David Anderson for his previous detailed posts here and here I managed to work it out and restore the partitions. Is there anything I can do to rebuild the partition table back to a healthy APFS Volume state? dev/disk5 (synthesized):Ġ: APFS Container Scheme - +499.9 GB disk5Ģ: APFS Volume HD - Data 231.6 GB disk5s2īefore the partition data was damaged, it has a Container and two disks HD and HD - Data. UPDATE: here is the same data from the 500GB HD that was cloned onto the 1TB drive - if seeing how it used to be is any help. Turns out testDisk doesn't recognise APFS Containers and it has written it back incorrectly. I didn't make any changes intentionally to the disk layout, but since then it is messed up. I regretfully deployed testDisk - intending to look, but ended up saving the partition table. I have booted of an SD card and I could see the drive and browse it as read only. This week it decided to stop booting - was just hanging on the loading screen.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |