Recover Macbook APFS Partition












1















My question is very similar to this thread, but my situation is slightly different.



I have been successfully dual-booting OS X and Ubuntu for some time now with 2 partitions. I managed the partitions using OS X Disk Utility to avoid any partition table errors that Linux may incur given the new APFS structure.



Recently, I decided to shrink the OS X partition and create a 3rd partition as a dedicated swap partition for Ubuntu. Again, I managed the partitions in OS X Disk Utility to avoid errors. I successfully added the swap partition in Ubuntu (I am sure the correct partition was specified) and all seemed well. However, after I rebooted, the boot manager (stock, not rEFInd) was no longer showing OS X as a boot option. I decided to use gdisk (thank you Rod Smith for your incredible recovery tools!) to check the table structure, and it seems that the OS X partition is still recognized, but has been given the partition code FF. As far as I can tell the sectors all look good, leaving me to believe that all of my data is present. Unfortunately, I don't have a backup because my backup drive recently crapped out. Lucky me.



Can I simply change the type code of the OS X partition to rescue my data? From my understanding, APFS doesn't quite work that way.



Here is my output from gdisk -l:



Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Crucial_CT250MX2
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 37FE5D3B-875C-471A-B4FC-A4887DDA4659
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 8-sector boundaries
Total free space is 13 sectors (6.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 416425263 198.4 GiB FFFF
3 416425264 449628383 15.8 GiB FFFF
4 449628384 488397127 18.5 GiB 8300


Partition 2 is my OS X partition, partition 3 is my swap partition (not sure why its also marked FFFF instead of 8200?), and partition 4 is the Ubuntu partition.



Here is my output from swapon -s && free to prove I'm not a moron:



Filename                Type        Size    Used    Priority
/dev/sda3 partition 16601556 435456 -2

total used free shared buff/cache available
Mem: 16335648 2089764 374952 51452 13870932 14611436
Swap: 16601556 435456 16166100









share|improve this question

























  • Welcome to Ask Ubuntu and thank you for sharing your solution! Apparently your problem was different than mine linked above, luckily for you. :)

    – Andrea Lazzarotto
    Aug 17 '18 at 22:36
















1















My question is very similar to this thread, but my situation is slightly different.



I have been successfully dual-booting OS X and Ubuntu for some time now with 2 partitions. I managed the partitions using OS X Disk Utility to avoid any partition table errors that Linux may incur given the new APFS structure.



Recently, I decided to shrink the OS X partition and create a 3rd partition as a dedicated swap partition for Ubuntu. Again, I managed the partitions in OS X Disk Utility to avoid errors. I successfully added the swap partition in Ubuntu (I am sure the correct partition was specified) and all seemed well. However, after I rebooted, the boot manager (stock, not rEFInd) was no longer showing OS X as a boot option. I decided to use gdisk (thank you Rod Smith for your incredible recovery tools!) to check the table structure, and it seems that the OS X partition is still recognized, but has been given the partition code FF. As far as I can tell the sectors all look good, leaving me to believe that all of my data is present. Unfortunately, I don't have a backup because my backup drive recently crapped out. Lucky me.



Can I simply change the type code of the OS X partition to rescue my data? From my understanding, APFS doesn't quite work that way.



Here is my output from gdisk -l:



Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Crucial_CT250MX2
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 37FE5D3B-875C-471A-B4FC-A4887DDA4659
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 8-sector boundaries
Total free space is 13 sectors (6.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 416425263 198.4 GiB FFFF
3 416425264 449628383 15.8 GiB FFFF
4 449628384 488397127 18.5 GiB 8300


Partition 2 is my OS X partition, partition 3 is my swap partition (not sure why its also marked FFFF instead of 8200?), and partition 4 is the Ubuntu partition.



Here is my output from swapon -s && free to prove I'm not a moron:



Filename                Type        Size    Used    Priority
/dev/sda3 partition 16601556 435456 -2

total used free shared buff/cache available
Mem: 16335648 2089764 374952 51452 13870932 14611436
Swap: 16601556 435456 16166100









share|improve this question

























  • Welcome to Ask Ubuntu and thank you for sharing your solution! Apparently your problem was different than mine linked above, luckily for you. :)

    – Andrea Lazzarotto
    Aug 17 '18 at 22:36














