Newsgroups: comp.os.minix
Path: utzoo!utgpu!cunews!hobbit.gandalf.ca!dperks
From: dperks@hobbit.gandalf.ca (Dave Perks)
Subject: Re: DOS and Minix partitions
Message-ID: <1991May7.215955.7949@hobbit.gandalf.ca>
Organization: Gandalf Data Ltd.
References: <1193@opus.NMSU.Edu>
Distribution: all
Date: Tue, 7 May 1991 21:59:55 GMT
Lines: 28

In <1193@opus.NMSU.Edu> kduling@nmsu.edu (Kevin Duling) writes:

>   I'm having some rather serious problems between my Minix and DOS partitions.
>   ... I've got a 32 Meg Seagate 138R harddrive which fdisk reports to have 939 
>cylinders and 17 sectors.  I set part. 1 to 10M (10641k) and set that to Minix.
>That's cylinders 0 through 312, btw.  Then I set part. 2 to 313 through 938
>and made that my DOS partition.  I set it active, and wrote it.
>   Ok...next I spent 4+ hours installing and testing Minix...
>   When I booted Minix next time, the whole fs was destroyed.  fdisk still 
>reported that I had my partitions, and DOS ran just fine...but Minix was
>trashed.

    I had the same problem, with DR-DOS 5.0. For some reason it masks off the
high order bit of the partition type field, so the Minix type 0x81 looks
like 0x01 -- a normal MS-DOS partition. DR-DOS uses all DOS-type partitions on
all hard drives, so the first partition (Minix!) was C: and the second (DOS)
was D:.

    To work around, I gave Minix the end of the disk instead of the beginning
and everything worked okay, except that I had to be careful not to mess up the
bogus D: partition from the DR-DOS.

    I finally worked up a patch to the BIOS portion of DR-DOS (IBMBIO.COM or
IO.SYS -- I can't remember which *-DOS uses which name) that deletes the masking
of the high order bit. It's at home and I'm not, and I wouldn't really want to
distribute it anyway in case it has previously unrevealed side effects ;-O

--dave perks, dperks@boromir.gandalf.ca