NetBSD 6.0Beta and 6.0Beta2 on hpcarm doesn't create a fdisk partition during install

[jmitchel%bigjar.com@localhost]

Hello,

I've noticed a slight issue with 6.0BETA and 6.0BETA2. After doing an
install on a new CF card, here's what we get:

--------------
fdisk /dev/wd0
--------------

Disk: /dev/wd0d
NetBSD disklabel disk geometry:
cylinders: 8150, heads: 16, sectors/track: 63 (1008 sectors/cylinder)
total sectors: 8215200

BIOS disk geometry:
cylinders: 512, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 8215200

Partitions aligned to 16065 sector boundaries, offset 63

Partition table:
0: Primary 'big' DOS, 16-bit FAT (> 32MB) (sysid 6)
    start 8192, size 80325 (39 MB, Cyls 0/130/3-5/130/2), Active
1: <UNUSED>
2: <UNUSED>
3: <UNUSED>
First active partition: 0
-----------------

The surprising part is that NetBSD 6.0 BETA & BETA2 can run on this flash
card. Part of that is because hpcarm uses Windows CE to load the NetBSD
kernel. But there is a disklabel somewhere. Here's what disklabel says:

------------------
disklabel /dev/wd0
------------------

# /dev/wd0d:
type: unknown
disk: TRANSCEND
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 8150
total sectors: 8215200
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   7863408     88517     4.2BSD   2048 16384     0  # (Cyl.     87*-  
7888*)
 b:    263275   7951925       swap                     # (Cyl.   7888*-  
8149)
 c:   8126683     88517     unused      0     0        # (Cyl.     87*-  
8149)
 d:   8215200         0     unused      0     0        # (Cyl.      0 -  
8149)
 e:     80325      8192      MSDOS                     # (Cyl.      8*-   
 87*)
---------------------

And here's what mount says:

------------
mount
------------

/dev/wd0a on / type ffs (log, local)
kernfs on /kern type kernfs (local)
ptyfs on /dev/pts type ptyfs (local)
procfs on /proc type procfs (local)

------------

Does this surprise anyone else? Any ideas where that disklabel lives? The
disklabel isn't accessible when I boot 5.1.2 off another CF and try to
access it from the 5.1.2 system.

Should I file a PR for this? I've tested it on 6.0BETA and 6.0BETA2 and
the behavior is the same on both. Also, if there's other information I
could collect, let me know so I can gather it.

Jason M.