Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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:
>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
>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?


Home | Main Index | Thread Index | Old Index