[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
> src/distrib/vax/miniroot: Makefile.inc
> src/sys/arch/vax/include: disklabel.h types.h
> src/sys/sys: bootblock.h
>- 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:
> .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?
Main Index |
Thread Index |