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

[Hiten Pandya <hmp@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!
>
>     Ok.  I'll add some additional comments and then commit my modified patch.
>     It's unclear what the official specification allows but the patched
>     scanning code does check for zero'd entries and should handle those
>     cases, and it does match what the kernel does.
>
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

	http://howtos.linux.com/howtos/Large-Disk-HOWTO-13.shtml

		-Hiten