Tuesday, January 6, 2015

macos - The Mac OS X package installer doesn’t display the file system partition on which Mac OS X is installed


When a package, in a .pkg file, needs to be installed on a Mac OS X system, the package installer provided with the system is used. At some point in the installation of any package, it asks on which file system partition it should install the package. On my system, it used to show the partition on which Mac OS X is installed, which is called “Macintosh HD”, but it does not anymore due to reasons I am unaware of, and instead only shows the two recovery partitions both called “Recovery HD”; this effectively makes me unable to install anything using a package installer. Furthermore, the system partition is also absent from the choices available in the Mavericks installer, which means this problem also prevents me from upgrading my system from Mountain Lion to Mavericks.


I have told the disk utility to repair the hard drive, but it hasn’t found any problem. I have also wanted to repair the system partition, but it was absent from the list of partitions in the disk utility. I was later able to have it displayed by enabling the disk utility’s debug mode and although the repair option was grayed, I was able to run a verification that found no problem and to repair the permissions.


Furthermore, the “Partition” tab of the disk utility, when the hard drive is selected, claims the place where the system partition should be is actually 207.91 GB of free space. There are some other partitions I have previously used to run a Debian system, but I have since then erased them and they are now empty partitions.


Finally, I am unable to change the partition layout at all from the “Partition” tab of the disk utility when the hard drive is selected: every time I attempt to delete a partition or to apply a change, it tells me the change asked is too small and refuses to perform it.


My current system is Mac OS X 10.8.5 running on a Mac mini.


Answer



Okay, your GPT is all jacked up. A lot of your partitions are marked with the wrong partition types. Your PMBR looks perfect though, so that's good.


Let's look at your GPT (Make sure to make your window W-I-D-E or scroll horizontally to see the "should be" column):



start size index contents - "Label" type should be
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - "EFI system partition" EFI system partition
409640 404390464 2 GPT part - "Macintosh HD" Apple_Boot HFS+
404800104 1269544 3 GPT part - "Recovery HD" EFI system partition Apple_Boot
406069648 1269544 4 GPT part - "Recovery HD" HFS+ Apple_Boot (or just delete it)
407339192 1269536 5 GPT part - "Recovery HD" HFS+ Apple_Boot (or just delete it)
408608728 40
408608768 279976563 6 GPT part - "Ubuntu" Apple_Boot Linux filesystem data?
688585331 1421
688586752 974848 7 GPT part - "" EFI system partition Not sure? Maybe just delete it?
689561600 13410304 8 GPT part - "Apple_HFS_Untitled_6" HFS+
702971904 262144
703234048 5597184 9 GPT part - "Apple_HFS_Untitled_5" HFS+
708831232 262144
709093376 780288 10 GPT part - "Apple_HFS_Untitled_4" HFS+
709873664 258428928 11 GPT part - "Apple_HFS_Untitled_3" HFS+
968302592 262144
968564736 7946248 12 GPT part - "Apple_HFS_Untitled_2" HFS+
976510984 262151
976773135 32 Sec GPT table
976773167 1 Sec GPT header

So it looks like your partitions at indexes 2, 3, 4, 5, 6, and 7 are all marked as the wrong partition types in the GPT, and maybe some of them can be deleted if you don't have any valuable data on them. I'm also not sure why you have a bunch of smallish HFS+ partitions, like the one at index 10 that's just 390 MB (381 MiB). Did you put those there intentionally or know what they are and what's on them? Or are they also part of the mystery of this strangely messed up partition table?


I should state that I don't know much about how Debian likes to partition disks, especially on Mac hardware. I know that once upon a time, Linux distros on Windows PCs with GPT used a Windows partition type for Linux filesystems, but I think that old method is falling out of favor today. Perhaps its possible that Debian used Apple-style partition type markers in the GPT but then "on the inside" used them as linux filesystem and swap partitions?


One way to fix this would be to use the gpt command to remove the partition table entries that have the wrong type, then re-add them again with the correct type. This is tricky work, and you have a great chance of losing an entire partition or everything on the drive if you make a mistake.


But it would go something like this:


Remove the "bad" entry for "Macintosh HD" that had type Apple_Boot (that GUID starting 426...):


sudo gpt remove -b 409640 -s 404390464 -i 2 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0

Add a "good" entry for it, this time with type HFS+ (that GUID starting 484...):


sudo gpt add    -b 409640 -s 404390464 -i 2 -t 48465300-0000-11AA-AA11-00306543ECAC disk0

Now label it "Macintosh HD" again:


sudo gpt label  -b 409640 -s 404390464 -i 2 -l "Macintosh HD" disk0

Note that in the "remove" and "label" commands, I'm selecting the partition in more than one way. That's me being extra-careful to avoid typos; if all three selector types don't match, I don't want the command to work, because it means I made a typo.


Note that you'll have to do these commands while booted from some other device, so the disk you're editing won't be busy. Be very careful with the starting/beginning block and size/length numbers. Edit partition tables at your own risk. Have a full backup (and TEST YOUR BACKUP) of everything you care about before editing your partition table.


No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...