>On 18 Apr 96 at 11:19, Phil Knaack wrote about "Re: booting off
>of second partition".

>> 	I have OS-BS 2.0 beta 8 on my IDE disk with Windows 95. It
>> works just fine, the only problem I do have is that I can't
>> get a disklabel on the drive to mount it from netbsd. (netbsd
>> is entirely on SCSI.) One of the following two things happens,
>> I'm not sure which:
 
>> 	1) bsd disklabel collides with osbs2.0
>> 	2) bsd disklabel collides with win95 stuff
 
>I have the same setup and I can access both of my Win95
>partitions from NetBSD.  I did have trouble at first when I
>tried to access one of the partitions.  When setting up the
>disklabel, it turned out that I needed to increase the offset by
>63 sectors (which happens to be one track on my disk), and also
>decrease the partition size by same.  

>> 	In any case, I've got a "spare" machine here that has an
>> "empty" hard drive, and I'm going to be tackling the above
>> problem tonight to see if I can get win95 and netbsd to share
>> my disk.
 
	Okay, I discovered what the problem was. I went around with this
for some time. I finally managed to get my 500M Fujitsu split half-n-half
with win95 and netbsd, booting either with osbs20beta8, and able to mount
the win95 partition from netbsd.

	To lay some background:

	The i386 port has two different places it looks for a disklabel on
the disk: if no NetBSD/386BSD partitions are listed on the DOS partition table
(tag 0xA5) then it expects the disklabel to be located on the second sector
of the disk (the sector after the dos partition table).

	If an A5 partition _does_ exist, it expects to find the disklabel on
the second sector *of that partition*.

	This is part of the problem. For some reason, even though I had a
valid 0xA5 partition created, the "disklabel" program was WRITING the label
I created to the second sector of the DISK, not of that PARTITION.

	I determined this by inserting printf's into "disklabel.c" that
displayed the actual offsets into the disk used when actually reading or
writing. 

	When I did "disklabel wd0" it told me it was attempting to read from
offset 105283584 (205632 * 512), which was correct. It was also not finding
the magic number or a label.

	When I did "disklabel -r -R wd0 wd0.label" just a moment later it
told me it was writing to offset 512, and there went OSBS. (As an aside, for
those tempted to ask, I did this several times with different "c" partitions
specified. I left it out, I specified it as the whole disk (copy of "d"), and
I specified it as the same as the dos-partition-table-0xA5 partition. Same
results, always writes to offset 512.)

	OSBS2.0beta8 differs from the previous version in one important way:
it actually uses the second sector on the disk for part of its boot code. The
older version fit in the first sector. Thus, my disklabel would nuke OSBS.
Also, the boot blocks would never find a disklabel it liked.

	Finally, in order to make it work, I just used "dd" to cut+paste 
together:

	(1) /usr/mdec/wdboot
	(2) the contents of the second sector of the disk after running
	    disklabel
	(3) /usr/mdec/bootwd minus the first 512 bytes

	and then manually wrote this binary file to the proper offset on
the disk. It has worked like a charm. I've still not figured out what was
up with disklabel.

	If someone can point out something that I've done really stupid, 
please tell me. Or, if someone is aware of a bug in disklabel.c's calcu-
lation of the destination offset, please tell me .. otherwise I'm going to
keep poking about and learning more about the internals.

Cheers,
Phil
--
Phillip F Knaack               flipk@iastate.edu
Database Programmer, NCREMP    Student Development Group
ISU Extension                  Project Vincent, Iowa State University