Background
I use a Macbook Pro that has High Sierra and Fedora in dual-boot. I wasn't using Fedora so I wanted to try Ubuntu 17.10 and I ran a live USB (booting in EFI mode).
Given that all my work-related files, projects, and other "important stuff" (on the Mac side) are already backed up via either Dropbox or remote Git repositories, I decided to delete Fedora and install Ubuntu without doing a full bitstream image of the drive.
At first I deleted the Fedora related partitions using Gnome Disks (this is OK). I started the Ubuntu installer and I did these steps:
- Selected a language > Continue
- Checked "Download updates while installing Ubuntu" > Continue
- Chose "Something else" for the partitions > Continue
- Mistakenly set the type of
/dev/sda2as "Physical volume for encryption" and added my password
Please note that I did not chose to "Overwrite empty disk space". I also did not continue with the installation (I didn't reach the point when it asks you to confirm the new partition table). Rather, I clicked "Back" and then closed the installer immediately.
This should not have written anything to disk. However, the Ubuntu installer decided to write something anyway, it seems.
Problem
After rebooting quickly, it was clear that something wrong has been written on disk despite never reaching the confirmation step. The type of the partition has been changed and neither rEFInd (which loads correctly) nor the Apple boot screen can find macOS.
This is the output of lsblk:
NAME FSTYPE LABEL UUID MOUNTPOINT
loop0 squash /rofs
sda
├─sda1 vfat EFI 67E3-17ED
├─sda2 crypto 9b2ca99d-cf43-4d35-936d-be37db7b950d
└─sda3
Originally, sda2 was APFS. In macOS Filevault was enabled, however I can't tell if it was using CoreStorage or native APFS encryption (I suspect the latter as it was migrated from an older version with HFS+).
Running diskutil list from the Apple Internet recovery yields this:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: 7C3457EF-0000-11AA-AA11-00306543ECAC 349.7 GB disk0s2
3: 5361644D-6163-11AA-AA11-00306543ECAC 1.3 GB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *1.3 GB disk1
1: Apple_partition_map 30.7 KB disk1s1
2: Apple_HFS OS X Base System 1.3 GB disk1s2
The second device is the Internet recovery.
Strangely, also /dev/sda3 aka disk0s3 is not recognized, despite never being touched in any way. So the Mac now doesn't even boot the local recovery but it relies on the Internet based one.
Back on Ubuntu, parted complains about a corrupted GPT, but gdisk thinks it is fine. Here's the output of parted -l:
Model: ATA APPLE SSD SM0512 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 20.5kB 210MB 210MB fat32 EFI System Partition boot, esp
2 210MB 350GB 350GB
3 350GB 351GB 1306MB
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh
table, and using Parted's rescue feature to recover partitions.
Questions
Most importantly, how can I use Ubuntu to fix the GPT table and set the correct file system type for /dev/sda2 and /dev/sda3?
Secondly, does the Ubuntu installer write stuff on the partition table even before confirming the changes? Is this intended behavior?
Are there chances to recover the system without reinstalling? As I said, I have backups of the valuable data. What worries me is that I will lose a lot of time for reinstalling applications and things like that.
You wrote:
Given your subsequent problems, I'd say that either the Ubuntu installer wrote to the disk immediately or something else damaged the partition in a coincidence of timing. Either way, your best hope for recovery lies on the macOS side. APFS is simply too new to have any native Linux recovery tools, at least as far as I know. Even if such tools were available in Linux, I'd be a little wary of them. I suggest you ask about recovery on a Mac forum. You might or might not get anything back, though; APFS is new enough that there's not yet much expertise available about recovering damaged filesystems, and it's conceivable that the Ubuntu installer (or whatever caused the damage) overwrote something truly critical. This is especially true if you used encryption on the macOS side -- although encryption has some big advantages, one big drawback is that minor filesystem damage can greatly complicate recovery, perhaps to the point of making it impossible. (I don't know how APFS fares in this respect.)
The
partedoutput you quoted is pretty unclear about the nature of the alleged damage, and you've not provided any output fromgdisk. In particular, thevoption fromgdisk(orsgdisk -v) might be helpful, as would be the complete output from when you launchgdiskand typep(or typesudo gdisk -l). You might have overlooked agdiskwarning; or it might have silently repaired some trivial problem that's provoking a complaint byparted; orpartedmight be complaining about something that's not really damage and thatgdiskaccepted; orpartedmight have noticed a problem thatgdiskdidn't. The distinctions between some of these things may be subjective -- although the GPT specification is much clearer than the non-existent MBR specification, it's got some ambiguities, so one program might interpret something unusual as damage whereas another might think it's OK. If the partition table is damaged, thegdiskpage on repairing GPT damage may be helpful. (Note: I'm the author ofgdisk.) Without knowing precisely whatgdiskthinks of the disk, though, I can't offer more specific advice on how to repair it, or even if it needs repair.