Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!apple!oliveb!mipos3!omepd!iwarpj!pcm
From: pcm@iwarpj.intel.com (Phil C. Miller)
Newsgroups: comp.os.minix
Subject: Re: mkfs bombing out
Message-ID: <4621@omepd.UUCP>
Date: 8 Jul 89 12:56:57 GMT
References: <1695@netcom.UUCP>
Sender: news@omepd.UUCP
Reply-To: pcm@iwarpj.UUCP (Phil C. Miller)
Organization: Intel Corp., Hillsboro
Lines: 57

In article <1695@netcom.UUCP> hinton@netcom.UUCP (Greg Hinton) writes:

>I've been re-installing minix 1.2 after a recent hard-disk crash & decided to
>change the partitions around some.  Previously, minix was on the first
>partition & DOS was on the second; now I'd like DOS on the first & minix
>split between the second & third.  However, I've run across a problem with
>mkfs: on partitions 2 - 4 (/dev/hd[2-4]), mkfs crashes if the file system size
>is greater than about 7200 with the message:
>	Error: put_block couldn't write
>	Line 1 being processed when error detected.


>Mkfs works just fine, however, on the first partition (/dev/hd1) with any
>file system size.  Anyboby know what's going on here?  Is this a bug or am
>I just being exceptionally dense?



	I have run across this problem a lot when using proto.*.  I have
	also run across the problem when trying to make BIG file systems,
	but I have been able to successfully build & use a file system on
	/dev/hd2 which is about 8192 blocks.

	I will venture a guess (and clearly disclaim it as such) that the
	physical locations of the latter portions of a large second
	partition have some large number associated with them that is beyond
	some magic value in the file system code.  My DOS boot partition
	(which would be /dev/hd1 if it were used by MINIX) is about 10Mb;
	if I'm right, yours is probably larger by a Meg or so.

	If I'm even halfway close to the mark here, the third partition
	will probably behave even worse than the second.



>Also, even when mkfs returns without error, fsck doesn't like the file
>system produced.  It fails with the error:
>	bad magic number in super block

>Help!

	I can DEFINITELY help you with this one.  Chances are that your disk
	has some number of heads other than the default, 4.  Simply change
	the number of heads and recompile the fsck.  Can't remember which
	file you have to change right off the top of my head, but I do
	remember that it's one of the .h files used in fsck.


	After you run mkfs and before you run fsck, you'll probably need to
	run the badblocks stuff (diskcheck and badblocks); at least I did.
	Fsck got stuck trying to read a bad block and croaked on my system.

>Greg Hinton


Phil Miller
pcm@ogccse or {...}!tektronix!ogccse!pcm