EFI boot partition gets auto mounted

[dino7777]

Hello,

 

I know that there is plenty of information out there about this problem.

But believe me, I could not find a solution. So I post this issue of mine:

 

I have made a (usually) hidden EFI partition bootable with the "munky" method. Afterwards I have installed Chameleon on this partition.

 

But my EFI partition isn't invisible. It gets auto-mounted. Shown in Finder.

 

I figured out that for SL the munky method had to be modified, i.e. to use

$ newfs_hfs -v EFI /dev/diskXsY

 

So I did the same procedure, but this time using newfs_hfs command.

 

Anyway, still visible.

Its even visible and accessible in Linux and partition type is shown as ef, not ee like other hfs+ partitions.

diskutil also shows that theres a difference between this EFI (boot) partition, and any another EFI partition of an other disk:

/dev/disk0

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *640.1 GB disk0

1: Apple_HFS EFI 209.7 MB disk0s1

2: Apple_HFS Data 620.0 GB disk0s2

3: Apple_HFS Secure 19.7 GB disk0s3

/dev/disk1

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *640.1 GB disk1

1: EFI 209.7 MB disk1s1

2: Apple_HFS Macintosh HD 639.7 GB disk1s2

....

 

I have done the install process three times, step by step. This think gets visible every time.

I would really like to have the EFI boot partition invisible.

Thanks for any advice

 

PS: SL 10.6.4

Chameleon 2 RC4 on EFI

replaced Chameleon boot file with netkas pcefi 10.5 boot file

[srs5694]

I have made a (usually) hidden EFI partition bootable with the "munky" method. Afterwards I have installed Chameleon on this partition.

 

I'm not familiar with the "munky" method to which you refer. It might be helpful if you could post a link to whatever guide you used.

 

But my EFI partition isn't invisible. It gets auto-mounted. Shown in Finder.

 

I figured out that for SL the munky method had to be modified, i.e. to use

$ newfs_hfs -v EFI /dev/diskXsY

 

So I did the same procedure, but this time using newfs_hfs command.

 

Anyway, still visible.

 

At this point, I think some basic information is in order, since I'm afraid you misunderstand some things:

 

Real Macs use the GUID Partition Table (GPT) partitioning system. To older utilities designed for the Master Boot Record (MBR) partitioning system, GPT disks appear to be disks that are entirely filled by a single partition of type 0xEE, which is sometimes identified as "EFI", "EFI GPT", or something similar. Despite this appearance, though, the "EFI partition" seen by MBR tools is not a simple partition; it's just there to keep the older GPT-unaware tools from mucking with the disk. This feature of GPT is known as a protective MBR.

 

Unfortunately, most versions of Windows prior to Vista were completely GPT-unaware, and even Vista and Windows 7 are incapable of booting from GPT disks on BIOS-based computers. For these reasons, Apple resorted to an ugly and dangerous hack known as a hybrid MBR, which alters the protective MBR so that it can carry definitions equivalent to up to three GPT partitions in the MBR. Windows sees the hybrid MBR partitions and treats the disk as if it were a normal MBR disk, but OS X treats the disk like a GPT disk. (Linux also treats hybrid MBR disks as GPT disks.)

 

Its even visible and accessible in Linux and partition type is shown as ef, not ee like other hfs+ partitions.

 

What you're describing here is a misinterpretation of the MBR table. In the MBR scheme, the partition type 0xEE is just a flag that the disk holds GPT data; the partition thus defined isn't a real partition, and it's certainly not a flag that the partition holds HFS+ data. (0xAF is the HFS/HFS+ partition type code.) An MBR partition type code of 0xEF is the code for an EFI System Partition. Thus, if Linux fdisk or other MBR-centric tools are reporting that there's a 0xEF partition, then that means that in MBR-land, there's an EFI System partition on the disk. This has no relevance to how the partition is identified to GPT-centric tools and OSes, including OS X. For that, you need to look at the GPT data structures....

 

diskutil also shows that theres a difference between this EFI (boot) partition, and any another EFI partition of an other disk:

/dev/disk0

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *640.1 GB disk0

1: Apple_HFS EFI 209.7 MB disk0s1

2: Apple_HFS Data 620.0 GB disk0s2

3: Apple_HFS Secure 19.7 GB disk0s3

/dev/disk1

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *640.1 GB disk1

1: EFI 209.7 MB disk1s1

2: Apple_HFS Macintosh HD 639.7 GB disk1s2

....

 

I'm not entirely familiar with the output of diskutil, and I'm not entirely sure which of the two disks has the problem. It's therefore unclear to me how these disks are flagged in terms of their actual type codes, but from your description, my suspicion is that the problem partition has the wrong type code set on the GPT side. You can view and adjust the type codes with my GPT fdisk (gdisk) program. Here's an example on a Linux disk:

 

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 0.6.11

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

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): B322E151-7686-4B94-ACDF-F8F4CC2E9813
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 1-sector boundaries
Total free space is 4670 sectors (2.3 MiB)

