hinton@netcom.UUCP (Greg Hinton) (07/07/89)
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? 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! Greg Hinton INET: hinton@netcom.uucp UUCP: ...!uunet!apple!netcom!hinton "I've never let school get in the way of my education."
pcm@iwarpj.intel.com (Phil C. Miller) (07/08/89)
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
hinton@netcom.UUCP (Greg Hinton) (07/09/89)
In article <1695@netcom.UUCP> I write: > .... >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. > .... It's the little things that can drive you bonkers! I assumed that since at_wini.c used an intelligent method of determining the number of heads & sectors on a disk, that utilities like mkfs & fsck would do the same. I forgot that these programs must run on non-AT machines & therefore have those values hard-coded into them. Once I changed that, everything ran smoothly. The first partition wasn't affected earlier because the sector offset into it is always zero. But the second partition was actually overlapped with the first. I'm lucky I didn't wipe out any DOS stuff! Are these the only two files that hard-code disk parameters, or are there other gotcha's lurking out there? Also, does anyone have a list of which commands require the -i (separate I/D) switch when compiled? If so, please post. Thanks. Greg Hinton INET: hinton@netcom.uucp UUCP: ...!uunet!apple!netcom!hinton "I've never let school get in the way of my education."
evans@ditsyda.oz (Bruce Evans) (07/14/89)
In article <1709@netcom.UUCP> hinton@netcom.UUCP (Greg Hinton) writes: >Also, does anyone have a list of which commands require the -i (separate >I/D) switch when compiled? If so, please post. The list is best obtained with ls *.c :-). Using -i costs at most 15 bytes and results in a more robust runtime environment. -- Bruce Evans evans@ditsyda.oz.au