disklabel MAXPARTITIONS reversal (was: installboot is broken)

[Martin Husemann <martin%duskware.de@localhost>]

Oha, this is a bit trickier...

while fixing installboot was simple and the simh 780 boots fine
(after fixing an unrelated mscpbus bug), I now hit a wall and would
like to see some more input:

I found that the bump of MAXPARTITIONS from 8 to 16:

http://mail-index.netbsd.org/source-changes/2012/07/02/msg035340.html
---8<--
Module Name:    src
Committed By:   abs
Date:           Mon Jul  2 22:42:18 UTC 2012

Modified Files:
        src/distrib/vax/miniroot: Makefile.inc
        src/sys/arch/vax/include: disklabel.h types.h
        src/sys/sys: bootblock.h

Log Message:
- Increase MAXPARTITIONS for vax from 8 to 16, using the standard NetBSD
  mechanism to ensure all existing /dev nodes continue to work
- Adjust boot block layout to fit additional partitions
- Adjust number of inodes on install media

--->8---

missed the necessary changes in /boot/xxboot/start.S, so now d_end_ still
reflects the old disklabel size, but fixing it is impossible, as we end
up with 468 (0x1d4) as first byte past the disklabel.

However, at 0x19e we need to fill in the parameter block for uVAX boot:
.org    0x19e
        .byte   0x18            # must be 0x18 
        .byte   0x00            # must be 0x00 (MBZ) 
        .byte   0x00            # any value 
        .byte   0xFF - (0x18 + 0x00 + 0x00)     
                /* 4th byte holds 1s' complement of sum of previous 3 bytes */
...


So, unless there are any tricks I don't see right now, I would suggest to

 - revert the above mentioned commit
 - document the incompatiblity (affecting all new installs done after that
   commit in -current or in netbsd-6)

and be done. Unfortunate, but probably not a lot installations affected, and
I'll make sure disklabel(8) will properly deal with the situation (if it
doesn't already), so existing (and working) install have an easy way of
fixing (unless they actually already use more than 8 partitions).

Any better options?

Martin