Number  Start (sector)	End (sector)  Size	   Code  Name
  1			  34		  390625   190.7 MiB   0700  Unused
  2		  390626		  803249   201.5 MiB   0700  Gentoo /boot
  3		  803250		 1212850   200.0 MiB   0700  Ubuntu /boot
  4		 1212851	   976768064   465.2 GiB   8E00  Linux LVM data (nessus)
  5	   976768065	   976768464   200.0 KiB   EF02  BIOS boot partition

Command (? for help): t
Partition number (1-5): 1
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700): ef00
Changed type of partition to 'EFI System'

Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): B322E151-7686-4B94-ACDF-F8F4CC2E9813
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 1-sector boundaries
Total free space is 4670 sectors (2.3 MiB)

Number  Start (sector)	End (sector)  Size	   Code  Name
  1			  34		  390625   190.7 MiB   EF00  Unused
  2		  390626		  803249   201.5 MiB   0700  Gentoo /boot
  3		  803250		 1212850   200.0 MiB   0700  Ubuntu /boot
  4		 1212851	   976768064   465.2 GiB   8E00  Linux LVM data (nessus)
  5	   976768065	   976768464   200.0 KiB   EF02  BIOS boot partition

 

I changed the type code of the first partition from 0700 (Linux/Windows data) to EF00 (EFI System). (Note the change in the "Code" column of the two partition table listings.) To save the change, use the "w" command, which I omitted here because I didn't want to alter this disk.

 

Before you do this, though, be aware that using HFS+ on an EFI System partition is a Bad Idea (capitalized). I know it's common practice in the Hackintosh community, but that doesn't make it any less unwise. The problem is that this partition is defined in the EFI specifications, and the specs say very explicitly that it must be FAT32. If it's not, there's no telling how some random disk utility you might try in the future will react. I've seen reports of disk utilities that will "fix" an EFI System partition that's not in FAT32 form by initializing the partition to FAT32, without asking for permission. This would obviously be Bad News for anybody who relies on data in that partition.

 

This brings us around to a better solution than changing its type code: If the partition is flagged as being of type AF00 (in gdisk's coding), you can just leave it that way and tell OS X not to mount it. This can be done by creating an /etc/fstab entry like this one:

 

/dev/disk0s1 none hfs+ ro,noatuo 0 0

 

Change the device code, if necessary, for your disk. If you want to have the option of accessing the disk, you can change "none" to some convenient empty directory; then you'll be able to issue a text-mode mount command to mount the partition.

 

On a Hackintosh, the lack of an EFI System partition won't cause any real problems -- if I'm right, you're already running that way.

[dino7777]

Wow,

 

that was detailed! Thanks for your effort. Now I have learned some useful info.

I have managet to get the partition not auto mounted by, as you said adding the /etc/fstab.

 

I thought of this solution before, but my SL did not contain a fstab file. Just /etc/fstab.hd. I edited it before, but it had no effect. No that I know that SL reads fstab, I could easily fit the auto mount problem.

 

Heres my /etc/fstab

LABEL=WinBoot /Volumes/WinBootn ntfs noauto,ro 0 0

LABEL=EFI /Volumes/EFI hfs noauto,ro 0 0

 

where WinBoot is an partition that Win7x64 created and that contains only the boot files for Windows.

 

Special thanks for the hint with gdisk. I have installed the OSX version and it will sure be part of my next system recovery dvd.

gdisk says that my EFI boot partition (disk0s1 in post#1) is AF00, but I mistakenly typed hfs in fstab, and it works.

I also tried to use UUID rather than LABELs, but somehow does not work, as usually my boot partition (disk) is an other one.

 

Regarding the discussion, how wise it is to use EFI as a boot partition.

I my case it is for disaster recovery. So I have my bootloader redundant on my system. Just in case.

(Thats why I tried to use UUID rather than LABELs, and why I did not mark partitions by device names)

 

Again, thanks for your really detailed and well explained post.

I really love to be a member of this forum.

 

Cheers

[Gringo Vermelho]

Thanks for your effort. Now I have learned some useful info.

+1

 

Nice post (as usual I might add), thanks for laying down the law on these things.

I'm not familiar with the "munky" method to which you refer. It might be helpful if you could post a link to whatever guide you used.

Here: http://www.insanelymac.com/forum/index.php?showtopic=127330

 

The EFI partition loses its magic if you're on Snow Leopard and initialize it like this:

diskutil eraseVolume "HFS+" "EFI" /dev/diskXs1

That only works on 10.5.x. On Snow Leopard you should do this:

newfs_hfs -v EFI /dev/diskXs1 instead.

 

When I made this mistake myself, the only way I could get the EFI partition back to being invisible was formatting the whole drive again.

 

Of course initializing it as HFS+ goes against the advice of srs5694 above. But yes that's what everybody does and so far I haven't heard of any HFS+ EFI partitions that disappeared from using a disk tool. But yes, it will probably happen to someone sooner or later.