1












1








1








My question is very similar to this thread, but my situation is slightly different.



I have been successfully dual-booting OS X and Ubuntu for some time now with 2 partitions. I managed the partitions using OS X Disk Utility to avoid any partition table errors that Linux may incur given the new APFS structure.



Recently, I decided to shrink the OS X partition and create a 3rd partition as a dedicated swap partition for Ubuntu. Again, I managed the partitions in OS X Disk Utility to avoid errors. I successfully added the swap partition in Ubuntu (I am sure the correct partition was specified) and all seemed well. However, after I rebooted, the boot manager (stock, not rEFInd) was no longer showing OS X as a boot option. I decided to use gdisk (thank you Rod Smith for your incredible recovery tools!) to check the table structure, and it seems that the OS X partition is still recognized, but has been given the partition code FF. As far as I can tell the sectors all look good, leaving me to believe that all of my data is present. Unfortunately, I don't have a backup because my backup drive recently crapped out. Lucky me.



Can I simply change the type code of the OS X partition to rescue my data? From my understanding, APFS doesn't quite work that way.



Here is my output from gdisk -l:



Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Crucial_CT250MX2
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 37FE5D3B-875C-471A-B4FC-A4887DDA4659
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 8-sector boundaries
Total free space is 13 sectors (6.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 416425263 198.4 GiB FFFF
3 416425264 449628383 15.8 GiB FFFF
4 449628384 488397127 18.5 GiB 8300


Partition 2 is my OS X partition, partition 3 is my swap partition (not sure why its also marked FFFF instead of 8200?), and partition 4 is the Ubuntu partition.



Here is my output from swapon -s && free to prove I'm not a moron:



Filename                Type        Size    Used    Priority
/dev/sda3 partition 16601556 435456 -2

total used free shared buff/cache available
Mem: 16335648 2089764 374952 51452 13870932 14611436
Swap: 16601556 435456 16166100









share|improve this question
















My question is very similar to this thread, but my situation is slightly different.



I have been successfully dual-booting OS X and Ubuntu for some time now with 2 partitions. I managed the partitions using OS X Disk Utility to avoid any partition table errors that Linux may incur given the new APFS structure.



Recently, I decided to shrink the OS X partition and create a 3rd partition as a dedicated swap partition for Ubuntu. Again, I managed the partitions in OS X Disk Utility to avoid errors. I successfully added the swap partition in Ubuntu (I am sure the correct partition was specified) and all seemed well. However, after I rebooted, the boot manager (stock, not rEFInd) was no longer showing OS X as a boot option. I decided to use gdisk (thank you Rod Smith for your incredible recovery tools!) to check the table structure, and it seems that the OS X partition is still recognized, but has been given the partition code FF. As far as I can tell the sectors all look good, leaving me to believe that all of my data is present. Unfortunately, I don't have a backup because my backup drive recently crapped out. Lucky me.



Can I simply change the type code of the OS X partition to rescue my data? From my understanding, APFS doesn't quite work that way.



Here is my output from gdisk -l:



Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Crucial_CT250MX2
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 37FE5D3B-875C-471A-B4FC-A4887DDA4659
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 8-sector boundaries
Total free space is 13 sectors (6.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 416425263 198.4 GiB FFFF
3 416425264 449628383 15.8 GiB FFFF
4 449628384 488397127 18.5 GiB 8300


Partition 2 is my OS X partition, partition 3 is my swap partition (not sure why its also marked FFFF instead of 8200?), and partition 4 is the Ubuntu partition.



Here is my output from swapon -s && free to prove I'm not a moron:



Filename                Type        Size    Used    Priority
/dev/sda3 partition 16601556 435456 -2

total used free shared buff/cache available
Mem: 16335648 2089764 374952 51452 13870932 14611436
Swap: 16601556 435456 16166100






dual-boot partitioning data-recovery gedit






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 15 '18 at 17:27







D. Mills

















asked Aug 15 '18 at 17:20









D. MillsD. Mills

164




164













  • Welcome to Ask Ubuntu and thank you for sharing your solution! Apparently your problem was different than mine linked above, luckily for you. :)

    – Andrea Lazzarotto
    Aug 17 '18 at 22:36



















  • Welcome to Ask Ubuntu and thank you for sharing your solution! Apparently your problem was different than mine linked above, luckily for you. :)

    – Andrea Lazzarotto
    Aug 17 '18 at 22:36

















