Re: disklabel MAXPARTITIONS reversal (was: installboot is broken)

[christos%astron.com@localhost (Christos Zoulas)]

In article <20130329092457.GA8841%mail.duskware.de@localhost>,
Martin Husemann  <martin%duskware.de@localhost> wrote:
>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?

Bump it up to the maximum allowed?

christos