Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!ihnp4.ucsd.edu!agate!violet.berkeley.edu!jkh From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Newsgroups: comp.os.386bsd.bugs Subject: Re: A host of freebsd bugs Date: 19 Jan 1995 06:56:20 GMT Organization: University of California, Berkeley Lines: 68 Message-ID: <3fl2ek$214@agate.berkeley.edu> References: <3fkp1d$2r2@satisfied.elf.com> NNTP-Posting-Host: violet.berkeley.edu In article <3fkp1d$2r2@satisfied.elf.com>, *Hobbit* <hobbit@asylum.sf.ca.us> wrote: >The boot manager WRITES into the MBR freely. Bad design. Causes trouble >with virus-preventive BIOSes, and crapping into the hard drive before your >real OS is up, fscked, and running is poor practice at best. I suggest >LILO as an example of something better. Sorry, we can't all go that route. BOOTEASY, which is what's bundled with FreeBSD 2.0, is no worse than any of the other (MANY) boot managers I've seen, and blaming FreeBSD for this is a little unfair. We didn't have time to write a boot manager of our own, and between OSBS, LILO and this, this was the easiest for us to use. We don't KNOW lilo! >The cpio set I pulled down is buggered somehow; when sysinstall invokes >"gunzip < /dev/fd0 | cpio -idum", gunzip returns 2 instead of 0 because >of "trailing junk". The cpio set is actually intact, but this causes Hmmmm. I will look into this. I don't understand why that image is buggered! >The mapping of MBR partitions to Freebsd filesystems is completely unclear. >How, for instance, was I supposed to know that the DOS partition on the second >hard drive was /dev/rwd1e?! I found it by pure accident. It was marked as a DOS partition in the disklabel screen; you just weren't paying close enough attention! I agree that this isn't entirely entuitive, but the info WAS there at some point during the install. >There is no way to get a SHELL out of the earlier stages of sysinstall >to try and fix any of this. There's no ROOM for a shell. You show me a way to pack a generic kernel and an installer on one 1.2MB floppy with a shell and I'll be happy to entertain the thought! >"mtools" should be in the default binary distribution, to make it easier >for folks to deal with DOS floppies. Why, when you can just mount them? >The kernel I got out of the abovementioned distribution has the <no_am> >floppy controller bug that someone recently mentioned. In fact, I can now >tell which kernel has the bug or not while it's booting, because I can >*hear* it sort of oddly gronkulate the floppy drive while probing it. >It gets gronked badly enough that the BIOS thinks the floppy is out to >lunch even after a hard reset. Fixed. >My first inclination here is to just launch the whole thing and install >Linux instead, but I'd really like to stick with it long enough to get >around these problems and maybe offer helpful suggestions for how the >release is packaged. I *can't* be the only person running into these >things; I pulled down the "obvious" stuff, and it fails miserably out >of the box. Well, you're always free to run Linux (believe me, you're not paying me and I'd just as soon avoid you you're gonna come with even the smallest emotional freight), but if you have a genuine interest in offering helpful suggestions then I am ALWAYS open to email detailing any faults found, and I will do my utmost to fix them. What I prefer in email is a simple, cold-blooded description of the problems. It's not important to me to know how you might FEEL about the problems, since your personal feelings are largly irrelevant to fixing the bug. Just describe the bug professionally and I will pledge to try and track/fix it professionally. Fair enough? Jordan