Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!agate!soda.berkeley.edu!wjolitz From: wjolitz@soda.berkeley.edu (William F. Jolitz) Newsgroups: comp.unix.bsd Subject: Re: [386bsd] strange solutions revisited Date: 22 Sep 1992 17:21:17 GMT Organization: U.C. Berkeley, CS Undergraduate Association Lines: 96 Message-ID: <19nkmdINNkmf@agate.berkeley.edu> References: <1992Sep20.185358.2092@drycas.club.cc.cmu.edu> NNTP-Posting-Host: soda.berkeley.edu In article <1992Sep20.185358.2092@drycas.club.cc.cmu.edu> ghod@drycas.club.cc.cmu.edu writes: >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. You seem to be interfering with the way in which the keyboard reset works. We've had this trouble on some high-end PCs lately (last week). It would seem that the problem in some cases can be eliminated by removing the keyboard reset code in the bootstrap and system (the only reason it's there and in both places is because some older PCs compulsively disable the keyboard on bootup and if this was not present, you would have the same effect on the older systems -- a toggle condition). There's a lot of work ongoing in this area, but nothing settled yet, as one must achieve work which all PCs agree upon. Another item which makes this area more subtle is that there is an interaction with the floppy which differs from that of the hard disk. >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. I tested it on a 386/16 "lunchbox" with a 40MB NEC 5146. It worked fine. >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? The amount of memory it displays is the total amount on the drive. It then subtracts 5MB for swap and then calculates. 37.4 MB would work, but 32 MB will not work (why this is happening is beyond me). Perhaps the BIOS entry is type 47 (user definable) and is set to this 716 number. Another possibility is that you are running with a DOS partition (which takes up space). You can't have a DOS partition on a tiny drive and expect to fit 386BSD on. >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... >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. We thought of this already. However, should extract find a corrupt set of files, one only has to reload that file set -- not the whole distribution as was the case with 0.0. Many people have found an error with one of their distribution floppies at the end, but only had to replace that floppy and type extract again. This was done as a convenience. In addition, since you can use the Tiny 386BSD floppy to obtain it via serial download and via the network, you need to have a place to hold the interim copies before you do the extract. I suppose we could have them make floppies and then reinsert them (shudder). :-) Quite frankly, in a era of gigabyte drives, trying to squeeze a 120MB pared down distribution in pieces onto a small drive is not practical. There are certain conditions that must be met before use is feasible. With the addition of X-Windows and other large packages that people find desirable, it becomes imperative that boundaries be drawn. Currently, we have enough quality work in-house now to fill a CD-ROM (uncompressed source and binary). It's getting exciting! >..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. Let's see if we can make it so you don't have to hang around. Time to look at the keyboard reset code (Any takers?). In the meantime, strike it out and recompile. Lynne.