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
