Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!ll-xn!mit-eddie!husc6!bloom-beacon!gatech!udel!princeton!allegra!ulysses!sfmag!sfsup!mpl
From: mpl@sfsup.UUCP
Newsgroups: comp.os.minix
Subject: the continuing saga of getting minix up
Message-ID: <1603@sfsup.UUCP>
Date: Wed, 8-Jul-87 09:54:28 EDT
Article-I.D.: sfsup.1603
Posted: Wed Jul  8 09:54:28 1987
Date-Received: Sat, 11-Jul-87 16:02:55 EDT
Organization: AT&T-IS, Summit N.J. USA
Lines: 38

Well, I managed to change the size of the ram disk last night.  If anyone
has a similar problem, here's what I did.  If you read my last posting, you
know that I built a file system using proto.ram with the size changed to 280
and it wouldn't boot.  Last night I looked into the problem.  "F1" showed
everything to be normal, with a shell running (accumulating time) with a pid
of 4.  This indicated that /etc/rc wasn't being run for some reason.  I
rebooted, mounted the new root as /usr, and started examining.  ALL the files
and directories were the same size, had the same contents, and the same
i-numbers, but the thing still wouldn't work.  Fsck was happy with it, as well.

I "od"d the two file sytems, and discovered the superblocks were the only
differences.  So, I did the following (which made it work):

	cat /dev/ram > /dev/fd0
	# to get a working 240 block ram disk

I then wrote a program:

main()
{
	int	fd = open("/dev/fd0", 2);
	int	i = 280;

	lseek(fd, 02002L, 0);
	write(fd, &i, 2);
	close(fd);
}

which changed the size of the filesystem in the superblock.
I then used fsck to patch up the block map for the extra 40
blocks I added.  The result?  A working ram disk of 280 blocks!

Tonight's task: find out what was initially wrong with the
superblock that kept it from working before, and if I have time,
recompile the kernel with the hard disk fixes using my patented ;{)
single-floppy method of compilation.

Mike Lindner