Welcome to Ask Ubuntu and thank you for sharing your solution! Apparently your problem was different than mine linked above, luckily for you. :)

– Andrea Lazzarotto
Aug 17 '18 at 22:36





Welcome to Ask Ubuntu and thank you for sharing your solution! Apparently your problem was different than mine linked above, luckily for you. :)

– Andrea Lazzarotto
Aug 17 '18 at 22:36










1 Answer
1






active

oldest

votes


















1














I solved my problem by following this thread's solution and using the GUID 7C3457EF-0000-11AA-AA11-00306543ECAC as my original OS X partition was an APFS container rather than an HFS partition or Logical Volume.



In summary:



1. Boot Mac in Recovery mode (Hold Cmd+R while booting)
2. Open Utilities->Terminal
3. "diskutil list" to identify the partition in question (for me, disk0s2 was marked with GUID FFFF...)
4. gpt -r show disk0" to provide the start sector and size of the disk0 partitions. The output here is very similar to the gdisk -l output of my original post above.
5. "diskutil unmountDisk disk0" to allow the next step...
6. "gpt remove -i 2 disk0" to strip the partition table data associated with the broken partition.
7. "gpt add -b 409640 -i 2 -s 416425263 -t 7C3457EF-0000-11AA-AA11-00306543ECAC"


Part 7 is the most critical step. It adds the correct data to the partition table and recovers the lost partition. Here is the breakdown of the instruction:



'-b' is the beginning sector of the partition as observed in step 4.
'-i' is the index of the partition to be recovered; in my case, this was disk0s2, so index position 2.
'-s' is the size of the partition as observed in step 4.
'-t' is the GUID type of the partition. Specifically, the originally broken data preventing use of the partition (previously marked FFFF...).





