Re: [PATCH] fix /boot/loader for extended slices

[walt <wa1ter@xxxxxxxxxxxxx>]

Matthew Dillon wrote:

>     So what we need is some serious testing, e.g. like creating multiple
>     extended dos partitions two recursions deep and seeing if the partition
>     data is properly passed between the loader and kernel.

First, your patch works just fine for me.

Now, some comments on how the DOS extended partitions work, which I can
only infer from how the various fdisk programs work.

I have only three fdisk programs which allow for extended partitions:
the ones from linux and NetBSD, and also the commercial Windows app
from Acronis  -- well, and the MS versions of fdisk too, of course.

They all behave the same when dealing with extended partitions -- that
is, they create the *primary* extended partition entry automatically
if there isn't one already.  If there is an extended partition already
then it sticks your new logical drive at the end of the existing chain
of extended partitions.  You never get the chance to create a second
*primary* extended slice.

In other words, there will always be only one slice of type 05 among
the four primary partitions because there is no way to create a second
one.  I even tried editing an existing partition to make it a type 05
and got an error message.  Verboten!

Second comment:   I restricted the reading of each chained XPT to the
first two entries in the table because (on my machines) the last two
entries are always zeros.  The first entry is the pointer to the
partition you really want (e.g. type a5 for DFLY) and the second
entry in the table is the pointer to the next XPT (i.e. always type
05.)  There didn't seem to be any point in reading the last two.

Doesn't matter -- your patch, as I said works fine.  Thanks!