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