OpenSolaris

On a bootcamp prepared disk, fdisk -F has a hard time:

d-mpk17-227-166:~# fdisk -W /tmp/1280 /dev/rdsk/c1d1p0
d-mpk17-227-166:~# fdisk -F /tmp/1280 /dev/rdsk/c1d1p0
ERROR: EFI_PMBR partition must encompass the entire disk.
 numsect 409639 - actual 488392064
fdisk: Cannot create partition table
d-mpk17-227-166:~# grep -v ^\* /tmp/1280


  238   0    254    63     1023    254    63     1023    1        409639  
  175   0    254    63     1023    254    63     1023    409640   381681664
  191   128  254    63     1023    254    63     1023    382091304 102558960
d-mpk17-227-166:~# 

 Sadly this kills install as it insists on re-writing the fdisk table 
even when a Solaris2 partition already exists (that's a separate bug).

Warning: There have been some cases of catastrophic data loss (wiped 
disk, both OS X and Solaris rendered unbootable) associated with this 
procedure. Both Sun and Apple are investigating that issue. This is 
hindered by the fact that it does not appear to be entirely 
deterministic. If anyone can provide steps to reliably reproduce this, 
please communicate them by submitting a bug under utility/fdisk. 
 
 Workaround: 
 
 Since the problem arises when then entire table is re-written, one 
can re-layout the Solaris2 partition (partition id 191) using the 
interactive fdisk(1M). 
 
 Then (and this part is strictly speaking a workaround for 6413240) 
wrap fdisk to not do anything for a commit (-F) operation: 

/# mount -o remount,rw /
/# cd /sbin/
/sbin# mv fdisk fdisk.real
/sbin# cat > fdisk
#!/bin/sh

echo "$*" | grep -- "-F" > /dev/null
if [ $? = 1 ] ; then
        /sbin/fdisk.real $*
fi
/sbin# chmod +x fdisk
/sbin#

 Then an interactive install to that partition can be performed.
Please be advised that using this workaround, if there are any GPT headers on
the disk, they will be cleared.

N/A