TO ADDRESS YOUR EDIT:
I didn't notice the edit to your question until just now. As written now, the question is altogether different than when I first answered it. The mirror you describe is not in the spec, actually, as it is instead a rather dangerous and ugly hack known as a hybrid-MBR partition format. This question makes a lot more sense now - it's not silly at all, in fact.
The primary difference between a GPT disk and a hybrid MBR disk is that a GPT's MBR will describe the entire disk as a single MBR partition, while a hybrid MBR will attempt to hedge for (extremely ugly) compatibility's sake and describe only the area covered by the first four partitions. The problem with that situation is the hybrid-MBR's attempts at compatibility completely defeat the purpose of GPT's Protective MBR in the first place.
As noted below, the Protective MBR is supposed to protect a GPT-disk from stupid applications, but if some of the disk appears to be unallocated to those, all bets are off. Don't use a hybrid-MBR if it can be at all helped - which, if on a Mac, means don't use the default
In general, if looking for advice on EFI/GPT-related matters go nowhere else (excepting maybe a slight detour here first) but to rodsbooks.com.
This (used to be) kind of a silly question - I think you're asking how to partition a GPT disk without a Protective MBR. The answer to that question is you cannot - because the GPT is a disk partition table format standard, and that standard specifies a protective MBR positioned at the head of the disk. See?
What you can do is erase the MBR or overwrite it - it won't prevent most GPT-aware applications from accessing the partition data anyway, but the reason it is included in the specification is to prevent non-GPT-aware applications from screwing with the partition-table. It prevents this by just reporting that the entire disk is a single MBR-type partition already, and nobody should try writing a filesystem to it because it is already allocated space. Removing the MBR removes that protection.
In any case, here's how:
This creates a 4G
./img file full of NULs...
</dev/zero >./img \
dd ibs=4k obs=4kx1k count=1kx1k
1048576+0 records in
1024+0 records out
4294967296 bytes (4.3 GB) copied, 3.38218 s, 1.3 GB/s
This writes a partition table to it - to include the leading Protective MBR.
- Each of
printf's arguments is followed by a
\newline and written to
gdisk interprets the commands as though they were typed at it interactively and acts accordingly, to create two GPT partition entries in the GUID Partition Table it writes to the head of our
All terminal output is dumped to
>/dev/null (because it's a lot and we'll be having a look at the results presently anyway).
printf %s\\n o y n 1 '' +750M ef00 \
n 2 '' '' '' '' \
w y | >/dev/null \
pr's four-columned formatted representation of the offset-accompanied
strings in the first 2K of
<./img dd count=4 |
strings -1 -td |
pr -w100 -t4
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 7.1933e-05 s, 28.5 MB/s
451 * 1033 K 1094 t 1212 n
510 U 1037 > 1096 e 1214 u
512 EFI PART 1039 ;@fY 1098 m 1216 x
524 \ 1044 30 1153 = 1218
529 P 1047 L 1158 rG 1220 f
531 ( 1050 E 1161 y=i 1222 i
552 " 1065 w 1165 G} 1224 l
568 V 1080 E 1170 $U.b 1226 e
573 G 1082 F 1175 N 1228 s
575 G 1084 I 1178 C 1230 y
577 y 1086 1180 b 1232 s
583 G 1088 S 1185 x 1234 t
602 Ml 1090 y 1208 L 1236 e
1024 (s* 1092 s 1210 i 1238 m
You can see where the MBR ends there, yeah? Byte 512.
And now for the fruits of our labor.
This is an interactive run of
GPT fdisk (gdisk) version 1.0.0
Partition table scan:
MBR: not present
BSD: not present
APM: not present
Found valid GPT with corrupt MBR; using GPT and will write new
protective MBR on save.
Command (? for help): p
Disk ./img: 8388608 sectors, 4.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 0528394A-9A2C-423B-9FDE-592CB74B17B3
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 8388574
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1538047 750.0 MiB EF00 EFI System
2 1538048 8388574 3.3 GiB 8300 Linux filesystem