Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!gatech!pitt.edu!drycas.club.cc.cmu.edu!ghod From: ghod@drycas.club.cc.cmu.edu Newsgroups: comp.unix.bsd Subject: [386bsd] strange solutions revisited Message-ID: <1992Sep20.185358.2092@drycas.club.cc.cmu.edu> Date: 20 Sep 92 23:53:58 GMT Organization: Carnegie Mellon Computer Club Lines: 65 Greetings again... This is directed to Lynne Jolitz, who responded to my first post. It seems there's another way I can get the dist.fs floppy to boot that doesn't involve the 'bait and switch' trick I described previously. I discovered that if I press a key on the keyboard (any key) while the system boots, the bootstrap code doesn't hang. Also, the problem persists even now that I installed the binaries on my hard disk: what happens is that the boostrap code is read from the hard disk, then the floppy drive light comes on and the system locks up again. Both the 'bait and switch' and holding down a key on the keyboard will permit me to boot from the hard disk properly. Obviously, there must be something funny going on with my disk controller, however my controller circuit appears to be part of the motherboard so I'm afraid there's not much I can tell you about it. Also, I didn't *really* get the binaries installed: apparently my 40 meg disk just isn't big enough to hold both the cpio distribution files *and* the installed file system. There are two things about this situation that I'd like to discuss. First, the install program claims that I have 37.4 Mbytes available on 716 cylinders (6 heads, 17 sectors per track). However, I know for a fact that my Seagate 351A/X has 820 cylinders, not 716. What I want to know is: is the difference being used for swap space, or is this an error in the install program? Second, here's a suggestion for the next release: rewrite the extract program so that it deletes the cpio distribution files 'on the fly', meaning for instance that once all the files from bin01.00 have been extracted, delete bin01.00. Once the files from bin01.01 have been extracted, delete bin01.01 etc. This would allow the space used by the distribution files to be freed and allow people with smaller drives to properly complete the installation. In my case, the file system filled up after getting about two thirds of the way through. I tried to remove the files on the fly myself, using /bin/csh and ^Z to suspend extract and then remove files it had already extracted. This didn't work, however, as it seems the system won't notice that these files are gone until *after* the extract process exits. I also found that because of the way the distribution is set up, you can't extract it by hand. I suppose I could write my own extract program, but I'd have to get the system installed first. Catch 22. One kludge I haven't tried yet is to suspend extract, and then compress some of the already installed files in order to make more room. I may try this before I give up for the night. Here's an even better idea: how about an extract program that can read the distribution files right off the floppies. Granted this would make checking their integrity a real pain, but this would solve the disk space problem and cut out one step from the installation procedure. Anyway, despite the problems I've been having with my particular setup, I'm still very impressed with what I've seen of 386BSD so far. The hanging boot problem makes it neccessary for an operator to be around whenever the system reboots, but I consider this a minor inconvenience so long as I can get the thing up and running reliably. I'll probably end up blowing my next pay check on a 100 meg drive: this is too good to pass up. Bravo Bill & Lynne. --Bill Paul Assitant System Administrator New Windsor Associates L.P. ghod@drycas.club.cc.cmu.edu -or- ghod@drycas.bitnet