I just got done dealing with trying to setup an MBR style label on my cube's
drive so I could boot directly from the prom.

I was planning on 2 partitions: 1 NetBSD, 1 MSDOS.

i.e. just dump ofwboot* in the msdos one and then

boot hd:,ofwboot.elf ultra0:0,/netbsd

works like a charm (in the end).

Here's the problem:

Boot off the network to start with. (from a -current image)

Use fdisk to lay down a partition table.
Make sure and mark the msdos partition as the active one
Use disklabel  -e -I to setup an initial label.

*boom* (so to speak)

Here's the problem...disklabel -I opens the raw device and seeks to the right
location based on getlabelsector() and getlabeloffset().

Well, those return 0, 64 on macppc which is the values in use for a whole disk
install.

Come to find out there are "special" values in the code today for MBR disks
which think it's at 1,0 (ala x86). This literally is like 5 lines of 
extra code...

This is just broken...There is no need to move the values to something 
different for MBR disks and nothing in disklabel or any other ports have 
multiple values they'll report/use for getlabel* calls. The only possible 
reason would be to be able to disklabel the drive from x86 and then move it
over, but considering you can't do that for whole disks, why sould this be
different and incompatible?

The fix for me was simply to remove the special MBR ones, and use the proper
0,64 offsets and everything was happy about reading and updating the labels
for both whole disk and inside an MBR partition.

Now, before fixing this long term (the idea you can't disklabel/fdisk a drive
from scratch natively is pretty silly) I figure adding a COMPAT option 
for macppc which does fallback is probably the right thing. That way anyone 
who forced disklabel to write the initial label at 1,0 (or more than likely 
init'd their drive on an x86 box and then moved it over) won't immediately 
lose.

Thoughts?

James

(BTW: did some tests and back porting the MBR support to 1.6 is fairly simple)