From owner-freebsd-bugs Wed Jun 14 20:11:46 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA17417 for bugs-outgoing; Wed, 14 Jun 1995 20:11:46 -0700 Received: from clark.net (rwatson@clark.net [168.143.0.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA17411 ; Wed, 14 Jun 1995 20:11:43 -0700 Received: (rwatson@localhost) by clark.net (8.6.12/8.6.5) id XAA17966; Wed, 14 Jun 1995 23:11:40 -0400 Date: Wed, 14 Jun 1995 23:11:40 -0400 (EDT) From: Robert Watson To: "Jordan K. Hubbard" cc: bugs@freebsd.org Subject: Re: originally a newsgroup post, but news server here isn't working In-Reply-To: <1394.803179968@whisker.internet-eireann.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bugs-owner@freebsd.org Precedence: bulk Sorry to quote your entire email, but I'm currently running under XFree86 on the same 386sx20 w/4megs of ram, a 14.4 ppp line ftping the kernel source dist. As you might imagine, the keystrokes are a little bit slow to appear (though that's actually mostly the ppp line being overrun by ftp packets ;). Other than the 5 minute startup time on X, and removing the window manager and other useless memory hogs (;) it doesn't run too badly. When I moved the window managing to a remote system (olwm on a sparcstation ten) it really sped up (and that over a ppp line ;). Anyhow, enough of the pushing-the-reasonable-limits-of-any-sane--system.. This is the version on the UPDATES floppy that I used. The initial version didn't even boot, unlike this version which boots and does some of its intended actions. At this point I'm a little hesitant to reinstall again from scratch, because over this ppp line its about 6 hours a throw, and I've lost my dos partition several times so far. Speaking of which, there may be a bug in your dos partition handling -- once I rebooted and booted dos, I discovered a looped directory pointer -- I have d: mounted to /dos under freebsd, and had a /bin directory in it. When I next looked under dos, there was a bi directory entry in bi pointing back to bin again. under dos you can cd for a while (getting bin\bin\... until you run out of path space) -- under FreeBSD it won't allow the installation to continue. This wasn't there prior to freebsd, so it might be the dos handling routines (or it might be the memory lack or any number of things.) I fixed it up quickly with norton disk editor and then ran ndd and it picked up the rest. At this point, from my point of view, the best possible thing would be quick instructions as to how to make the boot manager load onto wd0 so I could boot freebsd off of wd1/a. Right now it just goes straight to dos booting off of c: (wd0) but if I stick in the boot floppy, boot to the boot manager, and tell it wd(1/a) it boots to freebsd fine. So I just lost the boot manager/boot block somewhere along the way. The man pages aren't exactly clear as to how to just arbitrarily stick in a boot manager (unlike dos's sys/fdisk/mbr, etc). If you want, I can try and pursuade the boot disk to reproduce the trash-the-partition table bug, but I'm not sure I want to ;). I believe it just happens when I tell the partition editor in sysinstall to view wd0 (which won't contain any unix stuff but a boot manager), set the dos partition as bootable (btw, my primary on wd0 (dos primary) doesn't show up as dos -- it shows up as unused under the partition manager.) Anyhow, I'm just sitting here babbling away watching keys show up occasinoally. If you could send me a list of specific things to watch for debugging wise, or such, I'd gladly write them down and mail them to you as things progress. I'll even trash my dos partitions a few more times.. Just let me know ;). Sorry for any hassle this is causing you.. Robert Watson rwatson@sidwell.edu http://www.sidwell.edu/~rwatson/ The goal of science is to build better mousetraps. The goal of nature is to build better mice. On Thu, 15 Jun 1995, Jordan K. Hubbard wrote: > > on my system. Admittadly it's a 386sx20 w/4megs of ram, but that's > > supposedly the min platform line or such. > > Egads. I suppose I should be happy that there are people like you > around to keep us honest, though frankly you're all also a big pain in > the butt! :-) :-) > > Anyway, all joking aside, on to the reported problems. > > > 1) sysinstall has problems with memory -- first it started killing its > > own processed (hadn't set up swap yet, hadn't given me a chance, but was > > This *is* with the latest 2.0.5R "UPDATES" boot floppy? As Gary > announced on the mailing list, we initially > made a mistake with 4MB machines and overflowed our maximum allowable > kernel size. Gary pared things back down again at the last moment and > stuck a boot boot floppy in place. If it's still dying WITH that > floppy, then we definitely want to know about it as it means that the > problem hasn't been fixed! > > > 2) Having the ppp installation line go down trashes the installation > > program, locking up the ppp dialer and not letting you reload a further > > Sorry, I expect a reliable line for now and will continue to do so for > the forseeable future - coding defensively for this isn't actually all > that easy, and there are bigger problems I'd prefer to focus on > solving anyway. Heck, 2.0R didn't even *support* a ppp installation, > so I figured one that works on a reliable line was still a fair step > up from none at all! :) > > > to an hour (assuming that would be enough.) When I got back, it had > > installed fine, but the system froze shortly afterwards when I tried to > > abort part of sysinstall. (pressing ctrl-c results in a reboot of > > Sorry, you can't really abort it effectively right now - I don't hold > and process signals at checkpoints, though I may perhaps add this at > some other point. > > > Xconfig program confused, as it suggested /dev/tty00 as a possible mouse > > device, but there wasn't one (after linking random tty files to > > /dev/mouse, I eventually found /dev/ttyid0 for the mouse on com1.) > > This is because they've been renamed for 2.0.5 (which really should be > documented in a "Changes" doc someplace - argh!). /dev/cuaa0 is the > ticket. > > > Boot assistance would be great -- I have a 230 meg FreeBSD slice on wd1 > > (a maxtor 540 drive) and a 130 meg dos slice on wd0 (130 meg maxtor > > drive) and a 270 meg and 40 meg slice on wd1 again. (eg., freebsd should > > boot off of wd(1,a)/kernel -- which it did one installation, only the > > sysinstall program never installed all of the binary installation that > > time ;). > > Try a reinstall with the latest, if you haven't already done so, and > select the boot manager option. Try to also be sure of each step in > advance; sysinstall isn't very fault-tolerant right now and it works > fairly well in most instances if you say just the right things to > it. :-) > > Jordan >