I can confirm the following points: * the code in the kernel works "correctly" in that it can successfully mount and access deeply nested non-OpenBSD extended partitions; * the code in the base fdisk(8) utility works correctly as I have used it numerous times to fix disk partitioning on Windows and Linux boxes with sometimes over a dozen extended partitions; * in OBSD 4.4 and 4.5 I have done a test installation to every possible MBR and extended partition on a disk carved into about a dozen "slices" and was only successful with the MBR partitions and the very first two extended partitions;
* the published documentation I was ever able to find describing the extended partitions in the "IBM PC" architecture is consistent with the implementation present in the installboot(8) utility, HOWEVER, * my examination of the actual data in the partition description sectors of numerous boxes partitioned with Windows or Linux has found it to be instead consistent with the description provided below by OP. On 11 Feb 2011 at 14:48, Kenneth R Westerback wrote: > On Fri, Feb 11, 2011 at 05:11:45PM +0200, ucs...@gmail.com wrote: > > On Fri, Feb 11, 2011 at 06:28:28AM -0500, Kenneth R Westerback > wrote: > > > On Fri, Feb 11, 2011 at 09:47:02AM +0200, ucs...@gmail.com > wrote: > > > > Despite the touted support, OpenBSD wouldn't be able to boot off > an > > > > extended partition, unless it's the very first or second one. > > > > > > > > The kernel was fixed (after a fashion) some time ago, but > boot(8) and > > > > installboot(8) still live under the mistaken idea that extended > partitions > > > > are defined recursively, with each of them acting like a full > MBR again > > > > and again, each with 4 smaller partitions inside it, and the > offset of > > > > each subsequent extended partition should be calculated wrt. the > offset > > > > of the bigger one containing it. > > > > > > > > That doesn't work that way and never worked that way: There is > one big > > > > extended partition defined in the MBR, and then inside it there > is a > > > > linked list of 'logical' partitions, each of them with a fake > MBR > > > > defining a data sub-partition (whose offset is from the start of > this > > > > logical partition), and possibly a link to the next logical > partition > > > > (whose offset is from the start of the main extended > partition). > > > > > > > > > > Can you provide some pointers to where you are deriving this > > > information and what testing you have done and what setups now > work > > > that did not before? You hint in your description, but this is > an > > > area that has been argued over many times with each fix breaking > > > some systems while fixing others. The last test rig I set up had > > > > I don't see your point. > > My point was attempting to discover if you had discovered some clear > docs on how this is "supposed" to work. Hope springs eternal. Also > to discover what testing you had done to demonstrate that this fixes > a problem without causing other side effects. If you had done such > testing I would have to do less myself. > > Did you encounter a problem? What was it? Would other people care? > How did you encounter it? Did you just read code and type up the > diff (which looks good) on your Mac and hope it compiled/worked on > OpenBSD? > > > > > The kernel is already doing it the way I describe, though the code > > is a bit clunky and stupidly limited to 8 extended partitions. > > (that's the stuff in kern/subr_disk.c). > > Thanks for the moral support. The limit of 8 was one of those things > that > having a nice definitive doc would help with. > > > > > Are you arguing for keeping boot(8) and installboot(8) doing a > different > > thing from the kernel? > > No, I'm attempting to discover what work you had done that would not > have > to be repeated before considering committing. > > > > > It's easy to reproduce -- I could prepare you a qemu image with all > things > > set up and the 3rd or 4th extended partition of type 0xa6, but you > don't > > need such hand-holding. You can do that yourself ;-) > > > > > Having working extended partitions would be nice, but finally > finding > > > definitive docs that clearly and correctly describe what is > supposed > > > to happen would be even better. > > > > There are no such docs. What I describe in the 2nd paragraph is the > way > > windows (and linux, and probably others) work. > > And you know windows works this way because .... docs? testing? > reverse compiling windows (which ones?) code? web site? > > .... Ken > > ------------------------------------------------------------------ Jacob L. Leifman email: jac...@bitwise.net Bitwise Internet Technologies, Inc. tel: (617) 737-1837 x11 22 Drydock Avenue, Suite 310 cell: (617) 512-1024 Boston, MA 02210 fax: (617) 439-4941 ------------------------------------------------------------------