share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1065640%2frecover-macbook-apfs-partition%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    I solved my problem by following this thread's solution and using the GUID 7C3457EF-0000-11AA-AA11-00306543ECAC as my original OS X partition was an APFS container rather than an HFS partition or Logical Volume.



    In summary:



    1. Boot Mac in Recovery mode (Hold Cmd+R while booting)
    2. Open Utilities->Terminal
    3. "diskutil list" to identify the partition in question (for me, disk0s2 was marked with GUID FFFF...)
    4. gpt -r show disk0" to provide the start sector and size of the disk0 partitions. The output here is very similar to the gdisk -l output of my original post above.
    5. "diskutil unmountDisk disk0" to allow the next step...
    6. "gpt remove -i 2 disk0" to strip the partition table data associated with the broken partition.
    7. "gpt add -b 409640 -i 2 -s 416425263 -t 7C3457EF-0000-11AA-AA11-00306543ECAC"


    Part 7 is the most critical step. It adds the correct data to the partition table and recovers the lost partition. Here is the breakdown of the instruction:



    '-b' is the beginning sector of the partition as observed in step 4.
    '-i' is the index of the partition to be recovered; in my case, this was disk0s2, so index position 2.
    '-s' is the size of the partition as observed in step 4.
    '-t' is the GUID type of the partition. Specifically, the originally broken data preventing use of the partition (previously marked FFFF...).





    share|improve this answer




























      1














      I solved my problem by following this thread's solution and using the GUID 7C3457EF-0000-11AA-AA11-00306543ECAC as my original OS X partition was an APFS container rather than an HFS partition or Logical Volume.



      In summary:



      1. Boot Mac in Recovery mode (Hold Cmd+R while booting)
      2. Open Utilities->Terminal
      3. "diskutil list" to identify the partition in question (for me, disk0s2 was marked with GUID FFFF...)
      4. gpt -r show disk0" to provide the start sector and size of the disk0 partitions. The output here is very similar to the gdisk -l output of my original post above.
      5. "diskutil unmountDisk disk0" to allow the next step...
      6. "gpt remove -i 2 disk0" to strip the partition table data associated with the broken partition.
      7. "gpt add -b 409640 -i 2 -s 416425263 -t 7C3457EF-0000-11AA-AA11-00306543ECAC"


      Part 7 is the most critical step. It adds the correct data to the partition table and recovers the lost partition. Here is the breakdown of the instruction:



      '-b' is the beginning sector of the partition as observed in step 4.
      '-i' is the index of the partition to be recovered; in my case, this was disk0s2, so index position 2.
      '-s' is the size of the partition as observed in step 4.
      '-t' is the GUID type of the partition. Specifically, the originally broken data preventing use of the partition (previously marked FFFF...).





      share|improve this answer


























        1












        1








        1







        I solved my problem by following this thread's solution and using the GUID 7C3457EF-0000-11AA-AA11-00306543ECAC as my original OS X partition was an APFS container rather than an HFS partition or Logical Volume.



        In summary:



        1. Boot Mac in Recovery mode (Hold Cmd+R while booting)
        2. Open Utilities->Terminal
        3. "diskutil list" to identify the partition in question (for me, disk0s2 was marked with GUID FFFF...)
        4. gpt -r show disk0" to provide the start sector and size of the disk0 partitions. The output here is very similar to the gdisk -l output of my original post above.
        5. "diskutil unmountDisk disk0" to allow the next step...
        6. "gpt remove -i 2 disk0" to strip the partition table data associated with the broken partition.
        7. "gpt add -b 409640 -i 2 -s 416425263 -t 7C3457EF-0000-11AA-AA11-00306543ECAC"


        Part 7 is the most critical step. It adds the correct data to the partition table and recovers the lost partition. Here is the breakdown of the instruction:



        '-b' is the beginning sector of the partition as observed in step 4.
        '-i' is the index of the partition to be recovered; in my case, this was disk0s2, so index position 2.
        '-s' is the size of the partition as observed in step 4.
        '-t' is the GUID type of the partition. Specifically, the originally broken data preventing use of the partition (previously marked FFFF...).





        share|improve this answer













        I solved my problem by following this thread's solution and using the GUID 7C3457EF-0000-11AA-AA11-00306543ECAC as my original OS X partition was an APFS container rather than an HFS partition or Logical Volume.



        In summary:



        1. Boot Mac in Recovery mode (Hold Cmd+R while booting)
        2. Open Utilities->Terminal
        3. "diskutil list" to identify the partition in question (for me, disk0s2 was marked with GUID FFFF...)
        4. gpt -r show disk0" to provide the start sector and size of the disk0 partitions. The output here is very similar to the gdisk -l output of my original post above.
        5. "diskutil unmountDisk disk0" to allow the next step...
        6. "gpt remove -i 2 disk0" to strip the partition table data associated with the broken partition.
        7. "gpt add -b 409640 -i 2 -s 416425263 -t 7C3457EF-0000-11AA-AA11-00306543ECAC"


        Part 7 is the most critical step. It adds the correct data to the partition table and recovers the lost partition. Here is the breakdown of the instruction:



        '-b' is the beginning sector of the partition as observed in step 4.
        '-i' is the index of the partition to be recovered; in my case, this was disk0s2, so index position 2.
        '-s' is the size of the partition as observed in step 4.
        '-t' is the GUID type of the partition. Specifically, the originally broken data preventing use of the partition (previously marked FFFF...).






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 15 '18 at 23:14









        D. MillsD. Mills

        164




        164






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1065640%2frecover-macbook-apfs-partition%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Category:香港粉麵

            List *all* the tuples!

            Channel [V]