Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!spool.mu.edu!uunet!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!homer.cs.mcgill.ca!minstrel From: minstrel@cs.mcgill.ca (William LLOYD) Subject: Re: [386bsd] strange solutions revisited Message-ID: <1992Sep22.224438.3732@cs.mcgill.ca> Sender: news@cs.mcgill.ca (Netnews Administrator) Organization: SOCS - Mcgill University, Montreal, Canada References: <1992Sep20.185358.2092@drycas.club.cc.cmu.edu> <19nkmdINNkmf@agate.berkeley.edu> Date: Tue, 22 Sep 1992 22:44:38 GMT Lines: 96 In article <19nkmdINNkmf@agate.berkeley.edu> wjolitz@soda.berkeley.edu (William F. Jolitz) writes: > > >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. I am having the same problem on a 43 meg hard drive that I have. Dos will format it to 42.5 meg, but I cannot install 386BSD on it. I run out of space after about 2/3 of it. I dedicated this drive to 386BSD. 386BSD claims that it is only a 39 meg drive too. I am not using type 47, on my machine I am using type 33 (AMI BIOS). This is an old MFM drive, but I don't want to buy a new one yet. I have another 60 meg, that I might try to install it 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). :-) > When my installation failed with a file system out of space error, the machine rebooted. Enough of 386BSD was installed that it erased the /tmp directory on initiazation. So I not only don't have the full file system, but have to download it again. 40 meg is small I admit. I'll have to buy a new drive anyway to do anything worthwile with 386bsd anyway. -bill