partitioning - A new startup disk was created when trying to install Debian (Mac OS X 10.7.3)
2013-08
First, I tried to install Debian on my Mac. After giving that up and deleting all the unused partitions, I found, in rEFIt, a Linux startup volume even though no Linux distribution is installed — there is not even a partition. So I open the partition inspector to synchronise, and after a quick restart, no difference.
Finally, after uninstalling rEFIt, I can boot into Mac OS X fine. However, when holding option to list available startup disks, I find Macintosh HD, Windows, and the recovery HD. I can't figure out why the Mac detects this missing Windows/Linux partition. How do I get rid of it, or at least why this is happening?
I don't know if I was particularly clear on this, but the partition isn't there, just Macintosh HD, the EFI System partition, and the Recovery HD. Nothing else....
If it was a partition, I would be very able to fix it with GParted. Also, if I was to reinstall Mac OS X v10.7 (Lion). How could I guarantee it would rebuild my PMBR and GPT? I do not have the install disk (it was preinstalled), just the recovery HD... It does not show up in disk utility or any other command line tools.
This is what I don't understand.
Anyway, here is some output...
diskutil list
**/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 499.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3**
sudo gpt -r show -l /dev/disk0
gpt show: /dev/disk0: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - "EFI system partition"
409640 975093952 2 GPT part - "Customer"
975503592 1269536 3 GPT part - "Recovery HD"
976773128 7
976773135 32 Sec GPT table
976773167 1 Sec GPT header
sudo gpt -r show /dev/disk0
gpt show: /dev/disk0: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 975093952 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
975503592 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
976773128 7
976773135 32 Sec GPT table
976773167 1 Sec GPT header
sudo fdisk /dev/fdisk0
Disk: /dev/disk0 geometry: 60801/255/63 [976773168 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 976773167] <Unknown ID>
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
and if it helps, the output from rEFIt's own, Partition inspector...
*** Report for internal hard disk ***
Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 975503591 Mac OS X HFS+
3 975503592 976773127 Mac OS X Boot
Current MBR partition table:
# A Start LBA End LBA Type
1 1 976773167 ee EFI Protective
MBR contents:
Boot Code: GRUB
Partition at LBA 40:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 1, type EFI System (FAT)
Partition at LBA 409640:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 2, type Mac OS X HFS+
Partition at LBA 975503592:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 3, type Mac OS X Boot
I hope this helps.
I have been meddling around alot with Linux + OS X on my Mac, and it is my experience that the standard OS X tools will not touch your Linux partitions.
The above heuristic indicates that OS X will not delete your Linux partition.
To delete the Linux partition, I would re-install OS X. As a bonus, this solution would definitely clear out any lingering MBR/GPT/auxiliary problems that could potentially bug or irritate you in the future.
The strong-willed and competent individual would solve the problem using GParted - but, in the process, a typo, power loss or freak incident could loose you all you data. So best back up beforehand. And if that is done anyway, why not go the extra 45 minutes and re-install, obtaining a clean system in the process?
Reading this advice, please bear in mind that it was given by someone who's learning *NIX administration the phenomenological way - a more competent individual will surely be able to provide you with the tips needed.
But, in the end, why waste time debugging someone else's errors? No - nuke it, and get on with your life!
Cheers, Troels
Intel-based Macs require your boot drive to use the more modern GUID Partition Table (GPT) rather than the legacy Master Boot Record (MBR) to keep track of how the hard drive has been partitioned. For compatibility with OSes that aren't GPT-savvy, drives that use the GPT still have a Pseudo MBR (PMBR) that basically mirrors the information that's in the GPT.
It's important that the tools you use to repartition your hard drive or otherwise edit your GPT or your PMBR keep them both in sync. If they get out of sync, then any non-GPT-savvy tools will just look at the PMBR and give one view of how the drive is partitioned, and the GPT-savvy tools will look at the GPT and give a different view of how the drive is partitioned.
Different tools for different OSes tend to focus on certain partition types they know best, and may not accurately report the partition type for other partitions if it's not a type they recognize. Or they might just outright omit listing unrecognized partitions. Adding to the difficulty, Mac OS X's Disk Utility won't show you certain kinds of partitions it knows about, such as Mac OS X recovery partitions.
From within Mac OS X, to get a quick view of the connected hard drives and volumes it knows about, you can use
diskutil list
To see a more detailed, low-level view of the contents of the drive's GPT, use:
sudo gpt -r show /dev/disk0
sudo gpt -r show -l /dev/disk0
Replace /dev/disk0
with the path to the device special file for the disk in question, if needed. The first version of the command shows the partition/volume type identifiers (a bunch of long GUIDs you can look up here). The second version of the command shows the volume labels (names). I usually like to see the output of both of those, so I can match up volume names to types.
To see what's in your PMBR, try:
sudo fdisk /dev/disk0
On my current machine, the fdisk
output indicates that my PMBR thinks my drive is just one big partition of a type fdisk
doesn't recognize, even though gpt
shows that I have several different HFS+ and Mac OS X recovery partitions. I presume that if I had ever Boot Camped this drive, or used rEFIt on it, that the PMBR would know the specifics of some of the partitions, rather than showing the drive as one big chunk.
Update your Question with the output of those diskutil
, gpt
, and fdisk
commands, and we may be able to help you even more.
Oh, and to get rid of the unwanted partition, just use Mac OS X's Disk Utility to delete it, and then grow the partition "above" it in Disk Utility's display into the space it was using.
Update: gpt show
on my system doesn't have that output line about the suspicious MBR, so it makes me wonder what's suspicious about yours. Perhaps it's just the fact that you still have GRUB bootloader code in your MBR, whereas typical Mac GPT PMBR's don't have any boot code in them at all.
Also, I'd forgotten that the EFI System Partition is technically FAT32 (even though it's given a special GUID). I wonder if there's something about your MBR (like the presence of GRUB), or some contents of your EFI System Partition, that is making your Mac's EFI bootROM see it as a Windows partition instead of just being an EFI System Partition.
To inspect your EFI system partition, you can force Mac OS X to mount it like this:
sudo mkdir /mnt
sudo mount -t msdos /dev/disk0s1 /mnt
My EFI partition basically just contains:
/EFI /APPLE /EXTENSIONS /FIRMWARE
...plus the update files from the last EFI firmware update I installed on this machine, as well as some typical Mac OS X turd files like .Trashes/
. It would be interesting to know what your EFI system partition has in it.
The other notable difference between your system and mine is that rEFIt's Partition Inspector reports my MBR boot code as "None", whereas you have GRUB in yours. I wonder if forcing Disk Utility to touch your partition tables—like by slightly shrinking, then regrowing, your main HFS+ partition—would force the MBR to get touched, the the GRUB code to be overwritten (zeroed out).
I finally managed to get rid of that weird icon, and install Ubuntu. It turns out I had installed GRUB to the MBR, and since rEFIt. Apparently I didn't know any better; it called it Linux...
A quick
fdisk -u /dev/disk0
cleared the MBR and solved it.
I recently installed Ubuntu 9.10 on my macbook, hoping to create a dual boot system... I use rEFIt to boot.
Installation went great, up until insatllation of grub. Trying to create a dual boot system, I have a handful of partitions, and Ubuntu didn't ask where to put grub; it just choose a partition and put it there.
In the past, Debian worked well with grub and Debian in the same partition. (Debian, macbook and drivers is a high-maintenance trilogy, though...)
This is what Partition Inspector says:
*** Report for internal hard disk ***
Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 332556807 Mac OS X HFS+
3 332820480 391414229 EFI System (FAT)
4 391414230 440242355 Basic Data
5 440242356 476678383 Basic Data
6 476678384 488397134 Linux Swap
Current MBR partition table:
# A Start LBA End LBA Type
1 1 409639 ee EFI Protective
2 * 409640 332556807 af Mac OS X HFS+
3 332820480 391414229 83 Linux
4 391414230 440242355 83 Linux
MBR contents:
Boot Code: Unknown, but bootable
Partition at LBA 40:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 1, type EFI System (FAT)
Partition at LBA 409640:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 2, type Mac OS X HFS+
Listed in MBR as partition 2, type af Mac OS X HFS+, active
Partition at LBA 332820480:
Boot Code: None
File System: ext3
Listed in GPT as partition 3, type EFI System (FAT)
Listed in MBR as partition 3, type 83 Linux
Partition at LBA 391414230:
Boot Code: None
File System: ext3
Listed in GPT as partition 4, type Basic Data
Listed in MBR as partition 4, type 83 Linux
Partition at LBA 440242356:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 5, type Basic Data
Partition at LBA 476678384:
Boot Code: None
File System: Unknown
Listed in GPT as partition 6, type Linux Swap
I'm pretty sure grub was put in GPT #3. I want it to be in GPT #4, where Ubuntu is. How do I move it, ie. do the old uninstall/install?
LiveUSB? LiveCD? What do I write in Terminal...?
Cheers!
There's a good Grub 2 Guide on Ubuntu Forums; this is what I used during my recent Grub2 adventure. Here's another good Grub2 guide, and Ubuntu's Grub2 wiki page.
You "uninstall" Grub from a partition by overwriting the boot code it wrote into the boot sector of that partition. Ideally, you'd have a backup of what was there before Grub was installed to it. I don't believe Grub creates this backup for you, so if you want something particular there (other than Grub), you'll need another tool to provide it.
If you want, you can completely uninstall the Grub package, then reinstall (I doubt this is necessary). To do this from a LiveCD system you'll need to chroot into the system you're trying to fix.# chroot (assumes you've mounted the partition to fix to /mnt) sudo mount --bind /dev /mnt/dev sudo chroot /mnt # backup! cp /etc/default/grub /etc/default/grub.old cp -R /etc/grub.d /etc/grub.d.old cp -R /boot/grub /boot/grub.old # purge apt-get purge grub2 grub-pc # reinstall apt-get install grub2 grub-pc # grub install -- make sure /dev/sda is the right drive!! grub-install /dev/sda4 update-grub
If everything went well, you can exit your chroot, unmount your filesystems (/mnt/dev first), and reboot.If all you need to do is install Grub to the correct partition, all you really need to do is boot into a LiveCD/LiveUSB, mount your system partition, check that your system's
/boot/grub
is correctly set, and rungrub-setup
. If you need to reconfigure the Grub menu or perform other steps, use a chroot procedure as described earlier.
Let's assume you've booted the LiveCD and mounted your system drive to/mnt
. Check that/mnt/boot/grub
exists, and contains the proper files (a bunch of*.mod
files, a few.img
files, andgrub.cfg
). If so, run this (not from chroot):# install grub to partition boot sector on sda4 # this assumes the partition table you show is on /dev/sda # make sure path & device are correct !!! sudo grub-setup -d /mnt/boot/grub /dev/sda4