[comp.os.minix] fixing fsck for hard disks

subelman@ttidca.UUCP (05/05/87)

I finally got MINIX to work on my XT-2000 clone with a Seagate ST225 and a
WD1002S-WX2 controller. The main problems were with a read-only disk, cured by
Don Dugger's (n0ano@wldrdg) patch (thanks, Don), and with an fsck that refused
to work at all.
The problem with fsck is that it uses the BIOS for its I/O. The BIOS in the
controller uses part of the first 1K of RAM as a scratch pad. This same area
is used for the stack of the MINIX bootblock. Thus MINIX and the BIOS step on
each others toes. The cure is easy: move the bootblock's stack to high memory.
In file /user/tools/bootblok.s make the following change:

lines  62-63 were:
	mov	ss,ax		|set ss to 0
	mov	sp,#1024	|initialize sp (top of vector table)
and should be changed to
	mov	ss,dx		|set ss to our cs
	mov	sp,#1536	|set stack 1K above bootblock

(This is the bootblok.s file used when MINIX is the development environment).
After this change, recompile bootblok using the makefile and rebuild the boot
diskette.

There are two caveats:
1) if you hit CTRL-ALT-DEL while in MINIX, it brings up the bootstrap menu.
   However, the BIOS tables have been wiped out by the kernel, so fsck won't
   work again. Hit CTRL-ALT-DEL a second time in the menu. This forces the
   BIOS to reset itself, and a fresh menu to be brought up. Fsck will then
   work.

2) If you strapped the controller for its autoconfig option (I didn't) then
   the controller builds a table in RAM, in this same area. While fsck will
   still work with my patch, the kernel will not be able to read this table
   and the device driver will not work. Richard Todd (rmtodd@uokmax) first
   discussed how to solve this one.

-- 
Ed Subelman		{csun|philabs|psivax|trwrb}!ttidca!subelman
Citicorp(+)TTI		(213) 450-9111, x2972
3100 Ocean Park Blvd.,	Santa Monica, CA  90405