From csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail Thu Apr 13 15:16:12 1995 Path: csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 1 of 10) Supersedes: <386bsd-faq-1-795078010@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 27 Mar 1995 01:00:14 -0600 Organization: Dave's House in Omaha Lines: 1292 Sender: burgess@cynjut.infonet.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 04/14/95 02:00:10 CDT Message-ID: <386bsd-faq-1-796287611@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.infonet.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:14 comp.unix.bsd.freebsd.announce:13 comp.answers:10850 news.answers:40660 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part1 Frequently Asked Questions 386BSD, NetBSD, FreeBSD, and other BSD derived Operating Systems. EXTREMELY UNOFFICIAL Original FAQ by: Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu New FAQ by: TSgt Dave Burgess NCOIC, Configuration Management Section, US Strategic Command Instructor, Computer Science Dept, Nebraska College of Business President, Configuration Management Svcs, Inc. burgess@s069.infonet.net burgess@cynjut.infonet.net Last Update: 26 Mar 1995 Section 0. (Basic FAQ information) 0.0 Master Index. #undef unix 0.0 Master Index. 0.1 Introduction 0.2 About this FAQ. 0.2a What are the differences between *BSD and (your favorite operating system name here)? 0.2b Which is better, (your favorite operating system name here) or *BSD? 0.2c Is 386bsd better than (your favorite operating system name here)? 0.2.1 So what ARE the differences between the *BSD family and Linux? 0.2.2 I want to start up a thread about why *BSD is or isn't as good as some other operating system. Can anyone suggest a good reason why I shouldn't? 0.2.3 Are all of the Berkeley derived systems binary compatible? If not, what are the differences? 0.3 Are there any resources on the Net (like URLs) associated with the BSD family of operating systems? 0.4 How to add your pet answer to the FAQ. 0.5 Administrivia. 1.0 What is 386BSD? (Taken from the original INSTALL.NOTES by the Jolitz's, specifically Lynne) 1.0.1 What are these other Free BSD systems? 1.0.2 I just downloaded all of 386bsd version 0.1 and I can't get [some feature] to work? Do you have any suggestions? 1.1 Feature summary 1.2 The future of 386BSD. 1.3 386BSD software projects in progress 1.3.1 Contacting software authors 1.4 Minimum hardware configuration recommended 1.5 Where to get the source and binaries 1.5.1 Forms available (floppy, FTP, CD-ROM) 1.5.1.1 Where can I get the distribution on floppy or tape? 1.5.1.2 Where can I get the distribution via FTP? 1.5.1.3 Where can I get the distribution on CD ROM? 1.6 Electronic Information Groups for 386BSD 1.6.1 Usenet newsgroups 1.6.2 Newsgroup archives. 1.6.3 386bsd Derived mailing lists. 1.6.4 Other electronic resources. 1.6.5 System Updates. 1.7 Documentation available 1.7.1 BSD manuals 1.7.2 BSD books 1.7.3 The Jolitz Book 1.7.4 Dr. Dobbs' journal 1.7.5 Documentation that comes with most of the distributions. 1.7.6 Other FAQ's on the net that are relevant 1.8 FTP sites for 386BSD 1.8.1 FTP Site List 1.8.2 Official distribution sites 1.8.3 Reference sites 1.8.4 Unofficial archive sites that have neat stuff! 1.8.5 X for 386BSD 0.1 Ported Software List 1.8.6 Motif for the *BSD family. (Infomercial to follow) 2.0 Install process 2.0.1 Boot disks (versions and media formats) 2.0.1.1 Where does extract go when I reboot? 2.0.1.2 I put the floppy in and try to boot, and nothing happens. What now? 2.0.1.3a The floppy booted, but now the hard disk won't boot? 2.0.1.3b I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk? 2.0.1.4 What are the options on the boot prompt? 2.0.1.5 I just used the '-s' option on the boot, but I can't write anything onto the disk. What is wrong? If I use a plain 'mount' command it tells me that my root file system is read-only. 2.0.2 Fix-it boot disk 2.1 Binary distribution 2.1.1 I want to install by NFS but I am having all kinds of problems. 2.2 Source distribution 2.3 Additional software distribution 2.4 Patch-kit 2.5 Configuration 2.5.1 Partitions 2.5.1.1 What is a 'disklabel' and why do I need one? 2.5.2 Common Disk Label Problems. 2.5.2.1 Swap space. 2.5.2.2 Increasing the 386bsd partition size. 2.5.2.3 I can access the DOS partition on my second disk from Unix but not DOS? Any suggestions? 2.5.3 How do I set up the system so that I can boot from more than one operating system/file-loader without using floppies? 2.5.4 How do I disklabel my second hard drive? 2.5.5 386bsd/NetBSD/FreeBSD cannot handle disk geometry translations, but it turns out that my disk geometry is translated. It has five zones, each with a different sec/track! What kind of things can I do about the disk translation my hard disk controller uses? 2.5.6 My disk label is complaining about '256 heads' in the disklabel. This is obviously bogus, but it doesn't seem to be hurting anything. Is it Okay or should I fix it? 2.5.7 What are the options for the bootup prompt? 2.5.8 I am having trouble installing WRT 'syslogd: bind: Can't assign requested address' errors. What are some of the things I should look at? I also am having trouble with the network: 'starting network ... ifconfig: localhost: badvalue'. 2.6 Common installation problems. 2.6.1 Swap space not identified correctly. 2.6.2 Endless reboot cycles. 2.7 The computer just sits there, or 'that isn't right'. 2.7.1 The boot disk works all right on one computer but not another. 2.7.2 Really strange errors in the various *BSD flavors. 2.7.2.1 I am using the original 386bsd 0.1 with no patches installed and I get flashing multicolored characters and a "ptdi 81061" prompt error? 2.7.2.2 Using the new code in NetBSD, I get a "panic: pdti 206067" in pmap_enter(). What should I do? 2.7.3a I get the error "isr 15 and error: isr 17" on an NE2000 card. 2.7.3b I have some card on IRQ2 and it doesn't work; why? 2.7.3c I am getting lousy performance out of my network card. What are some of the other possibilities? 2.7.4 What is the difference between IRQ2 and IRQ9? Are they really the same, or are they really different? 2.7.5 Some of my SCSI devices (like a tape drive) don't work; why? 2.7.6 I try to run 'ps' or 'w' and get ': cannot get namelist' from the TinyBSD kernel. What did I do wrong? 2.7.7 I get a 'Floating point constant out of range' when I try to compile package 'n'. What is broke? 2.7.8 I want to use the Adaptec 1542C SCSI controller. What are the problems/tricks you need to know to get it working? 2.7.9 My system boots OK off the floppy, but once I try to boot from the hard drive, the message "changing root device to sd0a" appears and the system hangs. What is the most likely thing that I have done wrong? 2.8 Other common problems that are attributed to the installation process but are caused other places. 2.8.1 Why don't the man pages for "magic" and "file" work? 2.8.2 Why is apropos broke? 2.8.3 I want to use more than 16 Megabytes of memory. Will any of the BSD based systems support it? 2.8.4 I tried to use a device in my computer that should be there. When I did, I got a "Device not configured error." What do I do now? 3.0 System Internals 3.1 Kernel 3.1.1 How do I build a kernel? 3.1.2 I want to do one of the following things: * add a device not in the distributed kernel (third com port, additional disk or tape, line printer driver, etc). * use a patch from the net or the patchkit to fix a kernel bug. * add another swap device. * recompile the kernel to remove extraneous devices so that it takes up less space. * configure more pseudo-terminals to allow for more xterms or network logins. 3.1.3 I don't have the source distribution -- how can I rebuild the kernel? 3.1.4 Now that I have a kernel, how do I install it? 3.1.5 After installing the patchkit and recompiling the kernel with the option "WD8013", I am no longer able to reboot the machine. A cold boot (power on) runs fine, but after a reboot no boot drive is found by the BIOS. Besides having a 16-bit WD/SMC Ethernet card installed the machines try to boot using either a Adaptec 1742 or 1542 SCSI board to boot from. 3.1.6 My system is complaining about stray interrupt 7. Is my machine going to explode or anything? 3.1.7 I keep getting "wd0c: extra interrupt". What does it mean? 3.1.8 I found a bug in the kernel. How do I report it? 3.1.9 Can someone please give a reasonably clear set of instructions as to how to get a "current" version of NetBSD running? 3.2 What exactly is this config file, anyway? What are all of these cryptic notations? 3.2.1 Okay, fine. Why shouldn't I just add every device I can find to the kernel, so I'll never have to recompile this again? 3.2.2 What should I remove from the kernel? 3.2.3 I can't get enough remote login sessions or xterm sessions. I also can only get four sessions working at a time. What can I do? 3.2.4 How do I get ddb, the kernel debugger, compiled into the kernel and running? 3.2.5 Can I patch the current running OS image? 3.2.6 Can I have more than one config file? Should I rename it to something else? Any other hints? 3.2.7 What is the meaning of the trap codes I get in panic messages? Sometimes this message appears in the form "trap type nn". 3.2.8 I have been getting a lot of "virtual memory exhausted" errors when I am compiling a program with a really big static array. I have 128Meg of memory and 8Gig of swap. How can this be happening? 3.2.9 Where can I learn more about all this? 3.2.10 Does anyone have a system building script that takes things like building a new config and multiple config files into account? 3.3 X11/XFree86/XS3 3.3.1 What options should I define to get the X extensions included? 3.3.2 Where can I get the FAQ for 'X'? 3.3.3 Why does X drop characters when using xdm? When I run xdm from the console, it keeps losing keystrokes and the shift keys don't always work. Why? 3.4 Compiler and Library routines 3.4.1 Which C compiler is shipped with my 386BSD derived system? 3.4.2 Where is libcompat.a? 3.5 You promised to talk about timezones below. Are you going to? 3.5.1 How do you change the timezone on NetBSD (FreeBSD also?)? 3.5.2 The translation between seconds-since-the-epoch and date differs by about 18 seconds between BSD and other Unixes when running ntp; why? 3.6 Optional Op-codes for NetBSD, FreeBSD, and other systems. 4.0 Introduction 4.1 Common Kernel-related problems 4.1.1 Where are the commands "rpcinfo" and "rpcgen"? 4.1.2 Where can I get a working "netstat"? 4.1.3 How can I fix NFS to work with my NE2000 board? 4.1.4 How can I get "ps" and "w" to work? 4.1.5 Where are re_comp and re_exec? 4.1.6 What about the termio, termios, and termcap stuff? 4.1.6.1 Where are stty() and gtty()? 4.1.6.2 Sometimes I have trouble with my system resetting the terminal to seven bit mode. Isn't 386BSD eight bit clean? 4.1.7 The system hangs with the HD light on after intense disk usage. The system hangs when trying to fsck -p both of my IDE hard drives at boot-up. 4.1.8 How do you implement quotas on Net/2 derived BSD systems? 4.2 Available kernel add-ons 4.2.1 The Patch-Kit 4.2.2 Shared Libraries 4.2.3 Sound Blaster Drivers 4.2.4 Bus Mouse Drivers 4.2.5 PPP Support 4.2.6 re_comp and re_exec library functions 4.2.7 Intel i82586 Ethernet Controller driver 4.2.8 PC Speaker driver for Nethack 4.3 Other program building type problems. 4.3.1 Greetings from Mars. I am building a program that requires access to the crypt library. Either I have it and it isn't getting copied into the executable, or I don't have it; why? 4.3.2 I am having trouble with long file names in my libraries. It seems like there is a 16 character limit in the library somewhere. 4.4 Where is the 'adduser' program? 5.0 Introduction 5.1 Available Kernel Replacements 5.1.1 keycap/codrv 5.1.2 pcvt 5.1.3 syscons 5.1.4 Fast Symbolic Links 5.1.5 npx fixes 5.1.6 CGD's COM drivers 5.1.7 The original 386bsd 0.1 wd.c driver doesn't work. [386bsd 0.1 only] 5.1.8 Interruptless LPT Driver Kit [386bsd 0.1 only] 5.1.9 A replacement curses program/library. 5.2 Floppy Disk problems. 5.2.1 How do I get a bootable floppy? 5.2.2 How do I maximize the space on a mountable floppy disk. 5.3 Character Device Driver info 5.3.1 Printers 5.3.2 Terminals/Keyboards 5.3.3 Modems 5.3.4 What is the trick for getting Kermit to work with rz and sz? 5.4 Tape Drives 5.4.1 Does the tape need to be formatted? 5.4.2 If I execute the command 'st -f /dev/st0 status', I get: Archive/Tandberg? tape drive, residual=0, blocksize=512 Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5) ds=0 er=0 5.4.3 When is erst0 used? 5.4.4 How is density (bpi) computed? I am using 3M DC 6250 cassettes which have a 250MB capacity on the Viper 150. But computing the bits/inch based on 250MB/tape-length (1020 ft.), I get a density of 171335 bpi, which is nowhere near the 10000 bpi associated with QIC-150 in the st(1) man page. Why the discrepancy? 5.4.5 How is an appropriate block size determined (and in what units are they specified in the st(1) command)? 5.4.6 From the 4.3BSD mtio(4) man page, it sounds like data is typically (traditionally?) stored on tape in eof-terminated sequences of 1K records. 5.4.6.1 Is st's notion of "file" the record sequence between two eof marks? 5.4.6.2 What about a "record"? 5.4.6.3 Is a "record" one "block", as determined by st's "blocksize" command? If not, what is the connection between them? 5.4.6.4 Can I change the "record" size? 5.4.6.5 When would I want a block size that is different from the default? 1KB is the size of writes used by dd or whatever. QIC specifies 512 byte records (well at least its what people use..) Whatever you write in will be broken into 512 byte sections. They must be multiples of 512 though. 5.4.7.1 How do I write several archives to a single tape? I tried without success: $ st -f /dev/rst4 rewind $ tar cf /dev/nst4 archive1 $ st -f /dev/nrst4 weof $ tar cf /dev/nst4 archive2 $ st -f /dev/nrst4 weof 5.4.7.2 Later, I would expect to be able to access, say, archive3 via the fsf directive to skip over the first two archives. What is the correct sequence? 5.4.8 Since the Viper 150 writes on QIC-150/120, I guess I don't need to worry about writing variable-length records? How about reading a tape written with variable-length records. Is this possible with the Viper? If so, what's involved? 5.4.9 The very scant documentation that came with my drive mentions a "selectable buffer disconnect size," whose default is 16K. This is evidently the "maximum number of bytes that can be sent over the SCSI bus during a single data transfer phase." What's that? How is it connected st's "blocksize" command? Do I want to use 16K blocks, or might I even want to set the disconnect size to a higher value? 5.4.10 What is "streaming"? When I tar a directory of files to tape, I notice that the tape often stops. Streaming means it doesn't stop? How would I get the viper 150 to stream using tar or cpio or dump? 5.4.11 Where are all the answers to the above and related questions written down? Neither on the net nor in the 4.3BSD manuals nor Administration text which I have could I find this stuff covered! 5.4.12 What else should I know? For example, it seems that a new tape must stretched. How is this done? 5.4.13 My tape drive doesn't work. 5.4.14 I am trying to restore a tape from a FreeBSD machine on a Sun. What kinds of problems should I expect? 5.5 Network 5.5.1 How can I get my system to work as a network router? 5.5.2 I recently has a problem where I got a message that said "panic: kmem_malloc: mb_map too small". What is the solution to this problem? 6.0 Working with DOS and BNR/2 related software. 6.1 Formatting a floppy 6.2 Sharing the Disk with MS-DOS 6.2.1 How can I partition my drive to support both MS-DOS and *bsd? 6.2.2 I can install using the whole disk, but I can't install when I try to share the drive between 386bsd and MS-DOS. Why? 6.2.3 I can use either MS-DOS or 386BSD on my hard drive, but shutdown -todos doesn't seem to work. 6.2.4 Is there any hope of ever running MS-DOS applications under any of the free BSD systems? 6.3 Accessing the MS-DOS filesystem 6.4 NFS/PC-NFS support 6.4.1 Can I use 8K packets for NFS? When I try, I have all kinds of problems. Specifically, I get 'ring buffer overflows' or the performance is real bad. 6.4.2 How do I get around the NFS "Permission denied" error? 6.4.3 What does the message "BAD MNT RPC: RPC Authentication error; why = Invalid client credential" mean when I try to mount something from another machine? 6.4.4 What does the message "Bad MNT RPC: RPC: Authentication error; why = Client credential too weak" mean when I try to mount something from another machine? 6.4.5 I get a lot of 'ring buffer overflow' messages using NFS and the ed0 driver. Is there a problem? 6.4.6 Is there any PC software that will allow me to use my enormous PC with all of the unsupported hardware as a PC-NFS server? 6.5 How can I use mtools with the 'new' floppy naming convention? 7.0 Communications 7.1 SLIP/CSLIP 7.2 PPP 7.3 TCP/IP 7.4 UUCP 7.4.1 TIP/CU 7.4.2 What is the magic incantation that allows the modem to dial? 7.4.3 My modem on DOS COM3 or DOS COM4 works with DOS, but not with *BSD. It is set up using IRQ 4 (or 3) respectively. 7.5 Terminals 7.6 My network manager (or UUCP feed site admin) just informed me that the way I have installed sendmail through my UUCP connection and has caused a sendmail loop. Can you help me get sendmail installed correctly? 7.7 Can network attached assets be used by/from NetBSD? 8.0 What hardware is 386BSD known to run on and support! 8.1 Video cards 8.2 Mice and Trackballs 8.3 Serial Cards 8.3.1 How do I configure multiport cards? Is there a possibility of using multiport serial boards? How do you configure an AST/4 in the kernel? It looks like the AST driver only supports 4-port cards, but it looks like it would be easy to add support for 8 ports ... or am I wrong? 8.3.2 Now that I have FreeBSD 1.0 installed, how do I set up the serial ports for bi-directional use? 8.3.3 What is the difference between baud and bits per second? 8.3.4 How do I get a serial console to work? 8.4 Disk Controller Problems 8.4.1 IDE controller problems 8.4.2 SCSI controller problems 8.5 SCSI Controllers 8.6 Network Cards 8.7 Printers 8.8 TAPE Drives 8.9 QIC-40/80 tape drives 8.10 CD-ROMs 9.0 What GNU software has been tested and is working with Net/2 derived BSD systems for the 386? 9.1 Has anyone ever gotten news to work? 9.2 How did you get emacs to compile? 9.2 Has anyone tried to get Postgres to work? 0.1 Introduction The 386BSD 0.1 operating system was originally a derivative of the generally available parts of the Berkeley Net/2 release. The definitive "man without whom we would have nothing" in this effort has been William Jolitz. For more information, download the code. 386BSD is fully redistributable and is intended as a research OS. As such, many contributions to the system are provided through interaction by people who communicate via many means. Many new and innovative features have been added to 386BSD since it's original release in June of '92. There was an 'unofficial' patchkit which was available from many anonymous FTP sources which makes 386BSD more stable and usable. Many problems associated with the use of 386BSD Version 0.1 were solved through the application of patches from the patchkit. In addition, many common Unix packages have been ported with varying degrees of difficulty. 386BSD is available completely free of charge. It is also available on CD-ROM and many other methods, most of which end up charging for 'media and handling costs'. It is available by Anonymous FTP and through FTP-Mail. Recently, a new CD-ROM version of 386BSD has been announced in Dr. Dobb's Journal. It may be the long awaited 386BSD 1.0, or simply a revenue enhancement version of 386BSD 0.1 (or 0.2). 386BSD came in three distinct pieces, each of which was exclusive of the other two. These distributions were called the 'bindist', 'srcdist', and 'etcdist'. The bindist could be unloaded from its native form (on about 10 diskettes) and loaded onto a 42Meg hard drive partition. It is a fully functional system, including gcc 1.39, all executables for normal Unix style operation, and many other things. The etc distribution included MANY additional programs (all with source) which extended the functionality of 386BSD. The srcdist was the source code for 386bsd, along with all of the header files not included in the bindist. All of the distributions and compilation files would fit onto 180Meg of hard drive (barely). In addition to the original 386BSD, two newer versions of the system are available, under new names. NetBSD is the older (or newer depending on whom you choose to believe) and FreeBSD is the other. Both systems have evolved into programs that are superior to the progenitor and both have sizable (if a little rabid) followings. Most of the statements made in this FAQ will apply to all three, although I will try to differentiate one from another whenever the difference matters. Any place that says 386bsd either means the original 386bsd 0.1 (you should be able to tell by context) of any of the three members of the PC BSD family. There have been many attempts to polarize the FreeBSD and NetBSD development groups in the past. One of the reasons that I am still maintaining the FAQ is that it simply is a good source for historical information, as well as a reasonable source for information that is specific to the implementations of NetBSD and FreeBSD. It should be noted that when the *BSD family started out, they used a source called the "Berkeley Net Release/2" tape as their genesis. While this has provided a stable starting point, it also built a possible bomb into the system. Due to an ongoing legal battle (which has now been resolved) the following files are identified as 'encumbered' in the BNR/2 source tree. These kernel files are identified as the 'binary only' files in the BSDI distribution, and either have been or must be replaced before we can have a truly free OS family. This is the pertinent excerpt from a letter from someone (whose name I have lost) indicating what is and is not releasable. Q: What's all this about `binary-only files'? Will BSDI continue to ship source code? A: For Version 1.1 only, BSDI will ship the following kernel files in binary format: kern/init_main.c kern/subr_rmap.c ufs/ufs_bmap.c kern/kern_clock.c kern/sys_generic.c ufs/ufs_disksubr.c kern/kern_exit.c kern/sys_process.c ufs/ufs_inode.c kern/kern_physio.c kern/tty.c ufs/ufs_vnops.c kern/kern_sig.c kern/tty_subr.c kern/kern_synch.c kern/vfs_syscalls.c Our (Berkeley's) 4.4Lite-based release will again include the entire source tree (with the exception of a tiny number of device drivers whose interfaces are kept confidential at the request of their authors. I have it from a reasonably reliable source that these files either have been completely rewritten in a 'clean room' development effort or were replaced with code from other sources (such as CMU, or GNU). The encumbered sources for the user land portion of the system have long since been replaced. 0.2 About this FAQ. This FAQ consists of 10 parts: Section 0. Basic FAQ information Section 1. General Network Information Section 2. Common installation questions Section 3. Kernel Building and Maintenance Section 4. Kernel Additions Section 5. Kernel Replacement Parts Section 6. Interaction with MS-DOS Section 7. System Communication Section 8. "Supported" Hardware List Section 9. "Supported" Software List It has been suggested that I remove some of the older, less relevant information from this FAQ. I have given it some thought, and I might. Of course, if someone were to do it for me, it sure wouldn't break my heart. 0.2a What are the differences between *BSD and (your favorite operating system name here)? 0.2b Which is better, (your favorite operating system name here) or *BSD? 0.2c Is 386bsd better than (your favorite operating system name here)? I decided to put this in section 0, primarily because it by far the most asked and least useful question in comp.os.386bsd.*. You will often see this question veiled as a request for a brief description of the differences between 386bsd and (YFOS). This type of request, while seeming to be a reasonable one, is usually looked upon as either an attempt by some folks for the net to do their homework, or as an attempt to start yet another flame-war. What is the answer to this question, then? No. It is not. Nor is it any worse. It is DIFFERENT. There are alternative Operating Systems available, both free and commercial. 386bsd, NetBSD, FreeBSD, and Linux are examples of "free" Unix style Operating Systems. If you ask any of these questions, you are wasting a LOT of bandwidth and making a real name for yourself. Don't bother. It nearly always ends up in name calling and 'mine is bigger (or littler) than yours...' arguments. I have included an excerpt below: >>>>>>>>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>> Is not! >>>>>>>>>>>>> Is so! >>>>>>>>>>>> Is not! >>>>>>>>>>> Is so! >>>>>>>>>> Is not! >>>>>>>>> Is so! >>>>>>>> Is not! >>>>>>> Is so! [the rest of this scintillating debate is deleted...] Here are a brief list of differences between 386bsd and other systems: 1. *bsd will not run DOS applications natively. There is currently a DOS emulator in work. It is called pcemu, and it provides 8086 emulation for DOS programs. It only works in text mode. There is also work on a Windows program loader execution version. The project is called 'WINE' and is the free version of the 'WABI' project. More on that to follow. 2. 386bsd is not binary compatible with anything but the other free BSD systems (NetBSD, FreeBSD, and their kith). There are rumors and rumblings from time to time that one or more of the *Nix variants may be binary compatible with NetBSD or FreeBSD. The more the merrier. Be warned; if the package you are trying to run is not specifically compiled and linked for your version of {Free,Net}BSD, then you may well be completely on your own. Recent advances have provided some success in getting iBCS2 compatibility working, allowing certain SCO and AT&T Unix programs to work. See the newsgroups for more current information. 3. FreeBSD, which originally started life as 386bsd 0.1 with the patchkit applied, has since evolved into an entirely seperate BSD lineage in its own right and incorporates many important innovations. In addition to extensive, high quality work that has been done on the FreeBSD kernel, a great deal of effort and time has been invested in improving the overall level of quality in such areas as the installation and maintenance scripts, third-party applications packaging, and many of the various utilities and development tools in BSD. The emphasis seems to be on better packaging and improved operation, and with special emphasis being placed on positioning FreeBSD as an 'Intel-specific' BSD variant. Much care taken specifically to support the various and sundry peripherals and hardware one finds on the Intel PC world. FreeBSD is now based completely on the fully unencumbered BSD 4.4 Lite and is still intended primarily for the Intel platforms. 4. NetBSD, on the other hand, is intended as a multiplatform 'replacement' for Net2. It has built-in support for so many different platforms that I simply can't begin to list them. With the exception of the multiplatform support that is built into NetBSD, the two system are very similar and seem to parallel one another very closely. Since the NetBSD folks seem to be the self proclaimed 'bearers of the standard' for multi- platform BSD support, they are also proceeding with switching over to the 4.4 Lite tape. 5. Where BSD and POSIX differ, 386BSD conforms by default to BSD; Linux to POSIX. Furthermore, while both run mostly GNU utilities, Linux tends toward the SysV flavor (e.g. init) where 386BSD sticks with the BSD style. However, sources for different flavors of utilities are available for both, and both support compiler options which allow more BSD or more POSIX semantics. Clifford Stoll talks about the 'West Coast/East Coast' feeling of BSD/SysV in his book "The Cuckoo's Egg". In keeping with that, BSD feels like BSD/West Coast, Linux feels like SysV/East Coast (actually, Finland is what it says on the passport, but stay with me for a minute). If you don't believe me, just look at the primary U.S. archive sites. Linux is available from MIT, BSD is available from Berkeley. Can't get much more 'Coast' than that. :-) Actually, NetBSD and FreeBSD are feeling more and more POSIX all the time. Recent releases of both products have implemented many more POSIX compliant utilities, features, and low-level hooks into the operating system. A great deal of effort has gone into supporting and improving the POSIX standards compliance throughout all of the systems. 5. Linux, NetBSD, FreeBSD, and 386bsd share two vitally important facets. All are free and all include source. They are all excellent, and all fill a niche that the others would gladly leave available. Also, don't forget one of the most important things; get what your friends have. Then they can help you. 6. Finally, remember that this FAQ and the comp.os.386bsd.* groups are intended as places for 386bsd users and developers to meet and discuss topics which are germain to the further development of 386bsd. For more information about Linux, you can read the comp.os.linux.* newsgroups. If you are a 'rabid' Linux user, stay on the Linux groups. Most of us don't care how much better Linux is than *BSD. 0.2.1 So what ARE the differences between the *BSD family and Linux? Here it is, in its 'right for today' glory. As of 1 July, 1994, these statements were more or less accurate. Against my better judgement, I am going to include this, primarily because it is a very even handed approach to describing two very different systems. For those of you that find it, I hope that it answers some of your questions. It was written by: Thomas Heiling Pharmacist & Doctorate at Pharmazeutisches Institut Uni Wuerzburg - Germany Email phar006@rzbox.uni-wuerzburg.de (HP-UX) tom@wpzd07.pzlc.uni-wuerzburg.de (Linux) or phar006@vax.rz.uni-wuerzburg.de ( VAX ) I have read this group now for some time and saw this thread Linux-BSD coming often. Some answers to this question were good, but the FAQ was not updated. It is IMHO *not* very helpful to flame a newbie, that he/she should read the FAQ, where there is no information, nor it is helpful to shout to him "Hey man read the previos posts - I *hate* this thread!" What is missing here is an overview and a comparison of the free available Unixsystems. And this info should be in the FAQ ! I will start here such a comparison. Q: For whom should this be ? A: For a (hopefully) new Unix-user, who wants to install one of the free Unixes. He should be able to read this document, look at his hardware, define his needs for a Unix-systems and then he should be able to choose a system which meets his needs. Q: Who am I and why should I be able to write such a doc ? A: Good Question ! My name is Thomas Heiling, I am working at the University of Wuerzburg in Germany as a doctorate. My job is to program an Ultraviolett/Vis-spectrum comparison program. Furthermore I am the person, who maintains the Internet connections and computers of our Department. I have running Linux and NetBSD 0.9, the main Server is a 486/33 + 16 MB which runs Linux. A 486/66 is for numerical work. Then there are some clients mostly 386 with either 4 MB or 8 MB. One 386 with NetBSD, but this is just for testing. So I would say I can speak for Linux, a little bit for NetBSD and I have no idea for FreeBSD beside the Installation Guide. (I have no access to the BSD386 1.0 CD, which was announced some time ago). * PLEASE PLEASE PLEASE * It would be very helpful, if someone of the Core-Team of NetBSD and/or FreeBSD have a look at this and fill the white spaces, which I left. And if the FAQ-maintainer reads this, it would be nice, if he thinks this info should be in the FAQ. Hardware requirements : Linux: CPU: Anything that runs 386 protected mode programs (all models of 386s and 486s should work; 286s don't work, and never will). Architecture: ISA or EISA bus. MCA (mostly true blue PS/2's) does not work. Local busses (VLB and PCI) work. RAM: Theoretically up to 1 GB. This has not been tested. Some people (including Linus) have noted that adding ram has slowed down their machine extremely without adding more cache at the same time, so if you add memory and find your machine slower, try adding more cache. Data storage: Generic AT drives (IDE, 16 bit HD controllers with MFM or RLL) are supported, as are SCSI hard disks and CD-ROMs, with a supported SCSI adaptor. Generic XT controllers (8 bit controllers with MFM or RLL) are now also supported. Supported SCSI adaptors: Adaptec 1542, 1522, and 1740 in extended (not 1542 compatible) mode, Seagate ST-01 and ST-02, Future Domain TMC-88x series (or any board based on the TMC950 chip) and TMC1660/1680, Ultrastor 14F, 24F and 34F, and Western Digital wd7000. SCSI and QIC-02 tapes are also supported. Support for QIC-80 tapes is now in ALPHA testing. Several CD-ROM devices are also supported, including Matsushita/Panasonic, non-EIDE Mitsumi, Sony, Soundblaster, Toshiba, and others. Video: VGA, EGA, CGA, or Hercules (and compatibles) work in text mode. For graphics and X, there is support for (at least) normal VGA, some super-VGA cards (most of the cards based on ET3000, ET4000, Paradise, and some Trident chipsets), S3 (except for Diamond Stealth cards, because the manufacturer won't tell how to program it), 8514/A, ATI MACH8, ATI MACH32, and hercules. (Linux uses the Xfree86 X server, so that determines what cards are supported.) Networking: Western Digital 80x3, ne1000, ne2000, 3com503, 3com509, Allied Telliesis AT1500 (said to be some of the fastest, as well as quite cheap), d-link pocket adaptors, SLIP, CSLIP, PLIP (Parallel Link IP), and more I have forgotten at the moment. Other hardware: SoundBlaster, ProAudio Spectrum 16, Gravis Ultrasound, AST Fourport cards (with 4 serial ports), several models of Boca serial boards, the Usenet Serial Card II, several flavours of bus mice (Microsoft, Logitech, PS/2). *BSD: Architecture: ISA or EISA bus. MCA (mostly true blue PS/2's) does not work. Local busses (VLB and PCI) are also supported. Standard hard disk controllers: MFM ESDI IDE RLL SCSI hard disk controllers: Adaptec 154x *, Adaptec 174x, Buslogic 545S, Bustek 742(EISA) DTC 3290 in 1542 emulation mode *, Ultrastor 14f and 34f, and the 24f experimentally. The Soundblaster SCSI code is also being tested and should work eventually. Display Adaptors : MDA,CGA,VGA,HGC for textmode. For X the same as Linux. Serial Communications: 8250,16450,16550A, 4-port multi-serial cards require a kernel rebuild. Ethernet controllers: SMC/WD 8003, 8013 and equivalents ( including SMC Elite ) Novell NE1000,NE2000,NE2100 3com 3c503 ISOLAN ISOlink Tape Drives: QIC-02 format tape drives QIC-36 format tape drives QIC-80 format tape drives (in FreeBSD) most SCSI tape/DAT drives on a supported SCSI controller CD-ROM drives: Mitsumi CDROM with Mitsumi Controller (not EIDE) Most SCSI CD-ROM drives on a supported SCSI controller Other hardware: SoundBlaster, ProAudio Spectrum 16, Gravis Ultrasound, AST Fourport cards (with 4 serial ports), several models of Boca serial boards, the Usenet Serial Card II, several flavours of bus mice (Microsoft, Logitech, PS/2). Same as Linux, although some options may require a kernel rebuild. Harddisk Storage requirements : FreeBSD: Base System 16 MB Full binary distribution 46 MB Full source " 72 MB Kernel Source 7 MB Swap 8 MB They say, that the minimum is Base + Binary + Swap, and that this minimum is 80 MB. For a complete system with binary and source you need at least 210 MB. This does NOT include X or LaTeX. Linux: This is difficult, because there are different distributions to choose from. Every distribution has a special goal. I will show two popular distributions : - Slackware and the MCC-Interim Distribution. Slackware is intended for a full fledge system, which has everything you want. You need about 150 MB for this. - MCC-Interim is intended for small systems. The main idea is to give a ASCII-environment for programming courses. For a full MCC install you need about 47 MB + 8 MB Swap, you can strip this down to 23 MB + 8 MB Swap, if you don't want emacs, no kernel source and no extras. Some other features: virtual terminals/consoles: All of the -current versions of *BSD have virtualy consoles available. Linux has virtual consoles as well. shared libraries: NetBSD, FreeBSD, and Linux have it. I recall a thread some time ago, which was something like "Linux shared Libs are no good - A pain for the developer." For the user this should be meaningless. NetBSD and FreeBSD shared library implementations are both very easy to use both from the developer and user point of view. Networking: *BSD networking is more mature, but with Linux 1.0 it's getting closer. One Feature of Linux is the ability to make a filesystem on top of a DOS-FAT, so you don't need to repartition your Disk. This Filesystem is of course not so fast as a native Filesystem, but for trial it should be O.K. Conclusion: It depends on you hardware and what you want to do with your system. If your hardware is supported and if you have the resources and if you are on the net, I would vote for *BSD. If you just want some *iX experience and have low ressources, choose Linux. Here are some pro's and con's for both : *BSD: + Full Source Code of all commands in a source tree, no need to look all over the Internet for the source of a command. + There is only one distribution, which is valid for some time. + Networking is better. + The system is standard BSD. - You need extra packages for XFree and for TeX. They are not hard to find, and install into a standard location in the directory tree, but they are not included in the base distribution. Linux: + Uses fewer resources + Has more support for devices - Every distribution is a little bit different - Development is too fast without net access I include here some info from other posts, which should help the new user to show the differences: burgess@cynjut.infonet.net wrote: : NetBSD is the OS I use. It is a BSD derived Operating System : that has a very stable operating envelope. The networking code : has been stolen by commercial OS and network vendors the world : over. NetBSD has the advantage of being meant for a wide : range of hardware platforms. It is currently available for : something like 10 different CPUs, and has been laid out such : that new architectures can be added relatively painlessly. These arechitetures include several Sun Systems, many Motorolas, including the Amiga and Mac, and several other older mini- and microcomputer systems. : : FreeBSD is pretty much the same (go ahead a quibble over : details, I don't care anymore). The biggest difference is that : NetBSD is a horizontal system (across platforms) and FreeBSD is : a vertical system (intended to stay on the Intel family). Both : are based on code from 386BSD, although neither really resembles : it any more. : : Linux was developed by Linus Torvalds and has the advantage of : being available in source code form first. Other than that, I : have heard that it is a good OS platform for standalone Unix : workstations. It had a lot of things that made its users rabid : before the *BSD folks did, but the purists insist that *BSD is : (choose two: cleaner, safer, taller, wider, better, quieter, : louder, greener). I even heard a rumor that Linus had sold the : source code license to Novell so that they could distribute an : 'X' terminal package for use in their networks. From: hedrick@geneva.rutgers.edu (Charles Hedrick) There are four major differences: 1) the 386BSD family started with BSD, and Linux started with POSIX. NetBSD/FreeBSD/386BSD have been adding POSIX and System V compatibility, and Linux has been adding Berkeley and System V compatibility. So there's a good deal of overlap. But ...BSD is still a better choice if you want to program in a Berkeley environment and Linux if you want a POSIX environment. That's for the kernel and libc -- the utilities and other stuff users see tends to be fairly similar. In both cases the programs are what I call "typical University Unix". The main difference is that the base Unix utilities tend to be Berkeley for ...BSD and Gnu for Linux. Gnu is fairly Berkeley-compatible, but its priority is POSIX, so it tends to look slightly closer to System V, with massive Berkeley extension. There are several sets of administrative utilities, but it's more likely that init, getty, etc., are going to be System V style for Linux and BSD for ...BSD. Again, these things aren't as significant as they might be because ...BSD is also concerned about POSIX compatibility and Gnu is concerned about BSD compatibility. So both sets of software are approaching a similar sort of goal from opposite directions. You could probably use the systems for quite a while without noticing much difference. (I'd like to emphasize that there's no similarity in overall feel between Linux and typical brain-dead PC System V ports.) The ...BSD FAQ characterizes the difference as one of East Coast vs. West Coast. There's a lot to be said for that summary. There's more difference in Unix culture between New Jersey and California than between New Jersey and Finland. 2) The nature of the development communities and distribution mechanisms are different. ...BSD has two or three different developer communities that take code from each other, but appear to hate each other's guts. (Actually, even ...BSD and Linux take code from each other.) Thus there are several different ...BSD's, each of which has an official distribution. There's just one Linux kernel, and from a practical point of view just one set of major utilities, but there's no official distribution. So several different groups put together distributions, with their own choice of kernel and utility versions. This means that it's easier to define what the One True Linux is than what the One True BSD is, but harder to get it. Once you've decided which BSD is the right one, it's easier to find an authoritative distribution of it. Development of Linux tends to be more distributed. Lots of people are working on lots of projects: new drivers for this and that, new versions of this utility and that. If you want to keep up with NetBSD, you can sup netBSD-current from one or two places. If you want to keep up with Linux, you end up taking pieces from lots of people (though they generally end up on one of two archive machines -- tsx-11.mit.edu or sunsite.unc.edu). If you don't want to do this, of course the packaged distributions do it for you. 3) The BSD networking is more mature than the Linux networking. This is one area in which I don't think Linux has any countervailing advantages, though in my opinion by release 1.0 Linux networking will be acceptable. 4) There are specific things in each system that are likely to be deciding factors for some people. I don't know what unique things BSD has, because I'm not part of that community, but for some people the COFF and ELF compatiblity projects may be big selling points. Both ...BSD and Linux are working towards having these executable formats available. In addition, Windows executable emulation may also be important to some people. This is probably more useful, and it's being done jointly by developers from both BSD and Linux cooperatively. (Neither of these things is finished, by the way.) It's not clear to me whether the existing Linux DOS compatibility is a critical advantage. BSD doesn't have it, but my experience is that the Linux DOS emulator is slow enough and creaky enough that it's not generally usable. However it certainly does work for many programs, and if one of those programs is critical to you, it may be a big deal. Differences in support of devices are not likely to persist for long. There's a history of taking device drivers in both directions, so if there's enough interest in a device, and one side implements it, you can bet it will show up on the other side. Linux uses DOS partitions (including extended partitions). BSD creates its own partitions inside a single DOS partition. This is a difference, but it's unclear whether it's a critical one. Linux and ...BSD can all mount DOS filesystems and Linux can mount OS/2 file systems (OS/2 is read-only). For a lot of people, the best suggestion is to find out what your friends are doing. If there's a significant user community near you of either kind, you're probably best off to go with it. If not, flip a coin (or look at a map and see whether you're nearer Berkeley or Finland -- note that in this comparison portions of the distance that are over an ocean don't count). 0.2.2 I want to start up a thread about why *BSD is or isn't as good as some other operating system. Can anyone suggest a good reason why I shouldn't? Jordan Hubbard, one of the FreeBSD core team members, has offered this missive on that very subject: [ Note: You could very well simply substitute the word "NetBSD" for Linux in the argument that follows ] From time to time, a thread in both the comp.os.386bsd.misc and comp.os.linux.misc groups flares up regarding which operating system is "better", FreeBSD or Linux. This generally provokes controversy from users on both sides, with one group claiming that their OS is "better" for some reason and the other group claiming that the first group doesn't know what the heck it's talking about. Both arguments are a waste of time. Rather than trying to win a rather questionable debate on relative (and constantly changing) technical merits, we should be asking ourselves what both groups are REALLY about and what they represent. This is naturally going to be a matter of personal opinion, but I believe even the most seriously at-odds members would agree that both operating systems represent a unique and long-awaited opportunity: The ability to run a fully featured operating system on popular, easily affordable hardware and for which all source code is freely available. Those who have been in computing for awhile will remember when the term `operating system' referred almost exclusively to something provided solely by the hardware vendor, with very little in the way of alternative options. It was never EVER given out with source code, and true "wizard" status could only be achieved by exerting mind-numbing amounts of effort and patience in digging through forbidden bits of binary data. By comparison, the situation today seems almost too good to be true! Certainly, the feeling of achievement that came from finally ferreting out some esoteric bit of information from a 4MB printed system dump was high, but I don't think that anyone would argue that it was hardly the most optimal way of truly getting to know your operating system! :-) So now, within a very short space of time, we're almost spoiled for choice in having machines several times more powerful than the first multi-user VAX machines and available for under $2000, and we've got not one but SEVERAL perfectly reasonable free operating systems to chose from. We are in a comparative paradise, and what are some of us doing? *Complaining* about it! I suppose too much is never enough, eh? :-) So, my essential point is simply this: For the first time ever we have what previous computing generations could only dream about; powerful computers at a reasonable prices and a wonderful selection of things to run on them. Be happy, read the source code you're so privileged to now have available (*believe* me! What I wouldn't have given, even 5 years ago!) and spend your energy in making constructive use of it, not in arguing with the guys on the other side of the fence! Additionally, it should be said that none of the FreeBSD team has anything but the highest degree of respect for Linus Torvalds and his "team" of dedicated volunteers (and we occasionaly exchange gripe mail about the huge volume of messages each of us gets as a direct result of being insane enough to volunteer to do something like this :-). Our common commitment to the Intel platform also gives us more common ground (and interests) than one might think and, if anything, it's a pity that we do not endeavor to share more code and effort - ideologically, at least, I'd say we share pretty similar goals. As to which is "best", I have only one standard reply: Try them both, see for yourself, think for yourself. Both groups have given you something for free, at considerable personal effort, and the least you can do is give them the benefit of exerting enough effort to try what they're offering out before passing judgment (or worse, blindly accepting someone else's!). Whichever you run, you're getting a great deal - enjoy! Jordan Hubbard 0.2.3 Are all of the Berkeley derived systems binary compatible? If not, what are the differences? (Ed Note. This section is probably wrong, even if it was right when I looked at it last. There is a LOT of work going on, including SysV ELF support and other cool stuff.) NetBSD/386 runs 386BSD, FreeBSD, NetBSD/386 0.8, and most BSDI executables. However, due to upgrading to the latest version of the UCB DB library, programs which use said library cannot be mixed old and new; e.g. an old `ls' cannot read the pwd.db file created with a new `pwd_mkdb', and vice versa. FreeBSD runs 386BSD, NetBSD/386 0.8, and most BSDi executables. You can replace the remainder of the paragraph above here too. The FreeBSD and NetBSD shared libraries are different, so programs that are intended to be shared in binary form across the two platforms need to be compiled as 'static' implementations. This is not actually a guarantee that they will work across platforms, but this is the first hurdle that needs to be jumped in order to have the programs run. Also, due to better (read: properly) enforced address space protections, some incorrectly written programs which seemed to work under 386BSD or NetBSD/386 0.8 will core dump under NetBSD/386 0.9, even when recompiled. The default executable format produced by the NetBSD 0.9 `ld' i is not downward compatible with FreeBSD or 386BSD. It is essentially the same as BSDI's QMAGIC format and Sun's normal format--with no padding between the exec header and the first page of text, and with the first page of the address space always unmapped when loaded--except that the magic numbers are in the conventional `magic + machine id' format, and are in network (big-endian) order. 0.3 Are there any resources on the Net (like URLs) associated with the BSD family of operating systems? Yup: http://www.public.iastate.edu:~gendalia/FAQ/FAQ.list.html http://www.freebsd.org/ ftp://ftp.cdrom.com:/pub/FreeBSD/packages/WWW.tgz ftp://ftp.netbsd.org:pub/NetBSD/mailing-lists ftp://flick.lerc.nasa.gov:~ftp/pub/NetBSD/packages/1 ftp://ftp.iastate.edu:/pub/Netbsd/FAQ 0.4 How to add your pet answer to the FAQ. This is the trickiest part of this section of the FAQ. There are only two criteria for getting an entry made into the FAQ: 1. Your answer should answer a question that seems to come up with some regularity, or at least perplexes a group of people from time to time. 2. Your answer should be technically correct. In other words, answers like 'RTFM' and 'everybody knows that' are not really good candidates for the FAQ. These answers should spell out, in a reasonable level of detail, precisely how to fix the the question asked, or explain the basis for the answer and leave the implementation of the answer to the questioner. All answers MUST include a question. This is not as obvious as it would seem at first glance. An answer could solve many problems, especially in the realms of system halts or other catastrophes. Since I (Dave) am no Unix guru, I rely HEAVILY on the input of other people to make the FAQ a success. Many questions in the FAQ have been made largely irrelevant through the patchkits, but that doesn't means they may not reappear. That is why the old FAQ questions are still here. New FAQ questions should be added. I will try to attribute the question/answer to the author, but I personally think this is a waste of good disk space. As long as the answers get out, that should be reward enough :-) 0.5 Administrivia. Send all question/answer pairs to burgess@cynjut.infonet.net. If you are going to post the Q/A to the net, then do that, but be sure to mark it as a FAQ entry. I will get it from the net as easily as I do my E-Mail. Your Q/A will be formatted to look more or less like the others and be added. Corrections, deletions, flames, snivels, and whines should be addressed directly to me here. Either way, I will be sure to send out a reply letting you know what I have done with your submission. One last thing. I will assume that I am infalible. :-) I will not notice any mistakes that you may find. If you find a mistake and don't tell me, it will very likely stay a mistake. After all, if I didn't notice it before, why should I notice it now? -- TSgt Dave Burgess | Dave Burgess NCOIC, USSTRATCOM/J6844 | *BSD FAQ Maintainer Offutt AFB, NE | Burgess@s069.infonet.net From csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail Thu Apr 13 15:16:13 1995 Path: csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 1 of 10) Supersedes: <386bsd-faq-1-796287611@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 13 Apr 1995 01:00:10 -0500 Organization: Dave's House in Omaha Lines: 1292 Sender: burgess@cynjut.netins.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 05/01/95 01:00:08 CDT Message-ID: <386bsd-faq-1-797752808@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.netins.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:26 comp.unix.bsd.freebsd.announce:29 comp.answers:11169 news.answers:41785 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part1 Frequently Asked Questions 386BSD, NetBSD, FreeBSD, and other BSD derived Operating Systems. EXTREMELY UNOFFICIAL Original FAQ by: Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu New FAQ by: TSgt Dave Burgess NCOIC, Configuration Management Section, US Strategic Command Instructor, Computer Science Dept, Nebraska College of Business President, Configuration Management Svcs, Inc. burgess@s069.infonet.net burgess@cynjut.infonet.net Last Update: 26 Mar 1995 Section 0. (Basic FAQ information) 0.0 Master Index. #undef unix 0.0 Master Index. 0.1 Introduction 0.2 About this FAQ. 0.2a What are the differences between *BSD and (your favorite operating system name here)? 0.2b Which is better, (your favorite operating system name here) or *BSD? 0.2c Is 386bsd better than (your favorite operating system name here)? 0.2.1 So what ARE the differences between the *BSD family and Linux? 0.2.2 I want to start up a thread about why *BSD is or isn't as good as some other operating system. Can anyone suggest a good reason why I shouldn't? 0.2.3 Are all of the Berkeley derived systems binary compatible? If not, what are the differences? 0.3 Are there any resources on the Net (like URLs) associated with the BSD family of operating systems? 0.4 How to add your pet answer to the FAQ. 0.5 Administrivia. 1.0 What is 386BSD? (Taken from the original INSTALL.NOTES by the Jolitz's, specifically Lynne) 1.0.1 What are these other Free BSD systems? 1.0.2 I just downloaded all of 386bsd version 0.1 and I can't get [some feature] to work? Do you have any suggestions? 1.1 Feature summary 1.2 The future of 386BSD. 1.3 386BSD software projects in progress 1.3.1 Contacting software authors 1.4 Minimum hardware configuration recommended 1.5 Where to get the source and binaries 1.5.1 Forms available (floppy, FTP, CD-ROM) 1.5.1.1 Where can I get the distribution on floppy or tape? 1.5.1.2 Where can I get the distribution via FTP? 1.5.1.3 Where can I get the distribution on CD ROM? 1.6 Electronic Information Groups for 386BSD 1.6.1 Usenet newsgroups 1.6.2 Newsgroup archives. 1.6.3 386bsd Derived mailing lists. 1.6.4 Other electronic resources. 1.6.5 System Updates. 1.7 Documentation available 1.7.1 BSD manuals 1.7.2 BSD books 1.7.3 The Jolitz Book 1.7.4 Dr. Dobbs' journal 1.7.5 Documentation that comes with most of the distributions. 1.7.6 Other FAQ's on the net that are relevant 1.8 FTP sites for 386BSD 1.8.1 FTP Site List 1.8.2 Official distribution sites 1.8.3 Reference sites 1.8.4 Unofficial archive sites that have neat stuff! 1.8.5 X for 386BSD 0.1 Ported Software List 1.8.6 Motif for the *BSD family. (Infomercial to follow) 2.0 Install process 2.0.1 Boot disks (versions and media formats) 2.0.1.1 Where does extract go when I reboot? 2.0.1.2 I put the floppy in and try to boot, and nothing happens. What now? 2.0.1.3a The floppy booted, but now the hard disk won't boot? 2.0.1.3b I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk? 2.0.1.4 What are the options on the boot prompt? 2.0.1.5 I just used the '-s' option on the boot, but I can't write anything onto the disk. What is wrong? If I use a plain 'mount' command it tells me that my root file system is read-only. 2.0.2 Fix-it boot disk 2.1 Binary distribution 2.1.1 I want to install by NFS but I am having all kinds of problems. 2.2 Source distribution 2.3 Additional software distribution 2.4 Patch-kit 2.5 Configuration 2.5.1 Partitions 2.5.1.1 What is a 'disklabel' and why do I need one? 2.5.2 Common Disk Label Problems. 2.5.2.1 Swap space. 2.5.2.2 Increasing the 386bsd partition size. 2.5.2.3 I can access the DOS partition on my second disk from Unix but not DOS? Any suggestions? 2.5.3 How do I set up the system so that I can boot from more than one operating system/file-loader without using floppies? 2.5.4 How do I disklabel my second hard drive? 2.5.5 386bsd/NetBSD/FreeBSD cannot handle disk geometry translations, but it turns out that my disk geometry is translated. It has five zones, each with a different sec/track! What kind of things can I do about the disk translation my hard disk controller uses? 2.5.6 My disk label is complaining about '256 heads' in the disklabel. This is obviously bogus, but it doesn't seem to be hurting anything. Is it Okay or should I fix it? 2.5.7 What are the options for the bootup prompt? 2.5.8 I am having trouble installing WRT 'syslogd: bind: Can't assign requested address' errors. What are some of the things I should look at? I also am having trouble with the network: 'starting network ... ifconfig: localhost: badvalue'. 2.6 Common installation problems. 2.6.1 Swap space not identified correctly. 2.6.2 Endless reboot cycles. 2.7 The computer just sits there, or 'that isn't right'. 2.7.1 The boot disk works all right on one computer but not another. 2.7.2 Really strange errors in the various *BSD flavors. 2.7.2.1 I am using the original 386bsd 0.1 with no patches installed and I get flashing multicolored characters and a "ptdi 81061" prompt error? 2.7.2.2 Using the new code in NetBSD, I get a "panic: pdti 206067" in pmap_enter(). What should I do? 2.7.3a I get the error "isr 15 and error: isr 17" on an NE2000 card. 2.7.3b I have some card on IRQ2 and it doesn't work; why? 2.7.3c I am getting lousy performance out of my network card. What are some of the other possibilities? 2.7.4 What is the difference between IRQ2 and IRQ9? Are they really the same, or are they really different? 2.7.5 Some of my SCSI devices (like a tape drive) don't work; why? 2.7.6 I try to run 'ps' or 'w' and get ': cannot get namelist' from the TinyBSD kernel. What did I do wrong? 2.7.7 I get a 'Floating point constant out of range' when I try to compile package 'n'. What is broke? 2.7.8 I want to use the Adaptec 1542C SCSI controller. What are the problems/tricks you need to know to get it working? 2.7.9 My system boots OK off the floppy, but once I try to boot from the hard drive, the message "changing root device to sd0a" appears and the system hangs. What is the most likely thing that I have done wrong? 2.8 Other common problems that are attributed to the installation process but are caused other places. 2.8.1 Why don't the man pages for "magic" and "file" work? 2.8.2 Why is apropos broke? 2.8.3 I want to use more than 16 Megabytes of memory. Will any of the BSD based systems support it? 2.8.4 I tried to use a device in my computer that should be there. When I did, I got a "Device not configured error." What do I do now? 3.0 System Internals 3.1 Kernel 3.1.1 How do I build a kernel? 3.1.2 I want to do one of the following things: * add a device not in the distributed kernel (third com port, additional disk or tape, line printer driver, etc). * use a patch from the net or the patchkit to fix a kernel bug. * add another swap device. * recompile the kernel to remove extraneous devices so that it takes up less space. * configure more pseudo-terminals to allow for more xterms or network logins. 3.1.3 I don't have the source distribution -- how can I rebuild the kernel? 3.1.4 Now that I have a kernel, how do I install it? 3.1.5 After installing the patchkit and recompiling the kernel with the option "WD8013", I am no longer able to reboot the machine. A cold boot (power on) runs fine, but after a reboot no boot drive is found by the BIOS. Besides having a 16-bit WD/SMC Ethernet card installed the machines try to boot using either a Adaptec 1742 or 1542 SCSI board to boot from. 3.1.6 My system is complaining about stray interrupt 7. Is my machine going to explode or anything? 3.1.7 I keep getting "wd0c: extra interrupt". What does it mean? 3.1.8 I found a bug in the kernel. How do I report it? 3.1.9 Can someone please give a reasonably clear set of instructions as to how to get a "current" version of NetBSD running? 3.2 What exactly is this config file, anyway? What are all of these cryptic notations? 3.2.1 Okay, fine. Why shouldn't I just add every device I can find to the kernel, so I'll never have to recompile this again? 3.2.2 What should I remove from the kernel? 3.2.3 I can't get enough remote login sessions or xterm sessions. I also can only get four sessions working at a time. What can I do? 3.2.4 How do I get ddb, the kernel debugger, compiled into the kernel and running? 3.2.5 Can I patch the current running OS image? 3.2.6 Can I have more than one config file? Should I rename it to something else? Any other hints? 3.2.7 What is the meaning of the trap codes I get in panic messages? Sometimes this message appears in the form "trap type nn". 3.2.8 I have been getting a lot of "virtual memory exhausted" errors when I am compiling a program with a really big static array. I have 128Meg of memory and 8Gig of swap. How can this be happening? 3.2.9 Where can I learn more about all this? 3.2.10 Does anyone have a system building script that takes things like building a new config and multiple config files into account? 3.3 X11/XFree86/XS3 3.3.1 What options should I define to get the X extensions included? 3.3.2 Where can I get the FAQ for 'X'? 3.3.3 Why does X drop characters when using xdm? When I run xdm from the console, it keeps losing keystrokes and the shift keys don't always work. Why? 3.4 Compiler and Library routines 3.4.1 Which C compiler is shipped with my 386BSD derived system? 3.4.2 Where is libcompat.a? 3.5 You promised to talk about timezones below. Are you going to? 3.5.1 How do you change the timezone on NetBSD (FreeBSD also?)? 3.5.2 The translation between seconds-since-the-epoch and date differs by about 18 seconds between BSD and other Unixes when running ntp; why? 3.6 Optional Op-codes for NetBSD, FreeBSD, and other systems. 4.0 Introduction 4.1 Common Kernel-related problems 4.1.1 Where are the commands "rpcinfo" and "rpcgen"? 4.1.2 Where can I get a working "netstat"? 4.1.3 How can I fix NFS to work with my NE2000 board? 4.1.4 How can I get "ps" and "w" to work? 4.1.5 Where are re_comp and re_exec? 4.1.6 What about the termio, termios, and termcap stuff? 4.1.6.1 Where are stty() and gtty()? 4.1.6.2 Sometimes I have trouble with my system resetting the terminal to seven bit mode. Isn't 386BSD eight bit clean? 4.1.7 The system hangs with the HD light on after intense disk usage. The system hangs when trying to fsck -p both of my IDE hard drives at boot-up. 4.1.8 How do you implement quotas on Net/2 derived BSD systems? 4.2 Available kernel add-ons 4.2.1 The Patch-Kit 4.2.2 Shared Libraries 4.2.3 Sound Blaster Drivers 4.2.4 Bus Mouse Drivers 4.2.5 PPP Support 4.2.6 re_comp and re_exec library functions 4.2.7 Intel i82586 Ethernet Controller driver 4.2.8 PC Speaker driver for Nethack 4.3 Other program building type problems. 4.3.1 Greetings from Mars. I am building a program that requires access to the crypt library. Either I have it and it isn't getting copied into the executable, or I don't have it; why? 4.3.2 I am having trouble with long file names in my libraries. It seems like there is a 16 character limit in the library somewhere. 4.4 Where is the 'adduser' program? 5.0 Introduction 5.1 Available Kernel Replacements 5.1.1 keycap/codrv 5.1.2 pcvt 5.1.3 syscons 5.1.4 Fast Symbolic Links 5.1.5 npx fixes 5.1.6 CGD's COM drivers 5.1.7 The original 386bsd 0.1 wd.c driver doesn't work. [386bsd 0.1 only] 5.1.8 Interruptless LPT Driver Kit [386bsd 0.1 only] 5.1.9 A replacement curses program/library. 5.2 Floppy Disk problems. 5.2.1 How do I get a bootable floppy? 5.2.2 How do I maximize the space on a mountable floppy disk. 5.3 Character Device Driver info 5.3.1 Printers 5.3.2 Terminals/Keyboards 5.3.3 Modems 5.3.4 What is the trick for getting Kermit to work with rz and sz? 5.4 Tape Drives 5.4.1 Does the tape need to be formatted? 5.4.2 If I execute the command 'st -f /dev/st0 status', I get: Archive/Tandberg? tape drive, residual=0, blocksize=512 Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5) ds=0 er=0 5.4.3 When is erst0 used? 5.4.4 How is density (bpi) computed? I am using 3M DC 6250 cassettes which have a 250MB capacity on the Viper 150. But computing the bits/inch based on 250MB/tape-length (1020 ft.), I get a density of 171335 bpi, which is nowhere near the 10000 bpi associated with QIC-150 in the st(1) man page. Why the discrepancy? 5.4.5 How is an appropriate block size determined (and in what units are they specified in the st(1) command)? 5.4.6 From the 4.3BSD mtio(4) man page, it sounds like data is typically (traditionally?) stored on tape in eof-terminated sequences of 1K records. 5.4.6.1 Is st's notion of "file" the record sequence between two eof marks? 5.4.6.2 What about a "record"? 5.4.6.3 Is a "record" one "block", as determined by st's "blocksize" command? If not, what is the connection between them? 5.4.6.4 Can I change the "record" size? 5.4.6.5 When would I want a block size that is different from the default? 1KB is the size of writes used by dd or whatever. QIC specifies 512 byte records (well at least its what people use..) Whatever you write in will be broken into 512 byte sections. They must be multiples of 512 though. 5.4.7.1 How do I write several archives to a single tape? I tried without success: $ st -f /dev/rst4 rewind $ tar cf /dev/nst4 archive1 $ st -f /dev/nrst4 weof $ tar cf /dev/nst4 archive2 $ st -f /dev/nrst4 weof 5.4.7.2 Later, I would expect to be able to access, say, archive3 via the fsf directive to skip over the first two archives. What is the correct sequence? 5.4.8 Since the Viper 150 writes on QIC-150/120, I guess I don't need to worry about writing variable-length records? How about reading a tape written with variable-length records. Is this possible with the Viper? If so, what's involved? 5.4.9 The very scant documentation that came with my drive mentions a "selectable buffer disconnect size," whose default is 16K. This is evidently the "maximum number of bytes that can be sent over the SCSI bus during a single data transfer phase." What's that? How is it connected st's "blocksize" command? Do I want to use 16K blocks, or might I even want to set the disconnect size to a higher value? 5.4.10 What is "streaming"? When I tar a directory of files to tape, I notice that the tape often stops. Streaming means it doesn't stop? How would I get the viper 150 to stream using tar or cpio or dump? 5.4.11 Where are all the answers to the above and related questions written down? Neither on the net nor in the 4.3BSD manuals nor Administration text which I have could I find this stuff covered! 5.4.12 What else should I know? For example, it seems that a new tape must stretched. How is this done? 5.4.13 My tape drive doesn't work. 5.4.14 I am trying to restore a tape from a FreeBSD machine on a Sun. What kinds of problems should I expect? 5.5 Network 5.5.1 How can I get my system to work as a network router? 5.5.2 I recently has a problem where I got a message that said "panic: kmem_malloc: mb_map too small". What is the solution to this problem? 6.0 Working with DOS and BNR/2 related software. 6.1 Formatting a floppy 6.2 Sharing the Disk with MS-DOS 6.2.1 How can I partition my drive to support both MS-DOS and *bsd? 6.2.2 I can install using the whole disk, but I can't install when I try to share the drive between 386bsd and MS-DOS. Why? 6.2.3 I can use either MS-DOS or 386BSD on my hard drive, but shutdown -todos doesn't seem to work. 6.2.4 Is there any hope of ever running MS-DOS applications under any of the free BSD systems? 6.3 Accessing the MS-DOS filesystem 6.4 NFS/PC-NFS support 6.4.1 Can I use 8K packets for NFS? When I try, I have all kinds of problems. Specifically, I get 'ring buffer overflows' or the performance is real bad. 6.4.2 How do I get around the NFS "Permission denied" error? 6.4.3 What does the message "BAD MNT RPC: RPC Authentication error; why = Invalid client credential" mean when I try to mount something from another machine? 6.4.4 What does the message "Bad MNT RPC: RPC: Authentication error; why = Client credential too weak" mean when I try to mount something from another machine? 6.4.5 I get a lot of 'ring buffer overflow' messages using NFS and the ed0 driver. Is there a problem? 6.4.6 Is there any PC software that will allow me to use my enormous PC with all of the unsupported hardware as a PC-NFS server? 6.5 How can I use mtools with the 'new' floppy naming convention? 7.0 Communications 7.1 SLIP/CSLIP 7.2 PPP 7.3 TCP/IP 7.4 UUCP 7.4.1 TIP/CU 7.4.2 What is the magic incantation that allows the modem to dial? 7.4.3 My modem on DOS COM3 or DOS COM4 works with DOS, but not with *BSD. It is set up using IRQ 4 (or 3) respectively. 7.5 Terminals 7.6 My network manager (or UUCP feed site admin) just informed me that the way I have installed sendmail through my UUCP connection and has caused a sendmail loop. Can you help me get sendmail installed correctly? 7.7 Can network attached assets be used by/from NetBSD? 8.0 What hardware is 386BSD known to run on and support! 8.1 Video cards 8.2 Mice and Trackballs 8.3 Serial Cards 8.3.1 How do I configure multiport cards? Is there a possibility of using multiport serial boards? How do you configure an AST/4 in the kernel? It looks like the AST driver only supports 4-port cards, but it looks like it would be easy to add support for 8 ports ... or am I wrong? 8.3.2 Now that I have FreeBSD 1.0 installed, how do I set up the serial ports for bi-directional use? 8.3.3 What is the difference between baud and bits per second? 8.3.4 How do I get a serial console to work? 8.4 Disk Controller Problems 8.4.1 IDE controller problems 8.4.2 SCSI controller problems 8.5 SCSI Controllers 8.6 Network Cards 8.7 Printers 8.8 TAPE Drives 8.9 QIC-40/80 tape drives 8.10 CD-ROMs 9.0 What GNU software has been tested and is working with Net/2 derived BSD systems for the 386? 9.1 Has anyone ever gotten news to work? 9.2 How did you get emacs to compile? 9.2 Has anyone tried to get Postgres to work? 0.1 Introduction The 386BSD 0.1 operating system was originally a derivative of the generally available parts of the Berkeley Net/2 release. The definitive "man without whom we would have nothing" in this effort has been William Jolitz. For more information, download the code. 386BSD is fully redistributable and is intended as a research OS. As such, many contributions to the system are provided through interaction by people who communicate via many means. Many new and innovative features have been added to 386BSD since it's original release in June of '92. There was an 'unofficial' patchkit which was available from many anonymous FTP sources which makes 386BSD more stable and usable. Many problems associated with the use of 386BSD Version 0.1 were solved through the application of patches from the patchkit. In addition, many common Unix packages have been ported with varying degrees of difficulty. 386BSD is available completely free of charge. It is also available on CD-ROM and many other methods, most of which end up charging for 'media and handling costs'. It is available by Anonymous FTP and through FTP-Mail. Recently, a new CD-ROM version of 386BSD has been announced in Dr. Dobb's Journal. It may be the long awaited 386BSD 1.0, or simply a revenue enhancement version of 386BSD 0.1 (or 0.2). 386BSD came in three distinct pieces, each of which was exclusive of the other two. These distributions were called the 'bindist', 'srcdist', and 'etcdist'. The bindist could be unloaded from its native form (on about 10 diskettes) and loaded onto a 42Meg hard drive partition. It is a fully functional system, including gcc 1.39, all executables for normal Unix style operation, and many other things. The etc distribution included MANY additional programs (all with source) which extended the functionality of 386BSD. The srcdist was the source code for 386bsd, along with all of the header files not included in the bindist. All of the distributions and compilation files would fit onto 180Meg of hard drive (barely). In addition to the original 386BSD, two newer versions of the system are available, under new names. NetBSD is the older (or newer depending on whom you choose to believe) and FreeBSD is the other. Both systems have evolved into programs that are superior to the progenitor and both have sizable (if a little rabid) followings. Most of the statements made in this FAQ will apply to all three, although I will try to differentiate one from another whenever the difference matters. Any place that says 386bsd either means the original 386bsd 0.1 (you should be able to tell by context) of any of the three members of the PC BSD family. There have been many attempts to polarize the FreeBSD and NetBSD development groups in the past. One of the reasons that I am still maintaining the FAQ is that it simply is a good source for historical information, as well as a reasonable source for information that is specific to the implementations of NetBSD and FreeBSD. It should be noted that when the *BSD family started out, they used a source called the "Berkeley Net Release/2" tape as their genesis. While this has provided a stable starting point, it also built a possible bomb into the system. Due to an ongoing legal battle (which has now been resolved) the following files are identified as 'encumbered' in the BNR/2 source tree. These kernel files are identified as the 'binary only' files in the BSDI distribution, and either have been or must be replaced before we can have a truly free OS family. This is the pertinent excerpt from a letter from someone (whose name I have lost) indicating what is and is not releasable. Q: What's all this about `binary-only files'? Will BSDI continue to ship source code? A: For Version 1.1 only, BSDI will ship the following kernel files in binary format: kern/init_main.c kern/subr_rmap.c ufs/ufs_bmap.c kern/kern_clock.c kern/sys_generic.c ufs/ufs_disksubr.c kern/kern_exit.c kern/sys_process.c ufs/ufs_inode.c kern/kern_physio.c kern/tty.c ufs/ufs_vnops.c kern/kern_sig.c kern/tty_subr.c kern/kern_synch.c kern/vfs_syscalls.c Our (Berkeley's) 4.4Lite-based release will again include the entire source tree (with the exception of a tiny number of device drivers whose interfaces are kept confidential at the request of their authors. I have it from a reasonably reliable source that these files either have been completely rewritten in a 'clean room' development effort or were replaced with code from other sources (such as CMU, or GNU). The encumbered sources for the user land portion of the system have long since been replaced. 0.2 About this FAQ. This FAQ consists of 10 parts: Section 0. Basic FAQ information Section 1. General Network Information Section 2. Common installation questions Section 3. Kernel Building and Maintenance Section 4. Kernel Additions Section 5. Kernel Replacement Parts Section 6. Interaction with MS-DOS Section 7. System Communication Section 8. "Supported" Hardware List Section 9. "Supported" Software List It has been suggested that I remove some of the older, less relevant information from this FAQ. I have given it some thought, and I might. Of course, if someone were to do it for me, it sure wouldn't break my heart. 0.2a What are the differences between *BSD and (your favorite operating system name here)? 0.2b Which is better, (your favorite operating system name here) or *BSD? 0.2c Is 386bsd better than (your favorite operating system name here)? I decided to put this in section 0, primarily because it by far the most asked and least useful question in comp.os.386bsd.*. You will often see this question veiled as a request for a brief description of the differences between 386bsd and (YFOS). This type of request, while seeming to be a reasonable one, is usually looked upon as either an attempt by some folks for the net to do their homework, or as an attempt to start yet another flame-war. What is the answer to this question, then? No. It is not. Nor is it any worse. It is DIFFERENT. There are alternative Operating Systems available, both free and commercial. 386bsd, NetBSD, FreeBSD, and Linux are examples of "free" Unix style Operating Systems. If you ask any of these questions, you are wasting a LOT of bandwidth and making a real name for yourself. Don't bother. It nearly always ends up in name calling and 'mine is bigger (or littler) than yours...' arguments. I have included an excerpt below: >>>>>>>>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>>>> Is not! >>>>>>>>>>>>>>> Is so! >>>>>>>>>>>>>> Is not! >>>>>>>>>>>>> Is so! >>>>>>>>>>>> Is not! >>>>>>>>>>> Is so! >>>>>>>>>> Is not! >>>>>>>>> Is so! >>>>>>>> Is not! >>>>>>> Is so! [the rest of this scintillating debate is deleted...] Here are a brief list of differences between 386bsd and other systems: 1. *bsd will not run DOS applications natively. There is currently a DOS emulator in work. It is called pcemu, and it provides 8086 emulation for DOS programs. It only works in text mode. There is also work on a Windows program loader execution version. The project is called 'WINE' and is the free version of the 'WABI' project. More on that to follow. 2. 386bsd is not binary compatible with anything but the other free BSD systems (NetBSD, FreeBSD, and their kith). There are rumors and rumblings from time to time that one or more of the *Nix variants may be binary compatible with NetBSD or FreeBSD. The more the merrier. Be warned; if the package you are trying to run is not specifically compiled and linked for your version of {Free,Net}BSD, then you may well be completely on your own. Recent advances have provided some success in getting iBCS2 compatibility working, allowing certain SCO and AT&T Unix programs to work. See the newsgroups for more current information. 3. FreeBSD, which originally started life as 386bsd 0.1 with the patchkit applied, has since evolved into an entirely seperate BSD lineage in its own right and incorporates many important innovations. In addition to extensive, high quality work that has been done on the FreeBSD kernel, a great deal of effort and time has been invested in improving the overall level of quality in such areas as the installation and maintenance scripts, third-party applications packaging, and many of the various utilities and development tools in BSD. The emphasis seems to be on better packaging and improved operation, and with special emphasis being placed on positioning FreeBSD as an 'Intel-specific' BSD variant. Much care taken specifically to support the various and sundry peripherals and hardware one finds on the Intel PC world. FreeBSD is now based completely on the fully unencumbered BSD 4.4 Lite and is still intended primarily for the Intel platforms. 4. NetBSD, on the other hand, is intended as a multiplatform 'replacement' for Net2. It has built-in support for so many different platforms that I simply can't begin to list them. With the exception of the multiplatform support that is built into NetBSD, the two system are very similar and seem to parallel one another very closely. Since the NetBSD folks seem to be the self proclaimed 'bearers of the standard' for multi- platform BSD support, they are also proceeding with switching over to the 4.4 Lite tape. 5. Where BSD and POSIX differ, 386BSD conforms by default to BSD; Linux to POSIX. Furthermore, while both run mostly GNU utilities, Linux tends toward the SysV flavor (e.g. init) where 386BSD sticks with the BSD style. However, sources for different flavors of utilities are available for both, and both support compiler options which allow more BSD or more POSIX semantics. Clifford Stoll talks about the 'West Coast/East Coast' feeling of BSD/SysV in his book "The Cuckoo's Egg". In keeping with that, BSD feels like BSD/West Coast, Linux feels like SysV/East Coast (actually, Finland is what it says on the passport, but stay with me for a minute). If you don't believe me, just look at the primary U.S. archive sites. Linux is available from MIT, BSD is available from Berkeley. Can't get much more 'Coast' than that. :-) Actually, NetBSD and FreeBSD are feeling more and more POSIX all the time. Recent releases of both products have implemented many more POSIX compliant utilities, features, and low-level hooks into the operating system. A great deal of effort has gone into supporting and improving the POSIX standards compliance throughout all of the systems. 5. Linux, NetBSD, FreeBSD, and 386bsd share two vitally important facets. All are free and all include source. They are all excellent, and all fill a niche that the others would gladly leave available. Also, don't forget one of the most important things; get what your friends have. Then they can help you. 6. Finally, remember that this FAQ and the comp.os.386bsd.* groups are intended as places for 386bsd users and developers to meet and discuss topics which are germain to the further development of 386bsd. For more information about Linux, you can read the comp.os.linux.* newsgroups. If you are a 'rabid' Linux user, stay on the Linux groups. Most of us don't care how much better Linux is than *BSD. 0.2.1 So what ARE the differences between the *BSD family and Linux? Here it is, in its 'right for today' glory. As of 1 July, 1994, these statements were more or less accurate. Against my better judgement, I am going to include this, primarily because it is a very even handed approach to describing two very different systems. For those of you that find it, I hope that it answers some of your questions. It was written by: Thomas Heiling Pharmacist & Doctorate at Pharmazeutisches Institut Uni Wuerzburg - Germany Email phar006@rzbox.uni-wuerzburg.de (HP-UX) tom@wpzd07.pzlc.uni-wuerzburg.de (Linux) or phar006@vax.rz.uni-wuerzburg.de ( VAX ) I have read this group now for some time and saw this thread Linux-BSD coming often. Some answers to this question were good, but the FAQ was not updated. It is IMHO *not* very helpful to flame a newbie, that he/she should read the FAQ, where there is no information, nor it is helpful to shout to him "Hey man read the previos posts - I *hate* this thread!" What is missing here is an overview and a comparison of the free available Unixsystems. And this info should be in the FAQ ! I will start here such a comparison. Q: For whom should this be ? A: For a (hopefully) new Unix-user, who wants to install one of the free Unixes. He should be able to read this document, look at his hardware, define his needs for a Unix-systems and then he should be able to choose a system which meets his needs. Q: Who am I and why should I be able to write such a doc ? A: Good Question ! My name is Thomas Heiling, I am working at the University of Wuerzburg in Germany as a doctorate. My job is to program an Ultraviolett/Vis-spectrum comparison program. Furthermore I am the person, who maintains the Internet connections and computers of our Department. I have running Linux and NetBSD 0.9, the main Server is a 486/33 + 16 MB which runs Linux. A 486/66 is for numerical work. Then there are some clients mostly 386 with either 4 MB or 8 MB. One 386 with NetBSD, but this is just for testing. So I would say I can speak for Linux, a little bit for NetBSD and I have no idea for FreeBSD beside the Installation Guide. (I have no access to the BSD386 1.0 CD, which was announced some time ago). * PLEASE PLEASE PLEASE * It would be very helpful, if someone of the Core-Team of NetBSD and/or FreeBSD have a look at this and fill the white spaces, which I left. And if the FAQ-maintainer reads this, it would be nice, if he thinks this info should be in the FAQ. Hardware requirements : Linux: CPU: Anything that runs 386 protected mode programs (all models of 386s and 486s should work; 286s don't work, and never will). Architecture: ISA or EISA bus. MCA (mostly true blue PS/2's) does not work. Local busses (VLB and PCI) work. RAM: Theoretically up to 1 GB. This has not been tested. Some people (including Linus) have noted that adding ram has slowed down their machine extremely without adding more cache at the same time, so if you add memory and find your machine slower, try adding more cache. Data storage: Generic AT drives (IDE, 16 bit HD controllers with MFM or RLL) are supported, as are SCSI hard disks and CD-ROMs, with a supported SCSI adaptor. Generic XT controllers (8 bit controllers with MFM or RLL) are now also supported. Supported SCSI adaptors: Adaptec 1542, 1522, and 1740 in extended (not 1542 compatible) mode, Seagate ST-01 and ST-02, Future Domain TMC-88x series (or any board based on the TMC950 chip) and TMC1660/1680, Ultrastor 14F, 24F and 34F, and Western Digital wd7000. SCSI and QIC-02 tapes are also supported. Support for QIC-80 tapes is now in ALPHA testing. Several CD-ROM devices are also supported, including Matsushita/Panasonic, non-EIDE Mitsumi, Sony, Soundblaster, Toshiba, and others. Video: VGA, EGA, CGA, or Hercules (and compatibles) work in text mode. For graphics and X, there is support for (at least) normal VGA, some super-VGA cards (most of the cards based on ET3000, ET4000, Paradise, and some Trident chipsets), S3 (except for Diamond Stealth cards, because the manufacturer won't tell how to program it), 8514/A, ATI MACH8, ATI MACH32, and hercules. (Linux uses the Xfree86 X server, so that determines what cards are supported.) Networking: Western Digital 80x3, ne1000, ne2000, 3com503, 3com509, Allied Telliesis AT1500 (said to be some of the fastest, as well as quite cheap), d-link pocket adaptors, SLIP, CSLIP, PLIP (Parallel Link IP), and more I have forgotten at the moment. Other hardware: SoundBlaster, ProAudio Spectrum 16, Gravis Ultrasound, AST Fourport cards (with 4 serial ports), several models of Boca serial boards, the Usenet Serial Card II, several flavours of bus mice (Microsoft, Logitech, PS/2). *BSD: Architecture: ISA or EISA bus. MCA (mostly true blue PS/2's) does not work. Local busses (VLB and PCI) are also supported. Standard hard disk controllers: MFM ESDI IDE RLL SCSI hard disk controllers: Adaptec 154x *, Adaptec 174x, Buslogic 545S, Bustek 742(EISA) DTC 3290 in 1542 emulation mode *, Ultrastor 14f and 34f, and the 24f experimentally. The Soundblaster SCSI code is also being tested and should work eventually. Display Adaptors : MDA,CGA,VGA,HGC for textmode. For X the same as Linux. Serial Communications: 8250,16450,16550A, 4-port multi-serial cards require a kernel rebuild. Ethernet controllers: SMC/WD 8003, 8013 and equivalents ( including SMC Elite ) Novell NE1000,NE2000,NE2100 3com 3c503 ISOLAN ISOlink Tape Drives: QIC-02 format tape drives QIC-36 format tape drives QIC-80 format tape drives (in FreeBSD) most SCSI tape/DAT drives on a supported SCSI controller CD-ROM drives: Mitsumi CDROM with Mitsumi Controller (not EIDE) Most SCSI CD-ROM drives on a supported SCSI controller Other hardware: SoundBlaster, ProAudio Spectrum 16, Gravis Ultrasound, AST Fourport cards (with 4 serial ports), several models of Boca serial boards, the Usenet Serial Card II, several flavours of bus mice (Microsoft, Logitech, PS/2). Same as Linux, although some options may require a kernel rebuild. Harddisk Storage requirements : FreeBSD: Base System 16 MB Full binary distribution 46 MB Full source " 72 MB Kernel Source 7 MB Swap 8 MB They say, that the minimum is Base + Binary + Swap, and that this minimum is 80 MB. For a complete system with binary and source you need at least 210 MB. This does NOT include X or LaTeX. Linux: This is difficult, because there are different distributions to choose from. Every distribution has a special goal. I will show two popular distributions : - Slackware and the MCC-Interim Distribution. Slackware is intended for a full fledge system, which has everything you want. You need about 150 MB for this. - MCC-Interim is intended for small systems. The main idea is to give a ASCII-environment for programming courses. For a full MCC install you need about 47 MB + 8 MB Swap, you can strip this down to 23 MB + 8 MB Swap, if you don't want emacs, no kernel source and no extras. Some other features: virtual terminals/consoles: All of the -current versions of *BSD have virtualy consoles available. Linux has virtual consoles as well. shared libraries: NetBSD, FreeBSD, and Linux have it. I recall a thread some time ago, which was something like "Linux shared Libs are no good - A pain for the developer." For the user this should be meaningless. NetBSD and FreeBSD shared library implementations are both very easy to use both from the developer and user point of view. Networking: *BSD networking is more mature, but with Linux 1.0 it's getting closer. One Feature of Linux is the ability to make a filesystem on top of a DOS-FAT, so you don't need to repartition your Disk. This Filesystem is of course not so fast as a native Filesystem, but for trial it should be O.K. Conclusion: It depends on you hardware and what you want to do with your system. If your hardware is supported and if you have the resources and if you are on the net, I would vote for *BSD. If you just want some *iX experience and have low ressources, choose Linux. Here are some pro's and con's for both : *BSD: + Full Source Code of all commands in a source tree, no need to look all over the Internet for the source of a command. + There is only one distribution, which is valid for some time. + Networking is better. + The system is standard BSD. - You need extra packages for XFree and for TeX. They are not hard to find, and install into a standard location in the directory tree, but they are not included in the base distribution. Linux: + Uses fewer resources + Has more support for devices - Every distribution is a little bit different - Development is too fast without net access I include here some info from other posts, which should help the new user to show the differences: burgess@cynjut.infonet.net wrote: : NetBSD is the OS I use. It is a BSD derived Operating System : that has a very stable operating envelope. The networking code : has been stolen by commercial OS and network vendors the world : over. NetBSD has the advantage of being meant for a wide : range of hardware platforms. It is currently available for : something like 10 different CPUs, and has been laid out such : that new architectures can be added relatively painlessly. These arechitetures include several Sun Systems, many Motorolas, including the Amiga and Mac, and several other older mini- and microcomputer systems. : : FreeBSD is pretty much the same (go ahead a quibble over : details, I don't care anymore). The biggest difference is that : NetBSD is a horizontal system (across platforms) and FreeBSD is : a vertical system (intended to stay on the Intel family). Both : are based on code from 386BSD, although neither really resembles : it any more. : : Linux was developed by Linus Torvalds and has the advantage of : being available in source code form first. Other than that, I : have heard that it is a good OS platform for standalone Unix : workstations. It had a lot of things that made its users rabid : before the *BSD folks did, but the purists insist that *BSD is : (choose two: cleaner, safer, taller, wider, better, quieter, : louder, greener). I even heard a rumor that Linus had sold the : source code license to Novell so that they could distribute an : 'X' terminal package for use in their networks. From: hedrick@geneva.rutgers.edu (Charles Hedrick) There are four major differences: 1) the 386BSD family started with BSD, and Linux started with POSIX. NetBSD/FreeBSD/386BSD have been adding POSIX and System V compatibility, and Linux has been adding Berkeley and System V compatibility. So there's a good deal of overlap. But ...BSD is still a better choice if you want to program in a Berkeley environment and Linux if you want a POSIX environment. That's for the kernel and libc -- the utilities and other stuff users see tends to be fairly similar. In both cases the programs are what I call "typical University Unix". The main difference is that the base Unix utilities tend to be Berkeley for ...BSD and Gnu for Linux. Gnu is fairly Berkeley-compatible, but its priority is POSIX, so it tends to look slightly closer to System V, with massive Berkeley extension. There are several sets of administrative utilities, but it's more likely that init, getty, etc., are going to be System V style for Linux and BSD for ...BSD. Again, these things aren't as significant as they might be because ...BSD is also concerned about POSIX compatibility and Gnu is concerned about BSD compatibility. So both sets of software are approaching a similar sort of goal from opposite directions. You could probably use the systems for quite a while without noticing much difference. (I'd like to emphasize that there's no similarity in overall feel between Linux and typical brain-dead PC System V ports.) The ...BSD FAQ characterizes the difference as one of East Coast vs. West Coast. There's a lot to be said for that summary. There's more difference in Unix culture between New Jersey and California than between New Jersey and Finland. 2) The nature of the development communities and distribution mechanisms are different. ...BSD has two or three different developer communities that take code from each other, but appear to hate each other's guts. (Actually, even ...BSD and Linux take code from each other.) Thus there are several different ...BSD's, each of which has an official distribution. There's just one Linux kernel, and from a practical point of view just one set of major utilities, but there's no official distribution. So several different groups put together distributions, with their own choice of kernel and utility versions. This means that it's easier to define what the One True Linux is than what the One True BSD is, but harder to get it. Once you've decided which BSD is the right one, it's easier to find an authoritative distribution of it. Development of Linux tends to be more distributed. Lots of people are working on lots of projects: new drivers for this and that, new versions of this utility and that. If you want to keep up with NetBSD, you can sup netBSD-current from one or two places. If you want to keep up with Linux, you end up taking pieces from lots of people (though they generally end up on one of two archive machines -- tsx-11.mit.edu or sunsite.unc.edu). If you don't want to do this, of course the packaged distributions do it for you. 3) The BSD networking is more mature than the Linux networking. This is one area in which I don't think Linux has any countervailing advantages, though in my opinion by release 1.0 Linux networking will be acceptable. 4) There are specific things in each system that are likely to be deciding factors for some people. I don't know what unique things BSD has, because I'm not part of that community, but for some people the COFF and ELF compatiblity projects may be big selling points. Both ...BSD and Linux are working towards having these executable formats available. In addition, Windows executable emulation may also be important to some people. This is probably more useful, and it's being done jointly by developers from both BSD and Linux cooperatively. (Neither of these things is finished, by the way.) It's not clear to me whether the existing Linux DOS compatibility is a critical advantage. BSD doesn't have it, but my experience is that the Linux DOS emulator is slow enough and creaky enough that it's not generally usable. However it certainly does work for many programs, and if one of those programs is critical to you, it may be a big deal. Differences in support of devices are not likely to persist for long. There's a history of taking device drivers in both directions, so if there's enough interest in a device, and one side implements it, you can bet it will show up on the other side. Linux uses DOS partitions (including extended partitions). BSD creates its own partitions inside a single DOS partition. This is a difference, but it's unclear whether it's a critical one. Linux and ...BSD can all mount DOS filesystems and Linux can mount OS/2 file systems (OS/2 is read-only). For a lot of people, the best suggestion is to find out what your friends are doing. If there's a significant user community near you of either kind, you're probably best off to go with it. If not, flip a coin (or look at a map and see whether you're nearer Berkeley or Finland -- note that in this comparison portions of the distance that are over an ocean don't count). 0.2.2 I want to start up a thread about why *BSD is or isn't as good as some other operating system. Can anyone suggest a good reason why I shouldn't? Jordan Hubbard, one of the FreeBSD core team members, has offered this missive on that very subject: [ Note: You could very well simply substitute the word "NetBSD" for Linux in the argument that follows ] From time to time, a thread in both the comp.os.386bsd.misc and comp.os.linux.misc groups flares up regarding which operating system is "better", FreeBSD or Linux. This generally provokes controversy from users on both sides, with one group claiming that their OS is "better" for some reason and the other group claiming that the first group doesn't know what the heck it's talking about. Both arguments are a waste of time. Rather than trying to win a rather questionable debate on relative (and constantly changing) technical merits, we should be asking ourselves what both groups are REALLY about and what they represent. This is naturally going to be a matter of personal opinion, but I believe even the most seriously at-odds members would agree that both operating systems represent a unique and long-awaited opportunity: The ability to run a fully featured operating system on popular, easily affordable hardware and for which all source code is freely available. Those who have been in computing for awhile will remember when the term `operating system' referred almost exclusively to something provided solely by the hardware vendor, with very little in the way of alternative options. It was never EVER given out with source code, and true "wizard" status could only be achieved by exerting mind-numbing amounts of effort and patience in digging through forbidden bits of binary data. By comparison, the situation today seems almost too good to be true! Certainly, the feeling of achievement that came from finally ferreting out some esoteric bit of information from a 4MB printed system dump was high, but I don't think that anyone would argue that it was hardly the most optimal way of truly getting to know your operating system! :-) So now, within a very short space of time, we're almost spoiled for choice in having machines several times more powerful than the first multi-user VAX machines and available for under $2000, and we've got not one but SEVERAL perfectly reasonable free operating systems to chose from. We are in a comparative paradise, and what are some of us doing? *Complaining* about it! I suppose too much is never enough, eh? :-) So, my essential point is simply this: For the first time ever we have what previous computing generations could only dream about; powerful computers at a reasonable prices and a wonderful selection of things to run on them. Be happy, read the source code you're so privileged to now have available (*believe* me! What I wouldn't have given, even 5 years ago!) and spend your energy in making constructive use of it, not in arguing with the guys on the other side of the fence! Additionally, it should be said that none of the FreeBSD team has anything but the highest degree of respect for Linus Torvalds and his "team" of dedicated volunteers (and we occasionaly exchange gripe mail about the huge volume of messages each of us gets as a direct result of being insane enough to volunteer to do something like this :-). Our common commitment to the Intel platform also gives us more common ground (and interests) than one might think and, if anything, it's a pity that we do not endeavor to share more code and effort - ideologically, at least, I'd say we share pretty similar goals. As to which is "best", I have only one standard reply: Try them both, see for yourself, think for yourself. Both groups have given you something for free, at considerable personal effort, and the least you can do is give them the benefit of exerting enough effort to try what they're offering out before passing judgment (or worse, blindly accepting someone else's!). Whichever you run, you're getting a great deal - enjoy! Jordan Hubbard 0.2.3 Are all of the Berkeley derived systems binary compatible? If not, what are the differences? (Ed Note. This section is probably wrong, even if it was right when I looked at it last. There is a LOT of work going on, including SysV ELF support and other cool stuff.) NetBSD/386 runs 386BSD, FreeBSD, NetBSD/386 0.8, and most BSDI executables. However, due to upgrading to the latest version of the UCB DB library, programs which use said library cannot be mixed old and new; e.g. an old `ls' cannot read the pwd.db file created with a new `pwd_mkdb', and vice versa. FreeBSD runs 386BSD, NetBSD/386 0.8, and most BSDi executables. You can replace the remainder of the paragraph above here too. The FreeBSD and NetBSD shared libraries are different, so programs that are intended to be shared in binary form across the two platforms need to be compiled as 'static' implementations. This is not actually a guarantee that they will work across platforms, but this is the first hurdle that needs to be jumped in order to have the programs run. Also, due to better (read: properly) enforced address space protections, some incorrectly written programs which seemed to work under 386BSD or NetBSD/386 0.8 will core dump under NetBSD/386 0.9, even when recompiled. The default executable format produced by the NetBSD 0.9 `ld' i is not downward compatible with FreeBSD or 386BSD. It is essentially the same as BSDI's QMAGIC format and Sun's normal format--with no padding between the exec header and the first page of text, and with the first page of the address space always unmapped when loaded--except that the magic numbers are in the conventional `magic + machine id' format, and are in network (big-endian) order. 0.3 Are there any resources on the Net (like URLs) associated with the BSD family of operating systems? Yup: http://www.public.iastate.edu:~gendalia/FAQ/FAQ.list.html http://www.freebsd.org/ ftp://ftp.cdrom.com:/pub/FreeBSD/packages/WWW.tgz ftp://ftp.netbsd.org:pub/NetBSD/mailing-lists ftp://flick.lerc.nasa.gov:~ftp/pub/NetBSD/packages/1 ftp://ftp.iastate.edu:/pub/Netbsd/FAQ 0.4 How to add your pet answer to the FAQ. This is the trickiest part of this section of the FAQ. There are only two criteria for getting an entry made into the FAQ: 1. Your answer should answer a question that seems to come up with some regularity, or at least perplexes a group of people from time to time. 2. Your answer should be technically correct. In other words, answers like 'RTFM' and 'everybody knows that' are not really good candidates for the FAQ. These answers should spell out, in a reasonable level of detail, precisely how to fix the the question asked, or explain the basis for the answer and leave the implementation of the answer to the questioner. All answers MUST include a question. This is not as obvious as it would seem at first glance. An answer could solve many problems, especially in the realms of system halts or other catastrophes. Since I (Dave) am no Unix guru, I rely HEAVILY on the input of other people to make the FAQ a success. Many questions in the FAQ have been made largely irrelevant through the patchkits, but that doesn't means they may not reappear. That is why the old FAQ questions are still here. New FAQ questions should be added. I will try to attribute the question/answer to the author, but I personally think this is a waste of good disk space. As long as the answers get out, that should be reward enough :-) 0.5 Administrivia. Send all question/answer pairs to burgess@cynjut.infonet.net. If you are going to post the Q/A to the net, then do that, but be sure to mark it as a FAQ entry. I will get it from the net as easily as I do my E-Mail. Your Q/A will be formatted to look more or less like the others and be added. Corrections, deletions, flames, snivels, and whines should be addressed directly to me here. Either way, I will be sure to send out a reply letting you know what I have done with your submission. One last thing. I will assume that I am infalible. :-) I will not notice any mistakes that you may find. If you find a mistake and don't tell me, it will very likely stay a mistake. After all, if I didn't notice it before, why should I notice it now? -- Dave Burgess (The man of a thousand E-Mail addresses) 386bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom "Just because something is stupid doesn't mean that there isn't someone that wants to do it...." From csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail Thu Apr 13 15:16:15 1995 Path: csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 2 of 10) Supersedes: <386bsd-faq-2-795078010@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 27 Mar 1995 01:00:19 -0600 Organization: Dave's House in Omaha Lines: 1308 Sender: burgess@cynjut.infonet.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 04/14/95 02:00:10 CDT Message-ID: <386bsd-faq-2-796287611@s069.netins.net> References: <386bsd-faq-1-796287611@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.infonet.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:15 comp.unix.bsd.freebsd.announce:14 comp.answers:10851 news.answers:40661 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part2 Section 1. (General Network Information) General information This section of the FAQ is about the electronic support network that exists for 386bsd and its off-spring. 1.0 What is 386BSD? (Taken from the original INSTALL.NOTES by the Jolitz's, specifically Lynne) Welcome to 386BSD Release 0.1, the second edition of the 386BSD operating system created by William and Lynne Jolitz. Like its predecessor, 386BSD Release 0.0, Release 0.1 comprises an entire and complete UNIX-like operating system for the 80386/80486-based AT Personal Computer. 386BSD Release 0.1 is an enhanced version of the original release done by William F. Jolitz, the developer of 386BSD. 386BSD Release 0.0 was based on the Networking Software, Release 2 from the University of California at Berkeley EECS Department, and included much of the 386BSD work done earlier by Bill and contributed by us to the University. The latest release, 386BSD Release 0.1, contains new work by the developer and many new items which have been freely contributed by other software developers for incorporation into 386BSD (see the file CONTRIB.LIST). These contributions have increased the functionality and made it more robust. As a courtesy to the developer and the many people who have generously contributed these software enhancements, we request that users abide by and properly maintain all attributions, copyrights, and copylefts contained within this release. 386BSD is intended to foster new research and development in operating systems and networking technology by providing this base technology in a broadly accessible manner. As such, like its predecessor, 386BSD Release 0.1 is freely redistributable and modifiable. 1.0.1 What are these other Free BSD systems? For reasons best left to private E-Mail, there have been two different 'product lines' that have been established for development of BSD systems. They are NetBSD and FreeBSD. Both, individually, have virtually deprecated the original 386bsd. The "raison d'etre" for each is different and each has a different set of goals. The purpose for FreeBSD is to develop a stable working environment for [3-9]86 systems. The emphasis has been on upgrading utility programs and incorporating changes that make the system more stable. NetBSD, on the other hand, is a development effort whose main thrust is on mulitple platform support and staying more current with BSD 4.4. In other words, NetBSD is more 'horizontal' and FreeBSD is more 'vertical'. Both systems are excellent choices for the casual user or people who are interested in studying the internals of an operating system. While the products are nearly commercial quality, they are both maintained by volunteers. 1.0.2 I just downloaded all of 386bsd version 0.1 and I can't get [some feature] to work? Do you have any suggestions? Yes. Get either FreeBSD or NetBSD. The original 386BSD software was kind of buggy when it was put up for anonymous FTP in 1992. It has been modified significantly since then, and now exists in two different forms. There are people who will argue that the original 386BSD was completely unusable, but that is generally an overstatement. Over 100 patches were applied to the original system, with hundreds more waiting in the wings. It became just too much trouble to constantly have to patch the system to get it to work. This 'patched' version of 386bsd became FreeBSD. Around the same time, a second group split off from the original 386bsd tree and became NetBSD. For the primary differences, see above. Getting one of these two systems will provide you with a more complete system, with newer utilities, and many bugs already fixed. 1.1 Feature summary Among the many features of these systems: * Floppy disk based Installation * Hard drive partitioning for use with MS-DOS partitions * Compressed, multivolume CPIO dump format binary/source/other distribution sets on MS-DOS floppies. The cpio is based on the GNU cpio, and is completely free of encumbering USL software. * 387 support or emulation. * SCSI support. * (SCSI and most non-EIDE Mitsumi) CD-ROM support. * NFS, TCP/IP and full networking. * MS-DOS file system access (in newer *BSD systems). * PPP and SLIP protocol support. * System upgrades through Carnegie Mellon University's 'sup' utility. * Shared Library Support (in the newer version of both NetBSD and FreeBSD. * Both systems are based exclusively on Berkeley's BSD 4.4 Lite tape, instead of the encumbered 4.3 Net2 tape. Hence, both systems are free of encumbered USL code and are freely redistributable. 1.2 The future of 386BSD. { This section is included for historical purposes only. Most of the information in here is either wildly out of date or just plain wrong. For example, the FreeBSD statements in here imply that it is nothing more than 386bsd in a new coat of paint. Nothing could be further from the truth. I decided to include it mostly to show how far we have come... dbb } Forecasting the future is always a tricky business. There is work underway to implement version 0.2 of 386bsd. In addition, many people are involved in a project to put together a 386bsd version (FreeBSD) which will be a complete distribution set including all relevant patches and updates to new versions of many of the software packages that are currently available. It is available by anonymous FTP from FreeBSD.cdrom.com In addition, NetBSD (a direct descendent of 386bsd) is available for anonymous FTP from sun-lamp.cs.berkeley.edu. The purposes of these two apparent competitors appear to be at odds, but in fact are very similar. NetBSD has taken a 'stable, production quality, free OS' as one of its primary goals, where 386bsd pursues the high ideal of the ultimate OS research platform. There is considerable cross pollination of the two. The frequent debates on style and concept that appear in comp.os.386bsd.* are testimony to that point. NetBSD and FreeBSD are still both very viable operating system alternatives, with differing goals. To see the Future of 386bsd as seen by Bill and Lynne Jolitz, I suggest you read the INSTALL.NOTES that come with 386bsd. 1.3 386BSD software projects in progress The list of software projects in progress is just too volatile to go into a static document like the FAQ. Suffice it to say, if there is something you want to do using 386bsd; ask first to see what has been done. Folks that are interested in software projects for NetBSD should contact netbsd-comments@sun-lamp.cs.berkeley.edu and let that mailing list know the same information. Folks interested in software projects for FreeBSD should contact the freebsd-hackers@freefall.cdrom.com mailing list and talk to them. 1.3.1 Contacting software authors Whenever you are working on a port of a software package, it is always a good idea to contact the original author and offer whatever changes you needed to make in order to port the software. That way, subsequent releases of the package may include changes that allow all users of 386bsd the advantage of reusing your work over and over. Also, once you have ported a package to *BSD, you might want to contact the respective *BSD teams to let them know you've completed it and where it may be located. For FreeBSD, contact: For NetBSD, contact: If the port was a simple recompile of the source and install, a note to one of the newsgroups telling the story could be considered appropriate as well. In keeping with that, if you find a 'bug' in 386bsd, or NetBSD, or FreeBSD, or find a problem that causes you some headaches and find a solution, you should contact the author of the particular driver/module/program and let them know. In addition, you could also post the problem and/or fix to "comp.os.386bsd.bugs". Both NetBSD and FreeBSD have implemented 'bugfiler', so if you are connected to the net, you can use that to send out your bug. See the documentation that comes with your system to find out more. 1.4 Minimum hardware configuration recommended There has been considerable debate about what the REAL minimum configuration for 386bsd is. Some would claim that it is the smallest computer that an installation will succeed on. Others claim that it is the smallest usable computer (based on RAM and speed constraints) and others would claim that it should be based on using 'X'-windows. For specific hardware, see Section 8 (still in development). The smallest installable platform is an 80386, using an MGA card, with at least 2Meg of RAM and a 20 Megabyte hard disk. While not all SCSI cards (especially EISA) are supported, a great many are either in the base distribution or through patches. Thanks to the new shared library code in FreeBSD and NetBSD, a 20Meg installation should be easier now (in spite of the more advanced functionality) than it ever was before. A comfortable installation which includes source and binary distributions, as well as other utilities will work in about 100Meg of hard drive. 'X' requires at least a Hercules MGA; for masochists only, from what I understand. See section 8 for more details. 1.5 Where to get the source and binaries 1.5.1 Forms available (floppy, FTP, CD-ROM) 386bsd is available in just about every format known to man, with the possible exception of stone tablets and papyrus. 1.5.1.1 Where can I get the distribution on floppy or tape? Many people will copy files onto diskettes or tapes if you coordinate it with them ahead of time. In addition, many companies offer 386bsd on various types of media for money. Austin Code Works and others (usually advertisers in PC magazines) offer the base 0.1 "official" distribution for a fee. Note that there are virtually no restrictions on distributing the 386bsd distributions. Basically, wherever you can find it, you can get it. This goes for FreeBSD and NetBSD as well. 1.5.1.2 Where can I get the distribution via FTP? If you are looking for the original 386bsd version 0.1, the files you should look for specifically when using FTP are directories called srcdist, bindist, and etcdist. These directories will hold the files for each of the distributions. Once you have received the files via FTP, you can either load them directly onto your system and then un archive them using 'extract' or one of the other methods suggested in Section 2 of the FAQ, in the section about installing with 'real partitioning'. The list of sites that have 386BSD is covered in section 1.8 below. This list is produced automatically by using a utility called 'archie' and is updated for every new version of the FAQ. If you try to access a site from this list and find that they either don't have FTP enabled, or don't have 386bsd loaded any more, a polite letter to the admin of the system asking them to update their 'archie' entries is good manners. 1.5.1.3 Where can I get the distribution on CD ROM? Infomagic sells a UNIX CD-ROM that has 386BSD. Their FAX number is 609-683-5502. In a new joint venture, DiscNet, Inc., and InfoMagic, Inc. are pleased to announce their joint release of the BSDisc. This collaboration should be beneficial to all of our customers, since it brings to bear more experience, more support capability, and economies of scale in production. The BSDisc (Vol 2, Num 1) is scheduled to begin shipping on the 20th of December, 1994. Available now for over a year, the BSDisc seeks to provide what BSD users and hackers want most on a CD-ROM. The current issue includes: - NetBSD 1.0 - distribution sets for 1, sparc, mac68k, and amiga - expanded source tree for all architectures - FreeBSD 2.0 - distribution sets for 1 - expanded source and binary trees for 1 - XFree86 binaries for both FreeBSD and NetBSD - X11R6 (xc as well as contrib) - BSD-related news archive - various Answers to Frequently asked Question (FAQs) - Lots of Freeware/Gnuware sources from the FreeBSD Ports effort - FreeBSD pre-built binary packages - a small set of pre-built NetBSD binary packages The BSDisc is available both for single-issue purchases, or on a buying plan. Single-issue price is $35.00; subscription pricing is $19.50 per issue, for a minimum length of 3 issues. (Those prices do not include S/H.) For single-issue purchases, contact InfoMagic at: +1-800-800-6613 InfoMagic, Inc. Tel: +1-602-526-9565 PO Box 30370 Fax: +1-602-526-9573 Flagstaff, AZ 86003-0370 e-mail: orders@Infomagic.com info@infomagic.com For information about subscriptions, contact DiscNet at: DiscNet, Inc. +1-608-846-9838 841 Acker Pkwy DeForest, WI 53532 email: bsdisc-info@grilled.cs.wisc.edu bsdisc-orders@grilled.cs.wisc.edu European subscriptions, email: bsdisc@altona.ppp.net Profit Press has 386BSD dated 7/21/92 on their "Mega Win OS/2" CD-ROM. This is in the format of BINDIST, ETCDIST, SRCDIST and BOOTABLE. Profit Press 2956 N. Campbell Ave Tucson, Arizona 85719 (602) 577-9696 Their order line is 1-800-843-7990 Look for their advertisements in the back pages of Computer Shopper. The Mega series is $29.00 each or $69.00 for all three plus a fourth "Demo Disk". In all likelihood, the version 386bsd that is available on CD-ROM will be the 0.1 version, without any patches. Keep this in mind when ordering, since the first thing most people want to do is bring the system up to the current patch level. If you do not want the original 0.1 version, be sure to ask where the distribution came from and which version of *BSD it is. For our European users, I have included these notes from Julian Stacey (stacey@guug.de) and Christian Seyb (cs@gold.muc.de) concerning locations and methods for getting 386bsd in Europe on both CD-ROM and floppies. ---------------------------------------------------------------------- The following CDROM is available for DM 98,-- (app. $60) and contains the following software: - Linux SLS V1.03, Kernel 0.99.11 and utilities for Linux - 386BSD version 0.1 including patch-kit 0.2.4 - NetBSD version 0.8 - Utilities for 386BSD and NetBSD - The Berkely Second Networking Distribution - GNU software (gcc 2.4.5, emacs 19.17, gmake 3.68, etc) - X11R5 up to patch 25 and lots of Contributed Software - TeX version 3.14 - The Internet RFCs up to RFC1493 - News, mail and mailbox software and many utilities for Unix To: CDROM Versand Helga Seyb Fuchsweg 86 Tel: +49-8106-302210 85598 Baldham Fax: +49-8106-302310 Germany Bbs/Fax: +49-8106-34593 (Ed. Note: This appears to be an advertisement, but the price is right and appears to be reasonable. Christian and Helga may have the same last name by coincidence :-) If you want more ordering information, please feel free to give Helga a call.) ----------------------------------------------------------------------- In Munich Germany: Buy the monthly "c't magazin fuer computer technik" (Price 8.5 DM) (~1.7 = $1) & look in back pages, I saw: Mail Order: JF Lehmanns Buchhandlung, fuer EDV, Zuelpicher Str 182, D-50937 Koeln, Germany Free catalogue for X, Linux, 386bsd, unix. Confusing advert seems to offer X11R5 + GNU + 386BSD on CD Rom "InfoMagic Vol2 No2" for Price: 149 DM. Tel. 0130 4372 (always busy, claims to be free, so don't know if +49 130 4372 viable) Fax: +49 221 415995 Shops in Berlin, Koeln, Regensburg, Ulm. (Editorial Notes: DM149 is about $75-$90 US (or a little more) and 0130 numbers are Toll Free in Germany only.) Mail Order: Computer Solutions Software GmbH Postfach 1180, D-85561 Grafing (Muenchen), Germany Tel +49 8092 5018 Fax +49 8092 31727 23 * 3.5" 1.4M flops @ Price: DM199 Order No:/Best Nr: 5099 Shop: Columbus Datentechnik, Theresienstr 63, D-80333 Muenchen, Germany Tel +49 89 5232021 Lynne wrote a short follow-up, letting us know that these companies do not send them any money. This announcement in from Jordan Hubbard: On the morning of 30 December, 1993, and after many many delays, the first official release of FreeBSD 1.0 began shipping on CDROM. This CD is being sold through Walnut Creek CDROM, our ongoing sponsors in the FreeBSD project, and without whom we would have had a substantially more difficult (if not impossible) time producing it. While I will _always_ encourage obtaining FreeBSD through "free" channels (the Internet, friends, suspicious individuals in dark alleys), and given that none of us will make any money from CD sales, or ever have from FreeBSD in general given that WC's sponsorship is confined to the loan of centralized development hardware and network access, I still hope that some of you will find the CD distribution medium convenient enough to order a FreeBSD CD from Walnut Creek, thus indirectly supporting our future development work. If this marriage between commercial and free software interests proves to be mututally beneficial (which still remains to be seen, from Walnut Creek's point of view), it is my hope that it may serve as a model for similar future endeavors. It is an unfortunate fact that developing free software at this scale costs money, even with the developers donating their time and efforts, and financing some of it through the sale of convenient distribution media is one of the least venal ways I know of going about it. This CD contains a full FreeBSD 1.0.2 source & binary release, the sources and binaries for XFree86 2.0, and numerous sources from the FreeBSD "ports collection". Where space permitted, sources were provided in both "packed" and "unpacked" forms for easy access both as an on-line resource and as a source for compressed downloads in BBS or release-construction situations. The CD is fully ISO9660 compatable and has been mastered using RockRidge extensions for long filenames on systems that support it (like FreeBSD! :-). It is, of course, possible to install the system off the CD from scratch, given some basic willingness to read a little documentation and a few blank floppy disks. [ Ed Note. You would be surprised the number of people that do not see this paragraph...DBB] For the sake of convenience, I append the ordering information distilled from FreeBSD's /usr/src/RELNOTES.FreeBSD below. Ordering information: Walnut Creek CDROM 4041 Pike Lane, Suite D Concord CA 94520 1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax) Or via the internet from orders@cdrom.com. A current catalog can be obtained via ftp from ftp.cdrom.com:/cdrom/catalog. Cost is $39.95. Shipping (per order, not per disc if ordering multiple disks) is $5 in the US, Canada, or Mexico and $10.00 overseas. They accept Visa, Mastercard, American Express, and ship COD within the United States. California residents please add 8.25% sales tax. In addition, John Cargille publishes a CD-ROM which caters primarily to the NetBSD crowd. It is called BSDisc and it is also available by mail. While that may seem like terrific news, it is unfortunately all the information I have right now. Once he sees his name in the FAQ, maybe he'll put together some real ordering instructions ;-) roman@public.btr.com (Roman Yanovsky roman@btr.com) sent in this note. I have editted it down some, but left in the bulk of the stuff in case you need more information: Subject: Linux Slackware and FreeBSD CD-ROM with X-windows etc. Trans-Ameritech presents "The best Linux plus FreeBSD CDROM ever" [ Linux stuff deleted ] * For hacker's reference an uncompressed FreeBSD source tree is provided. * On the BSD side there is a full source and binary distribution of the "final" FreeBSD 1.0 * If you have questions or problems Trans-Ameritech provides free support via e-mail within 24 hours. * We ship the same day as we get the order. The new CDROM is available for $30 plus shipping/handling. If you are a current customer, it is only $20. New releases will be available every 3 month. Subscription is available. Trans-Ameritech Enterprises, Inc. 2342A Walsh Ave. Santa Clara, CA 95051 Tel. 408/727-3883 FAX: 408/727-3882 This information is offered with no warranties, guarantees, franchise offers, or recommendations. 1.6 Electronic Information Groups for 386BSD 1.6.1 Usenet newsgroups General BSD questions can be posted to comp.unix.bsd. Bear in mind, however; that your questions to this group should really be about BSD in general, not a specific implementation detail of *BSD. With the reorganization of the BSD newsgroups, this group name was changed to comp.unix.bsd.misc. Listed below are the old Usenet newsgroups that were developed to support 386bsd and its descendents. This means that you should ask your questions in one of these newsgroups or on one of the many mailing lists that are available for specific features of said systems. comp.os.386bsd.announce (Moderated) Announcements relating to the 386bsd operating system. Posts should be mailed to "386bsd-announce@agate.berkeley.edu". This is also the place that improtant news about the past and future of 386bsd, FreeBSD, and NetBSD will be placed. comp.os.386bsd.apps Applications which run under 386bsd. Not all sites will carry comp.os.386bsd.apps, since it kind of 'showed up'. comp.os.386bsd.bugs Bugs and fixes for the 386bsd OS and its clients. comp.os.386bsd.development Working on 386bsd internals. comp.os.386bsd.misc General aspects of 386bsd not covered by other groups. comp.os.386bsd.questions General questions about 386bsd. There has been a reorgainzation of the *BSD newsgroups since these were originally created. The new newsgroups are as follows: Newsgroup for discussion of general BSD questions: comp.unix.bsd.misc Newsgroups for the discussion of the Bill and Lynne Jolitz version of 386BSD: comp.unix.bsd.386bsd.announce comp.unix.bsd.386bsd.misc Newsgroups for the discussion of the FreeBSD version of BSD 4.4 Lite: comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc Newsgroups for the discussion of the NetBSD version of BSD 4.4 Lite: comp.unix.bsd.netbsd.announce comp.unix.bsd.netbsd.misc Newsgroups for the discussion of the commercial version of the BSD 4.4 Lite system: comp.unix.bsd.bsdi.announce comp.unix.bsd.bsdi.misc 1.6.2 Newsgroup archives. These sites maintain a historical record of the traffic in the Usenet Newsgroups indicated. There are others, but I haven't gotten their names yet. Host Name IP address Location Newsgroups archived -------------------- -------------- -------------- ---------------- minnie.cs.adfa.oz.au 131.236.20.70 Australia comp.unix.bsd, comp.os.386bsd.* src.doc.ic.ac.uk 146.169.2.1 London, UK comp.os.386bsd.* 1.6.3 386bsd Derived mailing lists. With the elimination of the old 386bsd mailing lists, the only mailing lists that are still available are the ones for FreeBSD and NetBSD. Information about the NetBSD lists and how to use majordomo (the list handler) is available by mailing to majordomo@sun-lamp.cs.berkeley.edu. There are four mailing lists for FreeBSD and they are: FreeBSD-hackers: for hackers FreeBSD-questions: misc questions FreeBSD-bugs: bug reports FreeBSD-current: discussion of -current (in development) Send to FreeBSD-hackers-request@freefall.cdrom.com to be added to the hackers list, and *-questions-request@freefall... to be added to the questions list. For information about the NetBSD mailing lists, see the NetBSD Mailing List FAQ that is posted regularly by Chris Demetriou in comp.os.386bsd.announce. 1.6.4 Other electronic resources. There are many bulletin boards throughout the world that have 386bsd software and information available. Also, there are CompuServe and other on-line services that have 386bsd discussions. It is even rumored that Bill and Lynne have been active on Compuserve talking about 386BSD Version 1.0 (or 0.2, or whatever it is going to be). There are also IRC discussions on the net, but I don't have any more information than that right now. 1.6.5 System Updates. There are at least two different ways of getting the updates for the current source tree for both FreeBSD and NetBSD. The first is the traditional FTP method, and the other is using a utility called 'sup'. This program keeps a log of the source modules that have been updated and sends out only those files that have been changed. Included below are some sample instructions from John Brezak on how to run sup for NetBSD. The sup procedures for FreeBSD are similar and are available via ftp from freefall.cdrom.com in the ~/ftp/pub/sup directory. This directory contains the sup program, a man page, a sample sup-file and full instructions for maintaining your sources via 'sup. Instructions for installing NetBSD sources and releases using SUP ----------------------------------------------------------------- 1.3 1993/11/3 SUP is a network installation package written by CMU used to distribute software. For more details on SUP refer to the man pages. Sup works by reading a configuration file (supfile) and using this information to determine what "collections" of files will be loaded from the collection repository. Here is an example of a supfile to load the NetBSD current release. [ Notes: lines have been broken for readability; do NOT use '\' in supfiles and the information here is an EXAMPLE. This ain't a cooking school, folks. Also, the information in these lines has changed for each of the distributions. Read the documentation that comes with your software carefully for the lastest information. ] src release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup ksrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup security release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup gamessrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup regress release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup #othersrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup This supfile will load the "current" collections for "src", "ksrc", "security", "gamessrc", and "regress" in the /usr directory on the local machine. The "othersrc" collection will not be loaded because it is commented out. The supfile line is made up of keywords that describe the collection's location on the sup server and where and how it will be loaded on the local host. release - the release of the collection to load. host - the 'host' where the SUP repository resides. NetBSD uses sun-lamp.cs.berkeley.edu . hostbase- the pathname on the host to the base of the collection. The hostbase for NetBSD is "/b/anon_ftp". base - where you want to install it locally. prefix - used to locate the "sup" directory to write sup's info about updates. Usually the same as base. This supfile can also set some options. The "old" option tells sup to check all files for changes, not just those that are newer than the last sup update. Normally sup will overwrite local files with the changed file from the repository. If the sup collection specifies that an existing file should be renamed to a backup, the "backup" option in the supfile activates this. The "delete" option tells sup to delete any files locally that are no longer in the collection - be careful with this one. The "keep" option will cause sup to NOT update files that have been changes locally. The "compress" option will use gzip to compress the files before transfer and gunzip them on the receiving end. This option can be used to cut down on the number of transmitted bytes. You may want to set 'base' and 'prefix' to something other than /usr if you want to preserve your existing src tree. The sup repository on sun-lamp.cs.berkeley.edu currently offers these collections. src, ksrc, security The sources for NetBSD othersrc The current sources for contributed parts of NetBSD. This contains the sources for sup. regress The current sources for the NetBSD regression test suite. If you only want the kernel sources for a specific port there are some sub packages that you can use instead of the "ksrc" one. If you are using the sub packages, be sure to also sup the "ksrc-common" package. ksrc-common Kernel sources common to all ports. ksrc-1, ksrc-sparc, ksrc-hp300, ksrc-amiga, ksrc-mac, ksrc-pc532, ksrc-pmax, ksrc-sun3 Kernel sources for a particular port. The security package is not to be sup'ed by sites outside of the U. S., read the "README.export-control" file for details. Each collection can have multiple releases (as specified by the "release" keyword). IMPORTANT!! Be aware that the current release is simply a snapshot of the daily state of NetBSD development and is not guaranteed to build (or even work) - use at your own risk ! Stable releases of NetBSD are available via SUP. Instructions are included with the release announcement. Before running sup, be sure that your /etc/services contains these entries. supfilesrv 871/tcp # for SUP supfiledbg 1127/tcp To try sup without really updating anything use the '-f' flag. The '-v' flag means verbose and can be used to see what sup is doing. sup -fv supfile The sup binary, sup man page and sample supfiles can be ftp'ed from sun-lamp.cs.berkeley.edu:~ftp/pub/sup . Comments should be directed to "sup@sun-lamp.cs.berkeley.edu". A mailing list exists for users of the NetBSD "current" release. To join, mail to 'majordemo@sun-lamp.cs.berkeley.edu' with a mail body of "info". The reply will describe the mailing lists for NetBSD. The you will want to subscribe to the "current-users" mailing list. We will use this list to announce any special changes made to the "current" tree. 1.7 Documentation available This entire section pertains as much to NetBSD and FreeBSD as it does to 386BSD. Simply 'sed 's/386bsd/Your System/g' below. There are two types of documentation for 386bsd. First is the set that covers the operation and theory used in BSD-Unix. These sources are often excellent for background and understanding of the current implementation of 386bsd. Second is the set of manuals written specifically for 386bsd. Most of these are books and magazine articles written by Bill and Lynne Jolitz. 1.7.1 BSD manuals The full set of BSD documentation is available via anonymous FTP from ocf.berkeley.edu in /pub/Library/Computer/doc4.3. To print this documentation on 386bsd systems, replace the ditroff references in the Makefile with 'groff -e -t -msU {SRC} >out.ps' to generate PostScript format files. Use different options to make the output conform to other print styles. The etc distribution also comes with a documentation directory /usr/share/doc which has nearly 3Meg of documentation about *BSD. In addition, on-line manuals are available in the binary distribution set. It contains specific information on the use of UNIX utilities and commands. Type "man man" for information on the online manual. 1.7.2 BSD books There is an excellent set of works recommended by Bill and Lynne in the original 386bsd INSTALL.NOTES. In addition, several other books have been recommended by Andrew Moore and others. For learning how to work in the Unix environment, the standard text is "The Unix Programming Environment," by Kernighan and Pike. For Unix Administration, the best is "Unix System Administration Handbook," by Nemeth, Snyder and Seebass. For systems level programming (i.e., systems calls), I recommend "Advanced Unix Programming," by Marc Rochkind. Unfortunately it is out-dated and oriented towards System V. A new book "Advanced Programming in the Unix Environment," by W. Richard Stevens is very up-to-date, and an excellent reference, especially for dealing with POSIX standards issues. For network programming, "Unix Network Programming," by W. Richard Stevens is highly regarded. The 4.3BSD Unix Manuals contain loads of invaluable tutorials and historical papers in addition to hard copies of on-line documentation. The six volume set is available from Usenix for $60.00 (email: office@usenix.org) The 4.4 BSD Unic Manuals are the authoritative source for information about the 4.4 BSD release, and by inference the NetBSD and FreeBSD systems. They are available from O'Reilly and Associates (the Nutshell series people). In addition the the six volume set, there is a CD included (at a price) of the entire 4.4 release. Combine this with the NetBSD 1.0 or FreeBSD 2.0 systems, and you should have a commercial quality operating system available in no time. I could go on, but let me mention just two more - if you have a full 386BSD installation, you may want to learn the bash shell (in /usr/othersrc/public). This is an extension of the Bourne shell (sh) with features from both the C shell (Csh) and the Korn shell (Ksh). The Korn shell is described in "The Kornshell," by Korn (of course). Second, I recommend you look at "The AWK Programming Language," by Aho, Weinberger and Kernighan. This is a very nice prototyping language - powerful and easy to use. Another excellent reference book for 386bsd is "The Design and Implementation of the 4.3BSD UNIX Operating system" by Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S. Quarterman, 1989, Addison-Wesley, ISBN 0-201-06196-1. While this book is out of date in many sections, it is purported to be an excellent source of historical information, if nothing else. Chris Demetriou recommends the sections on the treatment of file systems, caching and the networking layer. The sections in this books which do not apply to 386bsd include the VM section, bootstrapping, and autoconfig. Here is a list from Hellmuth Michaelis (duplicative as it may seem to have all of these lists) for more information on *BSD: UNIX AND UNIX DEVICE DRIVERS ---------------------------- Bell Telephone Laboratories, Inc. "UNIX Programmer's Manual, Seventh Edition, Volume 2". Revised and Expanded Version. Holt, Rinehart and Winston 1983 George Pajari, "Writing Unix Device Drivers" Addison Wesley 1992 Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver" John Wiley & Sons 1988 Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver" Second Edition. John Wiley & Sons 1992 Leffler, McKusick, Karels, Quarterman, "The Design and Implementation of the 4.3BSD UNIX Operating System" Addison Wesley 1988, corrected Reprint 1989 Leffler, McKusick, "The Design and Implementation of the 4.3BSD UNIX Operating System, Answer Book" Addison Wesley 1991 Maurice J. Bach, "The Design of the UNIX Operating System" Prentice-Hall 1986 Sun Microsystems Inc., "Writing Device Drivers" Part No. 800-3851-10, Revision A of 27 March 1990 Hewlett-Packard Company, "HP-UX Driver Development Guide", Part No. 98577-90013, First Edition 07/91 W. Richard Stevens, "Advanced Programming in the UNIX Environment", Addison Wesley 1992 Phillip M. Adams, Clovis L. Tondo, "Writing Unix Device Drivers in C", Prentice Hall 1993 Peter Kettle, Steve Statler, "Writing Device Drivers for SCO UNIX, A Practical Approach", Addison Wesley 1993 In addition, there are many other books which, for one reason or another, have not made it into this brief list. Rest assured that this is not intended to be an exhaustive list by any means. 1.7.3 The Jolitz Book Bill and Lynne Jolitz are writing a book about 386bsd. It will be announced once it is ready. A tentative date of late 1992 was once offered, but since it is now 1994 and no book has been announced, we can assume that it will be later than the original estimate. 1.7.4 Dr. Dobbs' journal For users who wish to understand the internals of the BNR/2 BSD family of Operating Systems originally developed and/or ported by William F. Jolitz from 1989 to the present, the most immediate and available reference is the feature series entitled "Porting UNIX to the 386: A Practical Approach", appearing in Dr. Dobbs' Journal, USA (January 1991 to July 1992) and UNIX and iX Magazines, Germany (June 1991 to present). For inquiries on the article series (including reprints), contact the magazines for information. "Porting UNIX to the 386: A Practical Approach" (feature series) by Jolitz and Jolitz 1/91: DDJ "Designing a Software Specification" 2/91: DDJ "Three Initial PC Utilities" 3/91: DDJ "The Standalone System" 4/91: DDJ "Copyright, Copyleft, and Competitive Advantage" 4/91: DDJ "Language Tools Cross-Support" 5/91: DDJ "The Initial Root Filesystem" 6/91: DDJ "Research and the Commercial Sector: Where Does BSD Fit In?" 7/91: DDJ "A Stripped-Down Kernel" 8/91: DDJ "The Basic Kernel" 9/91: DDJ "Multiprogramming and Multiprocessing, Part I" 10/91: DDJ "Multiprogramming and Multiprocessing, Part II" 11/91: DDJ "Device Autoconfiguration" 2/92: DDJ "UNIX Device Drivers, Part I" 3/92: DDJ "UNIX Device Drivers, Part II" 4/92: DDJ "UNIX Device Drivers, Part III" 5/92: DDJ "Missing Pieces, Part I" 6/92: DDJ "Missing Pieces, Part II" 7/92: DDJ "The Final Step: Running Light with 386BSD" You can contact M&T Books (DDJ) for reprints if you can't get them from your technical library: 1-800-356-2002 (inside CA) 1-800-444-4881 (better In NA Backorder number) 1-415-358-9500 (international) 6/91: UNIX Magazin "Portierung von BSD-UNIX auf den 80386. Heimlich Liebe." 7/91: UNIX Magazin "Steighilfe." 8/91: UNIX Magazin "Systemverwaltung durch Tabellen" 9/91: UNIX Magazin "Sicher bewegen auf fremdem Terrain" 10/91: UNIX Magazin "Damit die Fehlersuche nicht zum Hurdenspringen wird" 11/91: UNIX Magazin "Alles in eine Schublade" 12/91: UNIX Magazin "Feuer und Wasser" 1/92: UNIX Magazin "Rekursives Speicher-Mapping" 2/92: UNIX Magazin "Tanz auf dem Eis" 3/92: UNIX Magazin "Aus Hanschen wird Hans" 4/92: UNIX Magazin "Das Geheimnis des Multiprogramming" 5/92: UNIX Magazin "Zeitmanagement scheibenweise" 6/92: UNIX Magazin "Magie des Kernels" 7/92: UNIX Magazin "Erkenne Dich Selbst" 9/92: UNIX Magazin "Niemand is eine Insel" 10/92: UNIX Magazin "Treiberlatein" 12/92: UNIX Magazin "Einlandung erforderlich" 1/93: iX Magazin "Wir unterbrechen das Programm" 2/93: iX Magazin "Liste gut, alles gut" 3/93: iX Magazin "Blick ins Allerheiligste" 4/93: iX Magazin "Von Bl"ocken, Ringen und Zeichen" NOTE: The series in UNIX Magazin was moved to IX Magazin in 1/93. The article in the April issue was the last one in the series. In addition, other major articles which discuss 386BSD in detail: 8/92: UNIX Magazin "Interview mit Bill Jolitz. Das passiert mit 386BSD" by Jurgen Fey 8/92: DDJ "Very High-Speed Networking" by W.F. Jolitz 12/92: DDJ "Inside the ISO-9660 Filesystem Format" by Jolitz and Jolitz Reprints of the first 19 parts on the UNIX Magazin series are available from: iX Redaktion Stichwort: 386BSD-Serie Verlag Heinz Heise GmbH & Co KG Helstorfer Str. 7 D-30625 Hannover, Germany Some of the parts are without code listings due to the unclear status of the BSD releases stemming from the Net/2 release. Dr. Dobbs is reported out of back issues of the articles listed above. You best bet may be to try your local public or school library. 1.7.5 Documentation that comes with most of the distributions. In the standard set for both NetBSD and FreeBSD there is a directory called '/usr/share/doc'. Here is a 'du' listing. 128 /usr/share/doc/ps1/06.sysman 98 /usr/share/doc/ps1/07.ipctut 116 /usr/share/doc/ps1/08.ipc 16 /usr/share/doc/ps1/13.rcs 37 /usr/share/doc/ps1/14.sccs 420 /usr/share/doc/ps1 123 /usr/share/doc/smm/02.config 14 /usr/share/doc/smm/04.quotas 78 /usr/share/doc/smm/05.fsck 42 /usr/share/doc/smm/06.lpd 92 /usr/share/doc/smm/07.sendmailop 14 /usr/share/doc/smm/08.timedop 99 /usr/share/doc/smm/10.newsop 83 /usr/share/doc/smm/11.named 77 /usr/share/doc/smm/14.fastfs 128 /usr/share/doc/smm/15.net 41 /usr/share/doc/smm/16.sendmail 21 /usr/share/doc/smm/20.termdesc 17 /usr/share/doc/smm/22.timed 851 /usr/share/doc/smm 144 /usr/share/doc/usd/04.csh 97 /usr/share/doc/usd/07.Mail 66 /usr/share/doc/usd/09.newsread 68 /usr/share/doc/usd/10.etiq 67 /usr/share/doc/usd/14.edit 107 /usr/share/doc/usd/15.vi 61 /usr/share/doc/usd/16.ex 13 /usr/share/doc/usd/21.msdiffs 45 /usr/share/doc/usd/22.memacros 43 /usr/share/doc/usd/23.meref 26 /usr/share/doc/usd/33.rogue 25 /usr/share/doc/usd/34.trek 798 /usr/share/doc/usd 2077 /usr/share/doc For those of you that don't read 'du -k' listings, this means that there is 'around' 2 MEGABYTES of documentation in the 'doc' directory. In addition, there are a few man pages. 2312 /usr/share/man/cat1 397 /usr/share/man/cat2 1 /usr/share/man/cat2a 855 /usr/share/man/cat3 1 /usr/share/man/cat3f 607 /usr/share/man/cat4 368 /usr/share/man/cat5 166 /usr/share/man/cat6 169 /usr/share/man/cat7 749 /usr/share/man/cat8 Something on the order of another 4 Megabytes of manual pages. That's what, about 6 MILLION CHARACTERS of documentation. I have received mail from several sources saying that my approximation of the amount of system documentation is way too low (by a factor of at least 50%). Given the fact that even by my meager estimation there is already more information here than most people can be bothered to read, whether there is 6 Meg or 60 Meg seems like overkill. Now, does anyone REALLY want to whine about there being no documentation included with the system? 1.7.6 Other FAQ's on the net that are relevant There is now a FAQ set up specifically for FreeBSD. In addition to answering the many specific questions that folks have about FreeBSD, it is also a good source for information on NetBSD and whatever the 386BSD {0.2,1.0,95} project is going to look like. In spite of all of the shouting and chest beating that you hear from time to time, the systems are still very close. There are many FAQs that can be used in conjunction with 386bsd. These include the FAQs for all of the GNU software, the different shells that are available, the programming languages that are available, and many more. In addition, many programs have their own FAQ which should be referenced whenever that package is being added. Good examples of the latter are the FAQs for elm, C-News, and innd. The observant reader will notice that there are very few 'X' questions in this FAQ. The XFree86 FAQ is posted regularly to comp.os.386bsd.*. There is no good reason to include any 'X' questions in this FAQ, with the exception of the most basic 'Where can I get the 'X' FAQ'. Most FAQs are available by anonymous FTP from rtfm.mit.edu and via Usenet News in news.answers and/or comp.answers. This FAQ is no exception (I hope). 1.8 FTP sites for 386BSD A standard tool on Internet connected hosts for finding files is 'archie'. Searching the archie archive for either "386BSD" or "386bsd" yields the following list. For UUCP sites, FTP-Mail is available from gatekeeper.dec.com. The list below was created with an 'archie -l' on 26 Mar 1995 searching for FreeBSD. For those folks that have access to telnet, but not FTP, you can use archie by using telnet and connecting to 132.206.2.3. Log in as 'archie' and use the 'prog' command to find programs of interest. The list below is included primarily for those folks that have only uucp, and will need to get their software though UUCP and other channels. 1.8.1 FTP Site List This list is automatically generated every time the FAQ is produced. Please do not request that your host be added to this list. If your host is represented in an 'archie' list, it will be reflected here. Several other sites are included in Section 1.8.4 below. Host Directory The code may soon also to be available, or perhaps is already available, from both CompuServe and BIX. 1.8.2 Official distribution sites According to Lynne Jolitz, there is no such thing as an 'official' 386bsd site. The closest we had was 'agate.berkeley.edu' which is now closed. Because of the USL/UCB agreement, 386bsd is no longer freely redistributable, since it was based on Net/2 and Net/2 was encumbered. FreeBSD's 'home' is FreeBSD.cdrom.com (the home disk of Walnut Creek). The portions of FreeBSD (versions less than 2.0) that were encumbered are distributed with the tolerance of AT&T/USL/Novell/whoever owns the source for SysV this week. All FreeBSD versions (with version number >= 2.0) are based solely on the freely redistributable BSD 4.4 sources. NetBSD's 'home' is now ftp.NetBSD.Org. All versions of NetBSD since 0.9 have replaced the kernel code from the 4.3 distribution with the source from the 4.4 distribution. The only code still in NetBSD from the 4.3 distribution is some user program code that was uncontested in the USL/UCB agreement. 1.8.3 Reference sites For a brief period, ref.tfs.com was available for use as a reference system. This system was used as the test-bed for many programs that were ported to 386bsd by many authors. Unfortunately, ref.tfs.com has been disabled as a reference system. The site is now a update by mail (CTM) system and is providing a mail only service for developers who do not have access to anything more than electronic mail. For more information, contact phk@freefall.cdrom.com for the standard CTM package. There is a site in Germany that is acting as a reference site for FreeBSD. The name is "g386bsd.first.gmd.de", also known as "bsd386.first.gmd.de". Sorry, no anonymous ftp yet. But there is a "guest" login with the password "guest". But the most important reason why I had installed the machine on the network was for all these people who don't have enough space to compile their own kernel or their own packages. They can do it on this machine. ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de ) 1.8.4 Unofficial archive sites that have neat stuff! There are many sites that have things which have either been ported to 386bsd or are available to the world. Use archie to find these sites, or read comp.os.386bsd.* for more information. Listed here because they don't have access to 'archie' yet... g386bsd.first.gmd.de -or- bsd386.first.gmd.de: Sources for 386bsd0.1 and the later patchkits. Source for NetBSD0.8 and the newer snapshots. Xfree is installed binary as version 1.3. Ported software are: tcsh6.03.00 emacs19-15 gcc-2.4.5 top3-1 perl4.0.36 elvis1.7 bison-1.21 rn and nn. In addition, ftp.cs.tu-berlin.de has a lot of neat software and Wolfram Schneider (wosch@cs.tu-berlin.de) has 'ported' the FAQ into LaTeX. It is available in pub/386BSD/FAQ/tex in both PostScript and DVI formats. 1.8.5 X for 386BSD 0.1 Ported Software List This is a list of non-core X window system application that have been ported to 386BSD 0.1. The ftp server and directory name are listed above and each file or directory name is followed by a short description. Feel free to send corrections, additions or suggestions to rich@rice.edu. nova.cc.purdue.edu:/pub/386bsd/submissions Xdtm-2.5.386bsd X desk top manager idraw-bin.tar.Z C++ GUI class library + WYSIWYG document & graphics editors. img1.3.386bsd.tar.Z see above mpeg_play.Z animated raster image viewer small_X11r5.tZ a minimal subset of the core distribution vogl.tar.Z a library that emulatates Silicon Graphics GL calls xview3 sun's GUI development tool kit sunvis.rtpnc.epa.gov:/pub/386bsd/incoming: Dirt.tar.Z GUI development tool kit XBSD8514-0.1.Z 8514 X server port XS3-0.3-exp.Z S3 X server port acm.tar.Z aerial combat mission/flight simulator chess-vort-movie.tar.Z ? epoch.Z enhanced emacs for X jpeg.tar.Z jpeg viewer libXaw3d.a.Z 3D widget library mpeg-1.2.tar.Z animated raster image viewer ups-2.45.bin.tar.Z C source level debugger with slick GUI vort-movie.tar.Z ? xantfarm.tar.Z screen saver with ants? xbench.tar.Z X server performance measurement tool xpipeman.tar.Z game: connect pipes to keep a liquid within xxgdb.tar.Z GUI for GNU source level debugger 1.8.6 Motif for the *BSD family. (Infomercial to follow) While I don't normally include commercials in the FAQ, I will this time. Motif is an interesting product that will help the development of the free Unices. It can also serve as a benchmark for other commercial organizations to consider supporting us by producing versions of their products that will work on these systems. Sequoia International, Inc. (305-783-4915/305-783-4935 (FAX)) sells a complete Motif 1.2.3 Runtime and Development package for FreeBSD, NetBSD, BSD/386, Linux, and Coherent. It is available for $149.95 and includes the following: * The Motif Window Manager (mwm) * Shared Library (libXm) [operating system dependent] * Static Libraries (libXm, libMrm, libUil) * Header and Include Files * Complete On-Line Manual Pages * Source code to OSF/Motif Demo programs * Complete OSF/Motif Users Guide Send mail to info@seq.com or contact them at the address below: Sequoia International, Inc. 600 West Hillsboro Blvd, Suite 300 Deerfield Beach, FL 33441 Phone: (305)783-4915 / FAX: (305)783-4935 / Email: info@seq.com -- TSgt Dave Burgess | Dave Burgess NCOIC, USSTRATCOM/J6844 | *BSD FAQ Maintainer Offutt AFB, NE | Burgess@s069.infonet.net From csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail Thu Apr 13 15:16:17 1995 Path: csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 2 of 10) Supersedes: <386bsd-faq-2-796287611@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 13 Apr 1995 01:00:16 -0500 Organization: Dave's House in Omaha Lines: 1308 Sender: burgess@cynjut.netins.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 05/01/95 01:00:08 CDT Message-ID: <386bsd-faq-2-797752808@s069.netins.net> References: <386bsd-faq-1-797752808@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.netins.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:27 comp.unix.bsd.freebsd.announce:30 comp.answers:11170 news.answers:41786 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part2 Section 1. (General Network Information) General information This section of the FAQ is about the electronic support network that exists for 386bsd and its off-spring. 1.0 What is 386BSD? (Taken from the original INSTALL.NOTES by the Jolitz's, specifically Lynne) Welcome to 386BSD Release 0.1, the second edition of the 386BSD operating system created by William and Lynne Jolitz. Like its predecessor, 386BSD Release 0.0, Release 0.1 comprises an entire and complete UNIX-like operating system for the 80386/80486-based AT Personal Computer. 386BSD Release 0.1 is an enhanced version of the original release done by William F. Jolitz, the developer of 386BSD. 386BSD Release 0.0 was based on the Networking Software, Release 2 from the University of California at Berkeley EECS Department, and included much of the 386BSD work done earlier by Bill and contributed by us to the University. The latest release, 386BSD Release 0.1, contains new work by the developer and many new items which have been freely contributed by other software developers for incorporation into 386BSD (see the file CONTRIB.LIST). These contributions have increased the functionality and made it more robust. As a courtesy to the developer and the many people who have generously contributed these software enhancements, we request that users abide by and properly maintain all attributions, copyrights, and copylefts contained within this release. 386BSD is intended to foster new research and development in operating systems and networking technology by providing this base technology in a broadly accessible manner. As such, like its predecessor, 386BSD Release 0.1 is freely redistributable and modifiable. 1.0.1 What are these other Free BSD systems? For reasons best left to private E-Mail, there have been two different 'product lines' that have been established for development of BSD systems. They are NetBSD and FreeBSD. Both, individually, have virtually deprecated the original 386bsd. The "raison d'etre" for each is different and each has a different set of goals. The purpose for FreeBSD is to develop a stable working environment for [3-9]86 systems. The emphasis has been on upgrading utility programs and incorporating changes that make the system more stable. NetBSD, on the other hand, is a development effort whose main thrust is on mulitple platform support and staying more current with BSD 4.4. In other words, NetBSD is more 'horizontal' and FreeBSD is more 'vertical'. Both systems are excellent choices for the casual user or people who are interested in studying the internals of an operating system. While the products are nearly commercial quality, they are both maintained by volunteers. 1.0.2 I just downloaded all of 386bsd version 0.1 and I can't get [some feature] to work? Do you have any suggestions? Yes. Get either FreeBSD or NetBSD. The original 386BSD software was kind of buggy when it was put up for anonymous FTP in 1992. It has been modified significantly since then, and now exists in two different forms. There are people who will argue that the original 386BSD was completely unusable, but that is generally an overstatement. Over 100 patches were applied to the original system, with hundreds more waiting in the wings. It became just too much trouble to constantly have to patch the system to get it to work. This 'patched' version of 386bsd became FreeBSD. Around the same time, a second group split off from the original 386bsd tree and became NetBSD. For the primary differences, see above. Getting one of these two systems will provide you with a more complete system, with newer utilities, and many bugs already fixed. 1.1 Feature summary Among the many features of these systems: * Floppy disk based Installation * Hard drive partitioning for use with MS-DOS partitions * Compressed, multivolume CPIO dump format binary/source/other distribution sets on MS-DOS floppies. The cpio is based on the GNU cpio, and is completely free of encumbering USL software. * 387 support or emulation. * SCSI support. * (SCSI and most non-EIDE Mitsumi) CD-ROM support. * NFS, TCP/IP and full networking. * MS-DOS file system access (in newer *BSD systems). * PPP and SLIP protocol support. * System upgrades through Carnegie Mellon University's 'sup' utility. * Shared Library Support (in the newer version of both NetBSD and FreeBSD. * Both systems are based exclusively on Berkeley's BSD 4.4 Lite tape, instead of the encumbered 4.3 Net2 tape. Hence, both systems are free of encumbered USL code and are freely redistributable. 1.2 The future of 386BSD. { This section is included for historical purposes only. Most of the information in here is either wildly out of date or just plain wrong. For example, the FreeBSD statements in here imply that it is nothing more than 386bsd in a new coat of paint. Nothing could be further from the truth. I decided to include it mostly to show how far we have come... dbb } Forecasting the future is always a tricky business. There is work underway to implement version 0.2 of 386bsd. In addition, many people are involved in a project to put together a 386bsd version (FreeBSD) which will be a complete distribution set including all relevant patches and updates to new versions of many of the software packages that are currently available. It is available by anonymous FTP from FreeBSD.cdrom.com In addition, NetBSD (a direct descendent of 386bsd) is available for anonymous FTP from sun-lamp.cs.berkeley.edu. The purposes of these two apparent competitors appear to be at odds, but in fact are very similar. NetBSD has taken a 'stable, production quality, free OS' as one of its primary goals, where 386bsd pursues the high ideal of the ultimate OS research platform. There is considerable cross pollination of the two. The frequent debates on style and concept that appear in comp.os.386bsd.* are testimony to that point. NetBSD and FreeBSD are still both very viable operating system alternatives, with differing goals. To see the Future of 386bsd as seen by Bill and Lynne Jolitz, I suggest you read the INSTALL.NOTES that come with 386bsd. 1.3 386BSD software projects in progress The list of software projects in progress is just too volatile to go into a static document like the FAQ. Suffice it to say, if there is something you want to do using 386bsd; ask first to see what has been done. Folks that are interested in software projects for NetBSD should contact netbsd-comments@sun-lamp.cs.berkeley.edu and let that mailing list know the same information. Folks interested in software projects for FreeBSD should contact the freebsd-hackers@freefall.cdrom.com mailing list and talk to them. 1.3.1 Contacting software authors Whenever you are working on a port of a software package, it is always a good idea to contact the original author and offer whatever changes you needed to make in order to port the software. That way, subsequent releases of the package may include changes that allow all users of 386bsd the advantage of reusing your work over and over. Also, once you have ported a package to *BSD, you might want to contact the respective *BSD teams to let them know you've completed it and where it may be located. For FreeBSD, contact: For NetBSD, contact: If the port was a simple recompile of the source and install, a note to one of the newsgroups telling the story could be considered appropriate as well. In keeping with that, if you find a 'bug' in 386bsd, or NetBSD, or FreeBSD, or find a problem that causes you some headaches and find a solution, you should contact the author of the particular driver/module/program and let them know. In addition, you could also post the problem and/or fix to "comp.os.386bsd.bugs". Both NetBSD and FreeBSD have implemented 'bugfiler', so if you are connected to the net, you can use that to send out your bug. See the documentation that comes with your system to find out more. 1.4 Minimum hardware configuration recommended There has been considerable debate about what the REAL minimum configuration for 386bsd is. Some would claim that it is the smallest computer that an installation will succeed on. Others claim that it is the smallest usable computer (based on RAM and speed constraints) and others would claim that it should be based on using 'X'-windows. For specific hardware, see Section 8 (still in development). The smallest installable platform is an 80386, using an MGA card, with at least 2Meg of RAM and a 20 Megabyte hard disk. While not all SCSI cards (especially EISA) are supported, a great many are either in the base distribution or through patches. Thanks to the new shared library code in FreeBSD and NetBSD, a 20Meg installation should be easier now (in spite of the more advanced functionality) than it ever was before. A comfortable installation which includes source and binary distributions, as well as other utilities will work in about 100Meg of hard drive. 'X' requires at least a Hercules MGA; for masochists only, from what I understand. See section 8 for more details. 1.5 Where to get the source and binaries 1.5.1 Forms available (floppy, FTP, CD-ROM) 386bsd is available in just about every format known to man, with the possible exception of stone tablets and papyrus. 1.5.1.1 Where can I get the distribution on floppy or tape? Many people will copy files onto diskettes or tapes if you coordinate it with them ahead of time. In addition, many companies offer 386bsd on various types of media for money. Austin Code Works and others (usually advertisers in PC magazines) offer the base 0.1 "official" distribution for a fee. Note that there are virtually no restrictions on distributing the 386bsd distributions. Basically, wherever you can find it, you can get it. This goes for FreeBSD and NetBSD as well. 1.5.1.2 Where can I get the distribution via FTP? If you are looking for the original 386bsd version 0.1, the files you should look for specifically when using FTP are directories called srcdist, bindist, and etcdist. These directories will hold the files for each of the distributions. Once you have received the files via FTP, you can either load them directly onto your system and then un archive them using 'extract' or one of the other methods suggested in Section 2 of the FAQ, in the section about installing with 'real partitioning'. The list of sites that have 386BSD is covered in section 1.8 below. This list is produced automatically by using a utility called 'archie' and is updated for every new version of the FAQ. If you try to access a site from this list and find that they either don't have FTP enabled, or don't have 386bsd loaded any more, a polite letter to the admin of the system asking them to update their 'archie' entries is good manners. 1.5.1.3 Where can I get the distribution on CD ROM? Infomagic sells a UNIX CD-ROM that has 386BSD. Their FAX number is 609-683-5502. In a new joint venture, DiscNet, Inc., and InfoMagic, Inc. are pleased to announce their joint release of the BSDisc. This collaboration should be beneficial to all of our customers, since it brings to bear more experience, more support capability, and economies of scale in production. The BSDisc (Vol 2, Num 1) is scheduled to begin shipping on the 20th of December, 1994. Available now for over a year, the BSDisc seeks to provide what BSD users and hackers want most on a CD-ROM. The current issue includes: - NetBSD 1.0 - distribution sets for 1, sparc, mac68k, and amiga - expanded source tree for all architectures - FreeBSD 2.0 - distribution sets for 1 - expanded source and binary trees for 1 - XFree86 binaries for both FreeBSD and NetBSD - X11R6 (xc as well as contrib) - BSD-related news archive - various Answers to Frequently asked Question (FAQs) - Lots of Freeware/Gnuware sources from the FreeBSD Ports effort - FreeBSD pre-built binary packages - a small set of pre-built NetBSD binary packages The BSDisc is available both for single-issue purchases, or on a buying plan. Single-issue price is $35.00; subscription pricing is $19.50 per issue, for a minimum length of 3 issues. (Those prices do not include S/H.) For single-issue purchases, contact InfoMagic at: +1-800-800-6613 InfoMagic, Inc. Tel: +1-602-526-9565 PO Box 30370 Fax: +1-602-526-9573 Flagstaff, AZ 86003-0370 e-mail: orders@Infomagic.com info@infomagic.com For information about subscriptions, contact DiscNet at: DiscNet, Inc. +1-608-846-9838 841 Acker Pkwy DeForest, WI 53532 email: bsdisc-info@grilled.cs.wisc.edu bsdisc-orders@grilled.cs.wisc.edu European subscriptions, email: bsdisc@altona.ppp.net Profit Press has 386BSD dated 7/21/92 on their "Mega Win OS/2" CD-ROM. This is in the format of BINDIST, ETCDIST, SRCDIST and BOOTABLE. Profit Press 2956 N. Campbell Ave Tucson, Arizona 85719 (602) 577-9696 Their order line is 1-800-843-7990 Look for their advertisements in the back pages of Computer Shopper. The Mega series is $29.00 each or $69.00 for all three plus a fourth "Demo Disk". In all likelihood, the version 386bsd that is available on CD-ROM will be the 0.1 version, without any patches. Keep this in mind when ordering, since the first thing most people want to do is bring the system up to the current patch level. If you do not want the original 0.1 version, be sure to ask where the distribution came from and which version of *BSD it is. For our European users, I have included these notes from Julian Stacey (stacey@guug.de) and Christian Seyb (cs@gold.muc.de) concerning locations and methods for getting 386bsd in Europe on both CD-ROM and floppies. ---------------------------------------------------------------------- The following CDROM is available for DM 98,-- (app. $60) and contains the following software: - Linux SLS V1.03, Kernel 0.99.11 and utilities for Linux - 386BSD version 0.1 including patch-kit 0.2.4 - NetBSD version 0.8 - Utilities for 386BSD and NetBSD - The Berkely Second Networking Distribution - GNU software (gcc 2.4.5, emacs 19.17, gmake 3.68, etc) - X11R5 up to patch 25 and lots of Contributed Software - TeX version 3.14 - The Internet RFCs up to RFC1493 - News, mail and mailbox software and many utilities for Unix To: CDROM Versand Helga Seyb Fuchsweg 86 Tel: +49-8106-302210 85598 Baldham Fax: +49-8106-302310 Germany Bbs/Fax: +49-8106-34593 (Ed. Note: This appears to be an advertisement, but the price is right and appears to be reasonable. Christian and Helga may have the same last name by coincidence :-) If you want more ordering information, please feel free to give Helga a call.) ----------------------------------------------------------------------- In Munich Germany: Buy the monthly "c't magazin fuer computer technik" (Price 8.5 DM) (~1.7 = $1) & look in back pages, I saw: Mail Order: JF Lehmanns Buchhandlung, fuer EDV, Zuelpicher Str 182, D-50937 Koeln, Germany Free catalogue for X, Linux, 386bsd, unix. Confusing advert seems to offer X11R5 + GNU + 386BSD on CD Rom "InfoMagic Vol2 No2" for Price: 149 DM. Tel. 0130 4372 (always busy, claims to be free, so don't know if +49 130 4372 viable) Fax: +49 221 415995 Shops in Berlin, Koeln, Regensburg, Ulm. (Editorial Notes: DM149 is about $75-$90 US (or a little more) and 0130 numbers are Toll Free in Germany only.) Mail Order: Computer Solutions Software GmbH Postfach 1180, D-85561 Grafing (Muenchen), Germany Tel +49 8092 5018 Fax +49 8092 31727 23 * 3.5" 1.4M flops @ Price: DM199 Order No:/Best Nr: 5099 Shop: Columbus Datentechnik, Theresienstr 63, D-80333 Muenchen, Germany Tel +49 89 5232021 Lynne wrote a short follow-up, letting us know that these companies do not send them any money. This announcement in from Jordan Hubbard: On the morning of 30 December, 1993, and after many many delays, the first official release of FreeBSD 1.0 began shipping on CDROM. This CD is being sold through Walnut Creek CDROM, our ongoing sponsors in the FreeBSD project, and without whom we would have had a substantially more difficult (if not impossible) time producing it. While I will _always_ encourage obtaining FreeBSD through "free" channels (the Internet, friends, suspicious individuals in dark alleys), and given that none of us will make any money from CD sales, or ever have from FreeBSD in general given that WC's sponsorship is confined to the loan of centralized development hardware and network access, I still hope that some of you will find the CD distribution medium convenient enough to order a FreeBSD CD from Walnut Creek, thus indirectly supporting our future development work. If this marriage between commercial and free software interests proves to be mututally beneficial (which still remains to be seen, from Walnut Creek's point of view), it is my hope that it may serve as a model for similar future endeavors. It is an unfortunate fact that developing free software at this scale costs money, even with the developers donating their time and efforts, and financing some of it through the sale of convenient distribution media is one of the least venal ways I know of going about it. This CD contains a full FreeBSD 1.0.2 source & binary release, the sources and binaries for XFree86 2.0, and numerous sources from the FreeBSD "ports collection". Where space permitted, sources were provided in both "packed" and "unpacked" forms for easy access both as an on-line resource and as a source for compressed downloads in BBS or release-construction situations. The CD is fully ISO9660 compatable and has been mastered using RockRidge extensions for long filenames on systems that support it (like FreeBSD! :-). It is, of course, possible to install the system off the CD from scratch, given some basic willingness to read a little documentation and a few blank floppy disks. [ Ed Note. You would be surprised the number of people that do not see this paragraph...DBB] For the sake of convenience, I append the ordering information distilled from FreeBSD's /usr/src/RELNOTES.FreeBSD below. Ordering information: Walnut Creek CDROM 4041 Pike Lane, Suite D Concord CA 94520 1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax) Or via the internet from orders@cdrom.com. A current catalog can be obtained via ftp from ftp.cdrom.com:/cdrom/catalog. Cost is $39.95. Shipping (per order, not per disc if ordering multiple disks) is $5 in the US, Canada, or Mexico and $10.00 overseas. They accept Visa, Mastercard, American Express, and ship COD within the United States. California residents please add 8.25% sales tax. In addition, John Cargille publishes a CD-ROM which caters primarily to the NetBSD crowd. It is called BSDisc and it is also available by mail. While that may seem like terrific news, it is unfortunately all the information I have right now. Once he sees his name in the FAQ, maybe he'll put together some real ordering instructions ;-) roman@public.btr.com (Roman Yanovsky roman@btr.com) sent in this note. I have editted it down some, but left in the bulk of the stuff in case you need more information: Subject: Linux Slackware and FreeBSD CD-ROM with X-windows etc. Trans-Ameritech presents "The best Linux plus FreeBSD CDROM ever" [ Linux stuff deleted ] * For hacker's reference an uncompressed FreeBSD source tree is provided. * On the BSD side there is a full source and binary distribution of the "final" FreeBSD 1.0 * If you have questions or problems Trans-Ameritech provides free support via e-mail within 24 hours. * We ship the same day as we get the order. The new CDROM is available for $30 plus shipping/handling. If you are a current customer, it is only $20. New releases will be available every 3 month. Subscription is available. Trans-Ameritech Enterprises, Inc. 2342A Walsh Ave. Santa Clara, CA 95051 Tel. 408/727-3883 FAX: 408/727-3882 This information is offered with no warranties, guarantees, franchise offers, or recommendations. 1.6 Electronic Information Groups for 386BSD 1.6.1 Usenet newsgroups General BSD questions can be posted to comp.unix.bsd. Bear in mind, however; that your questions to this group should really be about BSD in general, not a specific implementation detail of *BSD. With the reorganization of the BSD newsgroups, this group name was changed to comp.unix.bsd.misc. Listed below are the old Usenet newsgroups that were developed to support 386bsd and its descendents. This means that you should ask your questions in one of these newsgroups or on one of the many mailing lists that are available for specific features of said systems. comp.os.386bsd.announce (Moderated) Announcements relating to the 386bsd operating system. Posts should be mailed to "386bsd-announce@agate.berkeley.edu". This is also the place that improtant news about the past and future of 386bsd, FreeBSD, and NetBSD will be placed. comp.os.386bsd.apps Applications which run under 386bsd. Not all sites will carry comp.os.386bsd.apps, since it kind of 'showed up'. comp.os.386bsd.bugs Bugs and fixes for the 386bsd OS and its clients. comp.os.386bsd.development Working on 386bsd internals. comp.os.386bsd.misc General aspects of 386bsd not covered by other groups. comp.os.386bsd.questions General questions about 386bsd. There has been a reorgainzation of the *BSD newsgroups since these were originally created. The new newsgroups are as follows: Newsgroup for discussion of general BSD questions: comp.unix.bsd.misc Newsgroups for the discussion of the Bill and Lynne Jolitz version of 386BSD: comp.unix.bsd.386bsd.announce comp.unix.bsd.386bsd.misc Newsgroups for the discussion of the FreeBSD version of BSD 4.4 Lite: comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc Newsgroups for the discussion of the NetBSD version of BSD 4.4 Lite: comp.unix.bsd.netbsd.announce comp.unix.bsd.netbsd.misc Newsgroups for the discussion of the commercial version of the BSD 4.4 Lite system: comp.unix.bsd.bsdi.announce comp.unix.bsd.bsdi.misc 1.6.2 Newsgroup archives. These sites maintain a historical record of the traffic in the Usenet Newsgroups indicated. There are others, but I haven't gotten their names yet. Host Name IP address Location Newsgroups archived -------------------- -------------- -------------- ---------------- minnie.cs.adfa.oz.au 131.236.20.70 Australia comp.unix.bsd, comp.os.386bsd.* src.doc.ic.ac.uk 146.169.2.1 London, UK comp.os.386bsd.* 1.6.3 386bsd Derived mailing lists. With the elimination of the old 386bsd mailing lists, the only mailing lists that are still available are the ones for FreeBSD and NetBSD. Information about the NetBSD lists and how to use majordomo (the list handler) is available by mailing to majordomo@sun-lamp.cs.berkeley.edu. There are four mailing lists for FreeBSD and they are: FreeBSD-hackers: for hackers FreeBSD-questions: misc questions FreeBSD-bugs: bug reports FreeBSD-current: discussion of -current (in development) Send to FreeBSD-hackers-request@freefall.cdrom.com to be added to the hackers list, and *-questions-request@freefall... to be added to the questions list. For information about the NetBSD mailing lists, see the NetBSD Mailing List FAQ that is posted regularly by Chris Demetriou in comp.os.386bsd.announce. 1.6.4 Other electronic resources. There are many bulletin boards throughout the world that have 386bsd software and information available. Also, there are CompuServe and other on-line services that have 386bsd discussions. It is even rumored that Bill and Lynne have been active on Compuserve talking about 386BSD Version 1.0 (or 0.2, or whatever it is going to be). There are also IRC discussions on the net, but I don't have any more information than that right now. 1.6.5 System Updates. There are at least two different ways of getting the updates for the current source tree for both FreeBSD and NetBSD. The first is the traditional FTP method, and the other is using a utility called 'sup'. This program keeps a log of the source modules that have been updated and sends out only those files that have been changed. Included below are some sample instructions from John Brezak on how to run sup for NetBSD. The sup procedures for FreeBSD are similar and are available via ftp from freefall.cdrom.com in the ~/ftp/pub/sup directory. This directory contains the sup program, a man page, a sample sup-file and full instructions for maintaining your sources via 'sup. Instructions for installing NetBSD sources and releases using SUP ----------------------------------------------------------------- 1.3 1993/11/3 SUP is a network installation package written by CMU used to distribute software. For more details on SUP refer to the man pages. Sup works by reading a configuration file (supfile) and using this information to determine what "collections" of files will be loaded from the collection repository. Here is an example of a supfile to load the NetBSD current release. [ Notes: lines have been broken for readability; do NOT use '\' in supfiles and the information here is an EXAMPLE. This ain't a cooking school, folks. Also, the information in these lines has changed for each of the distributions. Read the documentation that comes with your software carefully for the lastest information. ] src release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup ksrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup security release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup gamessrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup regress release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup #othersrc release=current host=sun-lamp.cs.berkeley.edu hostbase=/b/anon_ftp base=/usr prefix=/usr backup This supfile will load the "current" collections for "src", "ksrc", "security", "gamessrc", and "regress" in the /usr directory on the local machine. The "othersrc" collection will not be loaded because it is commented out. The supfile line is made up of keywords that describe the collection's location on the sup server and where and how it will be loaded on the local host. release - the release of the collection to load. host - the 'host' where the SUP repository resides. NetBSD uses sun-lamp.cs.berkeley.edu . hostbase- the pathname on the host to the base of the collection. The hostbase for NetBSD is "/b/anon_ftp". base - where you want to install it locally. prefix - used to locate the "sup" directory to write sup's info about updates. Usually the same as base. This supfile can also set some options. The "old" option tells sup to check all files for changes, not just those that are newer than the last sup update. Normally sup will overwrite local files with the changed file from the repository. If the sup collection specifies that an existing file should be renamed to a backup, the "backup" option in the supfile activates this. The "delete" option tells sup to delete any files locally that are no longer in the collection - be careful with this one. The "keep" option will cause sup to NOT update files that have been changes locally. The "compress" option will use gzip to compress the files before transfer and gunzip them on the receiving end. This option can be used to cut down on the number of transmitted bytes. You may want to set 'base' and 'prefix' to something other than /usr if you want to preserve your existing src tree. The sup repository on sun-lamp.cs.berkeley.edu currently offers these collections. src, ksrc, security The sources for NetBSD othersrc The current sources for contributed parts of NetBSD. This contains the sources for sup. regress The current sources for the NetBSD regression test suite. If you only want the kernel sources for a specific port there are some sub packages that you can use instead of the "ksrc" one. If you are using the sub packages, be sure to also sup the "ksrc-common" package. ksrc-common Kernel sources common to all ports. ksrc-1, ksrc-sparc, ksrc-hp300, ksrc-amiga, ksrc-mac, ksrc-pc532, ksrc-pmax, ksrc-sun3 Kernel sources for a particular port. The security package is not to be sup'ed by sites outside of the U. S., read the "README.export-control" file for details. Each collection can have multiple releases (as specified by the "release" keyword). IMPORTANT!! Be aware that the current release is simply a snapshot of the daily state of NetBSD development and is not guaranteed to build (or even work) - use at your own risk ! Stable releases of NetBSD are available via SUP. Instructions are included with the release announcement. Before running sup, be sure that your /etc/services contains these entries. supfilesrv 871/tcp # for SUP supfiledbg 1127/tcp To try sup without really updating anything use the '-f' flag. The '-v' flag means verbose and can be used to see what sup is doing. sup -fv supfile The sup binary, sup man page and sample supfiles can be ftp'ed from sun-lamp.cs.berkeley.edu:~ftp/pub/sup . Comments should be directed to "sup@sun-lamp.cs.berkeley.edu". A mailing list exists for users of the NetBSD "current" release. To join, mail to 'majordemo@sun-lamp.cs.berkeley.edu' with a mail body of "info". The reply will describe the mailing lists for NetBSD. The you will want to subscribe to the "current-users" mailing list. We will use this list to announce any special changes made to the "current" tree. 1.7 Documentation available This entire section pertains as much to NetBSD and FreeBSD as it does to 386BSD. Simply 'sed 's/386bsd/Your System/g' below. There are two types of documentation for 386bsd. First is the set that covers the operation and theory used in BSD-Unix. These sources are often excellent for background and understanding of the current implementation of 386bsd. Second is the set of manuals written specifically for 386bsd. Most of these are books and magazine articles written by Bill and Lynne Jolitz. 1.7.1 BSD manuals The full set of BSD documentation is available via anonymous FTP from ocf.berkeley.edu in /pub/Library/Computer/doc4.3. To print this documentation on 386bsd systems, replace the ditroff references in the Makefile with 'groff -e -t -msU {SRC} >out.ps' to generate PostScript format files. Use different options to make the output conform to other print styles. The etc distribution also comes with a documentation directory /usr/share/doc which has nearly 3Meg of documentation about *BSD. In addition, on-line manuals are available in the binary distribution set. It contains specific information on the use of UNIX utilities and commands. Type "man man" for information on the online manual. 1.7.2 BSD books There is an excellent set of works recommended by Bill and Lynne in the original 386bsd INSTALL.NOTES. In addition, several other books have been recommended by Andrew Moore and others. For learning how to work in the Unix environment, the standard text is "The Unix Programming Environment," by Kernighan and Pike. For Unix Administration, the best is "Unix System Administration Handbook," by Nemeth, Snyder and Seebass. For systems level programming (i.e., systems calls), I recommend "Advanced Unix Programming," by Marc Rochkind. Unfortunately it is out-dated and oriented towards System V. A new book "Advanced Programming in the Unix Environment," by W. Richard Stevens is very up-to-date, and an excellent reference, especially for dealing with POSIX standards issues. For network programming, "Unix Network Programming," by W. Richard Stevens is highly regarded. The 4.3BSD Unix Manuals contain loads of invaluable tutorials and historical papers in addition to hard copies of on-line documentation. The six volume set is available from Usenix for $60.00 (email: office@usenix.org) The 4.4 BSD Unic Manuals are the authoritative source for information about the 4.4 BSD release, and by inference the NetBSD and FreeBSD systems. They are available from O'Reilly and Associates (the Nutshell series people). In addition the the six volume set, there is a CD included (at a price) of the entire 4.4 release. Combine this with the NetBSD 1.0 or FreeBSD 2.0 systems, and you should have a commercial quality operating system available in no time. I could go on, but let me mention just two more - if you have a full 386BSD installation, you may want to learn the bash shell (in /usr/othersrc/public). This is an extension of the Bourne shell (sh) with features from both the C shell (Csh) and the Korn shell (Ksh). The Korn shell is described in "The Kornshell," by Korn (of course). Second, I recommend you look at "The AWK Programming Language," by Aho, Weinberger and Kernighan. This is a very nice prototyping language - powerful and easy to use. Another excellent reference book for 386bsd is "The Design and Implementation of the 4.3BSD UNIX Operating system" by Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S. Quarterman, 1989, Addison-Wesley, ISBN 0-201-06196-1. While this book is out of date in many sections, it is purported to be an excellent source of historical information, if nothing else. Chris Demetriou recommends the sections on the treatment of file systems, caching and the networking layer. The sections in this books which do not apply to 386bsd include the VM section, bootstrapping, and autoconfig. Here is a list from Hellmuth Michaelis (duplicative as it may seem to have all of these lists) for more information on *BSD: UNIX AND UNIX DEVICE DRIVERS ---------------------------- Bell Telephone Laboratories, Inc. "UNIX Programmer's Manual, Seventh Edition, Volume 2". Revised and Expanded Version. Holt, Rinehart and Winston 1983 George Pajari, "Writing Unix Device Drivers" Addison Wesley 1992 Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver" John Wiley & Sons 1988 Janet I. Egan and Thomas J. Teixeira, "Writing a UNIX Device Driver" Second Edition. John Wiley & Sons 1992 Leffler, McKusick, Karels, Quarterman, "The Design and Implementation of the 4.3BSD UNIX Operating System" Addison Wesley 1988, corrected Reprint 1989 Leffler, McKusick, "The Design and Implementation of the 4.3BSD UNIX Operating System, Answer Book" Addison Wesley 1991 Maurice J. Bach, "The Design of the UNIX Operating System" Prentice-Hall 1986 Sun Microsystems Inc., "Writing Device Drivers" Part No. 800-3851-10, Revision A of 27 March 1990 Hewlett-Packard Company, "HP-UX Driver Development Guide", Part No. 98577-90013, First Edition 07/91 W. Richard Stevens, "Advanced Programming in the UNIX Environment", Addison Wesley 1992 Phillip M. Adams, Clovis L. Tondo, "Writing Unix Device Drivers in C", Prentice Hall 1993 Peter Kettle, Steve Statler, "Writing Device Drivers for SCO UNIX, A Practical Approach", Addison Wesley 1993 In addition, there are many other books which, for one reason or another, have not made it into this brief list. Rest assured that this is not intended to be an exhaustive list by any means. 1.7.3 The Jolitz Book Bill and Lynne Jolitz are writing a book about 386bsd. It will be announced once it is ready. A tentative date of late 1992 was once offered, but since it is now 1994 and no book has been announced, we can assume that it will be later than the original estimate. 1.7.4 Dr. Dobbs' journal For users who wish to understand the internals of the BNR/2 BSD family of Operating Systems originally developed and/or ported by William F. Jolitz from 1989 to the present, the most immediate and available reference is the feature series entitled "Porting UNIX to the 386: A Practical Approach", appearing in Dr. Dobbs' Journal, USA (January 1991 to July 1992) and UNIX and iX Magazines, Germany (June 1991 to present). For inquiries on the article series (including reprints), contact the magazines for information. "Porting UNIX to the 386: A Practical Approach" (feature series) by Jolitz and Jolitz 1/91: DDJ "Designing a Software Specification" 2/91: DDJ "Three Initial PC Utilities" 3/91: DDJ "The Standalone System" 4/91: DDJ "Copyright, Copyleft, and Competitive Advantage" 4/91: DDJ "Language Tools Cross-Support" 5/91: DDJ "The Initial Root Filesystem" 6/91: DDJ "Research and the Commercial Sector: Where Does BSD Fit In?" 7/91: DDJ "A Stripped-Down Kernel" 8/91: DDJ "The Basic Kernel" 9/91: DDJ "Multiprogramming and Multiprocessing, Part I" 10/91: DDJ "Multiprogramming and Multiprocessing, Part II" 11/91: DDJ "Device Autoconfiguration" 2/92: DDJ "UNIX Device Drivers, Part I" 3/92: DDJ "UNIX Device Drivers, Part II" 4/92: DDJ "UNIX Device Drivers, Part III" 5/92: DDJ "Missing Pieces, Part I" 6/92: DDJ "Missing Pieces, Part II" 7/92: DDJ "The Final Step: Running Light with 386BSD" You can contact M&T Books (DDJ) for reprints if you can't get them from your technical library: 1-800-356-2002 (inside CA) 1-800-444-4881 (better In NA Backorder number) 1-415-358-9500 (international) 6/91: UNIX Magazin "Portierung von BSD-UNIX auf den 80386. Heimlich Liebe." 7/91: UNIX Magazin "Steighilfe." 8/91: UNIX Magazin "Systemverwaltung durch Tabellen" 9/91: UNIX Magazin "Sicher bewegen auf fremdem Terrain" 10/91: UNIX Magazin "Damit die Fehlersuche nicht zum Hurdenspringen wird" 11/91: UNIX Magazin "Alles in eine Schublade" 12/91: UNIX Magazin "Feuer und Wasser" 1/92: UNIX Magazin "Rekursives Speicher-Mapping" 2/92: UNIX Magazin "Tanz auf dem Eis" 3/92: UNIX Magazin "Aus Hanschen wird Hans" 4/92: UNIX Magazin "Das Geheimnis des Multiprogramming" 5/92: UNIX Magazin "Zeitmanagement scheibenweise" 6/92: UNIX Magazin "Magie des Kernels" 7/92: UNIX Magazin "Erkenne Dich Selbst" 9/92: UNIX Magazin "Niemand is eine Insel" 10/92: UNIX Magazin "Treiberlatein" 12/92: UNIX Magazin "Einlandung erforderlich" 1/93: iX Magazin "Wir unterbrechen das Programm" 2/93: iX Magazin "Liste gut, alles gut" 3/93: iX Magazin "Blick ins Allerheiligste" 4/93: iX Magazin "Von Bl"ocken, Ringen und Zeichen" NOTE: The series in UNIX Magazin was moved to IX Magazin in 1/93. The article in the April issue was the last one in the series. In addition, other major articles which discuss 386BSD in detail: 8/92: UNIX Magazin "Interview mit Bill Jolitz. Das passiert mit 386BSD" by Jurgen Fey 8/92: DDJ "Very High-Speed Networking" by W.F. Jolitz 12/92: DDJ "Inside the ISO-9660 Filesystem Format" by Jolitz and Jolitz Reprints of the first 19 parts on the UNIX Magazin series are available from: iX Redaktion Stichwort: 386BSD-Serie Verlag Heinz Heise GmbH & Co KG Helstorfer Str. 7 D-30625 Hannover, Germany Some of the parts are without code listings due to the unclear status of the BSD releases stemming from the Net/2 release. Dr. Dobbs is reported out of back issues of the articles listed above. You best bet may be to try your local public or school library. 1.7.5 Documentation that comes with most of the distributions. In the standard set for both NetBSD and FreeBSD there is a directory called '/usr/share/doc'. Here is a 'du' listing. 128 /usr/share/doc/ps1/06.sysman 98 /usr/share/doc/ps1/07.ipctut 116 /usr/share/doc/ps1/08.ipc 16 /usr/share/doc/ps1/13.rcs 37 /usr/share/doc/ps1/14.sccs 420 /usr/share/doc/ps1 123 /usr/share/doc/smm/02.config 14 /usr/share/doc/smm/04.quotas 78 /usr/share/doc/smm/05.fsck 42 /usr/share/doc/smm/06.lpd 92 /usr/share/doc/smm/07.sendmailop 14 /usr/share/doc/smm/08.timedop 99 /usr/share/doc/smm/10.newsop 83 /usr/share/doc/smm/11.named 77 /usr/share/doc/smm/14.fastfs 128 /usr/share/doc/smm/15.net 41 /usr/share/doc/smm/16.sendmail 21 /usr/share/doc/smm/20.termdesc 17 /usr/share/doc/smm/22.timed 851 /usr/share/doc/smm 144 /usr/share/doc/usd/04.csh 97 /usr/share/doc/usd/07.Mail 66 /usr/share/doc/usd/09.newsread 68 /usr/share/doc/usd/10.etiq 67 /usr/share/doc/usd/14.edit 107 /usr/share/doc/usd/15.vi 61 /usr/share/doc/usd/16.ex 13 /usr/share/doc/usd/21.msdiffs 45 /usr/share/doc/usd/22.memacros 43 /usr/share/doc/usd/23.meref 26 /usr/share/doc/usd/33.rogue 25 /usr/share/doc/usd/34.trek 798 /usr/share/doc/usd 2077 /usr/share/doc For those of you that don't read 'du -k' listings, this means that there is 'around' 2 MEGABYTES of documentation in the 'doc' directory. In addition, there are a few man pages. 2312 /usr/share/man/cat1 397 /usr/share/man/cat2 1 /usr/share/man/cat2a 855 /usr/share/man/cat3 1 /usr/share/man/cat3f 607 /usr/share/man/cat4 368 /usr/share/man/cat5 166 /usr/share/man/cat6 169 /usr/share/man/cat7 749 /usr/share/man/cat8 Something on the order of another 4 Megabytes of manual pages. That's what, about 6 MILLION CHARACTERS of documentation. I have received mail from several sources saying that my approximation of the amount of system documentation is way too low (by a factor of at least 50%). Given the fact that even by my meager estimation there is already more information here than most people can be bothered to read, whether there is 6 Meg or 60 Meg seems like overkill. Now, does anyone REALLY want to whine about there being no documentation included with the system? 1.7.6 Other FAQ's on the net that are relevant There is now a FAQ set up specifically for FreeBSD. In addition to answering the many specific questions that folks have about FreeBSD, it is also a good source for information on NetBSD and whatever the 386BSD {0.2,1.0,95} project is going to look like. In spite of all of the shouting and chest beating that you hear from time to time, the systems are still very close. There are many FAQs that can be used in conjunction with 386bsd. These include the FAQs for all of the GNU software, the different shells that are available, the programming languages that are available, and many more. In addition, many programs have their own FAQ which should be referenced whenever that package is being added. Good examples of the latter are the FAQs for elm, C-News, and innd. The observant reader will notice that there are very few 'X' questions in this FAQ. The XFree86 FAQ is posted regularly to comp.os.386bsd.*. There is no good reason to include any 'X' questions in this FAQ, with the exception of the most basic 'Where can I get the 'X' FAQ'. Most FAQs are available by anonymous FTP from rtfm.mit.edu and via Usenet News in news.answers and/or comp.answers. This FAQ is no exception (I hope). 1.8 FTP sites for 386BSD A standard tool on Internet connected hosts for finding files is 'archie'. Searching the archie archive for either "386BSD" or "386bsd" yields the following list. For UUCP sites, FTP-Mail is available from gatekeeper.dec.com. The list below was created with an 'archie -l' on 26 Mar 1995 searching for FreeBSD. For those folks that have access to telnet, but not FTP, you can use archie by using telnet and connecting to 132.206.2.3. Log in as 'archie' and use the 'prog' command to find programs of interest. The list below is included primarily for those folks that have only uucp, and will need to get their software though UUCP and other channels. 1.8.1 FTP Site List This list is automatically generated every time the FAQ is produced. Please do not request that your host be added to this list. If your host is represented in an 'archie' list, it will be reflected here. Several other sites are included in Section 1.8.4 below. Host Directory The code may soon also to be available, or perhaps is already available, from both CompuServe and BIX. 1.8.2 Official distribution sites According to Lynne Jolitz, there is no such thing as an 'official' 386bsd site. The closest we had was 'agate.berkeley.edu' which is now closed. Because of the USL/UCB agreement, 386bsd is no longer freely redistributable, since it was based on Net/2 and Net/2 was encumbered. FreeBSD's 'home' is FreeBSD.cdrom.com (the home disk of Walnut Creek). The portions of FreeBSD (versions less than 2.0) that were encumbered are distributed with the tolerance of AT&T/USL/Novell/whoever owns the source for SysV this week. All FreeBSD versions (with version number >= 2.0) are based solely on the freely redistributable BSD 4.4 sources. NetBSD's 'home' is now ftp.NetBSD.Org. All versions of NetBSD since 0.9 have replaced the kernel code from the 4.3 distribution with the source from the 4.4 distribution. The only code still in NetBSD from the 4.3 distribution is some user program code that was uncontested in the USL/UCB agreement. 1.8.3 Reference sites For a brief period, ref.tfs.com was available for use as a reference system. This system was used as the test-bed for many programs that were ported to 386bsd by many authors. Unfortunately, ref.tfs.com has been disabled as a reference system. The site is now a update by mail (CTM) system and is providing a mail only service for developers who do not have access to anything more than electronic mail. For more information, contact phk@freefall.cdrom.com for the standard CTM package. There is a site in Germany that is acting as a reference site for FreeBSD. The name is "g386bsd.first.gmd.de", also known as "bsd386.first.gmd.de". Sorry, no anonymous ftp yet. But there is a "guest" login with the password "guest". But the most important reason why I had installed the machine on the network was for all these people who don't have enough space to compile their own kernel or their own packages. They can do it on this machine. ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de ) 1.8.4 Unofficial archive sites that have neat stuff! There are many sites that have things which have either been ported to 386bsd or are available to the world. Use archie to find these sites, or read comp.os.386bsd.* for more information. Listed here because they don't have access to 'archie' yet... g386bsd.first.gmd.de -or- bsd386.first.gmd.de: Sources for 386bsd0.1 and the later patchkits. Source for NetBSD0.8 and the newer snapshots. Xfree is installed binary as version 1.3. Ported software are: tcsh6.03.00 emacs19-15 gcc-2.4.5 top3-1 perl4.0.36 elvis1.7 bison-1.21 rn and nn. In addition, ftp.cs.tu-berlin.de has a lot of neat software and Wolfram Schneider (wosch@cs.tu-berlin.de) has 'ported' the FAQ into LaTeX. It is available in pub/386BSD/FAQ/tex in both PostScript and DVI formats. 1.8.5 X for 386BSD 0.1 Ported Software List This is a list of non-core X window system application that have been ported to 386BSD 0.1. The ftp server and directory name are listed above and each file or directory name is followed by a short description. Feel free to send corrections, additions or suggestions to rich@rice.edu. nova.cc.purdue.edu:/pub/386bsd/submissions Xdtm-2.5.386bsd X desk top manager idraw-bin.tar.Z C++ GUI class library + WYSIWYG document & graphics editors. img1.3.386bsd.tar.Z see above mpeg_play.Z animated raster image viewer small_X11r5.tZ a minimal subset of the core distribution vogl.tar.Z a library that emulatates Silicon Graphics GL calls xview3 sun's GUI development tool kit sunvis.rtpnc.epa.gov:/pub/386bsd/incoming: Dirt.tar.Z GUI development tool kit XBSD8514-0.1.Z 8514 X server port XS3-0.3-exp.Z S3 X server port acm.tar.Z aerial combat mission/flight simulator chess-vort-movie.tar.Z ? epoch.Z enhanced emacs for X jpeg.tar.Z jpeg viewer libXaw3d.a.Z 3D widget library mpeg-1.2.tar.Z animated raster image viewer ups-2.45.bin.tar.Z C source level debugger with slick GUI vort-movie.tar.Z ? xantfarm.tar.Z screen saver with ants? xbench.tar.Z X server performance measurement tool xpipeman.tar.Z game: connect pipes to keep a liquid within xxgdb.tar.Z GUI for GNU source level debugger 1.8.6 Motif for the *BSD family. (Infomercial to follow) While I don't normally include commercials in the FAQ, I will this time. Motif is an interesting product that will help the development of the free Unices. It can also serve as a benchmark for other commercial organizations to consider supporting us by producing versions of their products that will work on these systems. Sequoia International, Inc. (305-783-4915/305-783-4935 (FAX)) sells a complete Motif 1.2.3 Runtime and Development package for FreeBSD, NetBSD, BSD/386, Linux, and Coherent. It is available for $149.95 and includes the following: * The Motif Window Manager (mwm) * Shared Library (libXm) [operating system dependent] * Static Libraries (libXm, libMrm, libUil) * Header and Include Files * Complete On-Line Manual Pages * Source code to OSF/Motif Demo programs * Complete OSF/Motif Users Guide Send mail to info@seq.com or contact them at the address below: Sequoia International, Inc. 600 West Hillsboro Blvd, Suite 300 Deerfield Beach, FL 33441 Phone: (305)783-4915 / FAX: (305)783-4935 / Email: info@seq.com -- Dave Burgess (The man of a thousand E-Mail addresses) 386bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom "Just because something is stupid doesn't mean that there isn't someone that wants to do it...." From csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail Thu Apr 13 15:16:22 1995 Path: csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 3 of 10) Supersedes: <386bsd-faq-3-795078010@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 27 Mar 1995 01:00:23 -0600 Organization: Dave's House in Omaha Lines: 1963 Sender: burgess@cynjut.infonet.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 04/14/95 02:00:10 CDT Message-ID: <386bsd-faq-3-796287611@s069.netins.net> References: <386bsd-faq-1-796287611@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.infonet.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:16 comp.unix.bsd.freebsd.announce:15 comp.answers:10852 news.answers:40662 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part3 Section 2. (Common installation questions) 2.0 Install process The 386bsd system is distributed in many ways. One of the most common is via DOS diskettes, (either 3 1/2 or 5 1/4, both high density) with the actual distribution being a 'CPIO archive' broken into 240K pieces. This allows the distribution to fit onto a minimum number of floppies. Once the files are on floppies, thoughts usually turn to questions about how to install the boot image on a floppy. The rawrite program (for DOS) is used to write the bootable images (dist.fs and fixit.fs) onto floppies. The same image can used for 3 1/2 and 5 1/4 high density diskettes. Low density diskettes are not supported in this version of 386bsd. NetBSD uses the same file extension for its floppy images. FreeBSD uses the .flp extension. Once the bootable images are written onto the floppies, insert the dist.fs disk into the A: drive and reboot. If the system does not boot, see section 2.5 below for more information. If the disk boots, type install and proceed to use the INSTALL.NOTES to get more information. Problems with the install are either related to hardware (i.e. Do you want to install on your T.V.?) or software. Of the hardware issues, the most common FAQs are usually straight out of the installation notes. Of the software issues, there are only two that really concern us. The first is bad files. On some systems, files that are loaded from floppy appear to 'go bad' when they arrive on the hard disk. Try some of these solutions: - You forgot binary. Don't get insulted. Those of us that FTP for a living forget sometimes. If so, the distribution will come out with all different sizes and install will complain about every disk. - One or two of the files are no good. Try getting them again. As a precaution, rename the bad files on your hard drive to names like foo.1 and bob.23. Copy the files again from floppy. If they are still bad, rename the file, and the one immediately before the first bad file (bin01.23 if bin01.24 is bad) and copy them again. If they are still bad, download those files again from the distribution site (including the one before and after the bad one) and try again. The reason for renaming the files is that sometimes, especially with drive that do not auto-magically record bad sectors, you could copy a distribution file onto a bad spot on the disk. If this happens, you want to isolate the bad spot. The easiest way to do that is just leave the bad file on it. Keep trying, these same files have been used by literally thousands of people to install 386bsd. For those of you that have received your system on a CD-ROM, you will need to find at least three things. One is this file. Since you are reading it, I assume that you got it already. :-) If you can't read this file (you got it from the newsgroup, for example) there is one thing that you need to know so you don't look like a complete idiot on the net. There is no such thing as a Unix CD-ROM. They are all in something called the ISO CD-ROM format. You can read them as the D: drive in DOS, or mount them on your Sun or SVR4 system or whatever. Second, you will need to find the directory with the bootable disk images in it. They will have self explanatory names like: kerncopy.fs base0-9.fs fred.fs genericaha.fs boot-me-first.fs this-is-the-file-with-the-fs-extension.fs You get the idea, right? Look for the MS-DOS program "RAWRITE.EXE". It should be right near the file system (.fs) files. Another clue for the truly lost will be that the file system files will all be 1.2 Meg big. These files will fit onto either a 1.2Meg 5.25 inch diskette, or a 1.44Meg 2.5 inch diskette. Use rawrite to write the fs files to diskettes and boot from the diskettes. The FreeBSD system uses a system 'pretty much' the same as this, except that the filesystem files are 1.2 Meg files and they all have a '.flp' extension. Other than that, the instructions apply. You did back your system up, right? 2.0.1 Boot disks (versions and media formats) There is currently one official 386bsd 0.1 boot disk, referred to as the "Tiny" boot disk. Because of the nature of the agreement between USL and Berkeley, it is rapidly becoming impossible to get 386bsd 0.1 diskettes. The archive at agate.berkeley.edu has been eliminated completely. The NetBSD archive that was there has also been eliminated. There are a few FAQs from the boot/install disk. 2.0.1.1 Where does extract go when I reboot? It was in /tmp, which is cleaned the first time you reboot the system from the hard drive. If you have just booted from the hard drive for the second time, chances are you just wiped out extract. It is not really needed, since the instructions for building your own install are included in section 2.5.2 of the FAQ, under custom installation. When installing NetBSD, the set_tmp_dir and extract programs are part of the .profile that is booted when you are installing. This .profile is overwritten as part of the install process, and extract then disappears. If you need extract again, you can mount the install disk and source .profile. This will recreate these two routines. There is also an install procedure that FreeBSD uses that does the same job. It is defined as part of the .profile on one of the installation floppies. You can either copy it from there, or use the procedure for 'real disk partitioning'. 2.0.1.2 I put the floppy in and try to boot, and nothing happens. What now? There are lots of possibilities. We will start with the oldest (386bsd 0.1) problems. This is usually referred to as the Compaq boot problem. The easiest solution is to get a patched boot disk. Another source of possible hope for you is to grab the NetBSD bootable disks. They are compatible with 386BSD and allow you to install on some of the more recalcitrant hardware. The FreeBSD install process is said to be better than the NetBSD program for some machines. Could be. They are all available for free from the net. Try it. 2.0.1.3a The floppy booted, but now the hard disk won't boot? 2.0.1.3b I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk? The most likely culprit is your hard disk controller. It is probably doing some type of disk translation for you. If this is the case (assume it is) then you will need to find out the real disk controller geometry, and rewrite your disk label. See section 2.6.2, but before doing that get the program pfdisk.exe. This program will tell you what the controller geometry is (right before it reboots your computer). Make the disklabel agree with this program and your system should boot. You may have to reinstall, but at least your disklabel will be right. Note that this is a nearly required step for all NetBSD and FreeBSD installs. You need to know what the disk geometry is before the BIOS messes with it. If you start having these kinds of installation problems, I can virtually assure you that it is because your controller geometry and your disklabel geometry are different. NOTE: If the hard disk controller does NOT have an option for turning off the geometry, you may well be completely out of luck. There are very few controllers that fall into this category. The ones that do full time translation will often boot up in translated mode. pfdisk will help you determine the correct geometry for your drive by telling you what the geometry looks like when 386bsd boots up. But on the other hand, maybe not... See section 2.5.5 below for a detailed set of instructions about getting NetBSD (and by implication 386BSD and FreeBSD) to work with a system that uses full time translation. 2.0.1.4 What are the options on the boot prompt? The most amazing thing about the boot process in *BSD is the boot up alternatives that are available. There is little that a person can NOT do from the boot prompt. The boot diskette or disk can be selected (fd(1,a) for fd1a (my B: drive is DOS)) can be the source of my kernel. In addition, the name of the kernel can be chosen (this allows you to boot with a test kernel or reboot an older kernel if the new one gets hosed). Finally, there are three choices for options that may or may not work, depending on the age and proclivities of your boot blocks. These options are: -s............... boot into single user mode -a............... ask the user what device to use as root just before mounting it (Not presently supported) -d............... once you have the kernel loaded and VM and such up and going, drop into the kernel debugger. Great for debugging probe code. ( not sure if this is presently working) I have noticed that there is a fourth one. I'll write it up later. 2.0.1.5 I just used the '-s' option on the boot, but I can't write anything onto the disk. What is wrong? If I use a plain 'mount' command it tells me that my root file system is read-only. In single-user (system booted with -s or an error in one of the processes started by /etc/rc) the root filesystem mounts as read-only by default. This was intended so that some range of problems would not be made worse by writes to the disk. The 'dos' partitions mount as read-only in that there are reservations as to how well some of the FreeBSD tools work with the pcfs. The same kind of reservations exist with NetBSD and the '-t msdosfs' option. These options (-r for read-only, -w for read-write) can be set in /etc/fstab. The status of both can be changed with 'mount -wu /{mount.dir}' (where {mount-dir} is the name of the directory that the offending partition is mounted) to read-write. Particularly for the dos filesystem, the man page for mount should be read in detail and the 'noexec' option examined. Note that mounting the file systems using the '-a' option will mount all of the file systems that are normally mounted with their usual read-write bits set normally. Using this option makes your root partition writable, and also mounts the rest of the partitions in your /etc/fstab that are normally mounted during boot-up. 2.0.2 Fix-it boot disk The fix-it disk contains a series of programs that are particularly handy for 'fixing' your disk in case you can't get logged in. It includes the disklabel program and other utilities for system maintenance. For NetBSD and FreeBSD, you will probably have to build your own Fixit disk. You can mount the original file system floppy and beat it to death if you want. Put programs on it that you will need to build a new system. As I think of them, I will put them in. 2.1 Binary distribution The binary distribution 386bsd 0.1 consists of virtually all of the programs that a typical *nix system would be expected to have. The list includes mail, UUCP, GCC version 1.39, and others. Known problems with the binary distribution include the following: 1. Mtools as shipped in the bindist does not always work. The ones on the install disk seem to work fine. 2. The install script built into the binary distribution does not correctly install all of the files and symbolic links that it should. For example, some of the symbolic links to the /usr/include directory are botched up. 3. 'tip', the modem control program, does not always work right out of the box. 4. Any program that relies on a valid symbol table in the kernel (e.g. ps) will not work because the kernel is stripped so that it will fit onto the bootable disk. These problems are all cured either by patches available in the patchkit, or through re-compilation. FreeBSD and NetBSD have solved these problems. This information is included primarily for those few people that get sucked into using an old version of 386bsd for a class or something. 2.1.1 I want to install by NFS but I am having all kinds of problems. There is an unusual problem when installing over NFS. This solution may have been corrected in the documentation that comes with FreeBSD and NetBSD, but if not, here it is. The most common problem seems to be that FreeBSD (and by inference NetBSD and all the other 4.4 based systems) do not send out NFS requests over privileged ports. Sun's NFS implementation (and others, once again by inference) expect precisely the opposite. These systems will quietly fail if you try to NFS to them. The usual error message (which may ONLY appear in /var/adm/messages) is "nfs_server: weak authentication, source IP address=xx.xx.xx.xx" SunOS is particularly insidious at this point. The mount succeeds, but then everything else after that fails. This means that your FreeBSD or NetBSD system will return ann EACCESS error whenever you try to grab a file from the NFS filesystem. The solution (tested in FreeBSD) is to include the 'resvport' flag like this: # mount -o resvport server:/fs /mnt_point or to use the -P flag (which does the same thing). See the mount and mount_nfs man pages for the details. In fact, the -P flag provides a solution to the FreeBSD NFS installation problem. When prompted for server/filesystem, type in the flag before the server/filesystem pair: -P server:/fs If you are using an 8-bit network card, and want to avoid the ring buffer overflow problems that seem to come standard with this class of cards, you can also include the "-r4096 -w4096" flags between the -P and the server. 2.2 Source distribution The source distribution 386bsd 0.1 contains all of the source code for every program in the bindist. Known problems (which are fixed in the patchkit) include the following: 1. There is an error message during install about install.src01 not being found. It is not an error, there isn't an install.src01. Think of it as Bill and Lynne's idea of a practical joke. 2. There are several symbolic links that are not made correctly. In addition, there are several files that should have been deleted (to ensure clean 'make's) before the files were packed. This is fixed by the patchkit, as of 0.2.3. 3. The /usr/src tree does not compile cleanly. This is fixed by the patchkit, as of 0.2.3, or by NetBSD or FreeBSD. 2.3 Additional software distribution The etc distribution contains source trees for many programs that are of interest to 386bsd users. The complete ISO software development environment, as well as many additional software packages (and all of the games) are included in this distribution. The most common problem with the etc distribution is the error "too many files open". Followed closely by "install.etc01 not found". The latter is a annoyance (see above) but the former can be easily overcome in a couple of ways. The "too many files open" is a result of the "cat" command leaving files open after it has read a file. Dwight E. Cass (his Email address is dec@lazarus.nrtc.northrop.com) has provided us with this anecdotal work around for his own experiences: -------------------------------------------------------------------- So - back to installation. This time, when I get to the etc01 partition, I am a bit more awake, so I run it from Csh (with the open file limit at 256). Works pretty well - but complains at the end that it could not do the final configuration because it could not find the configuration file - I checked the MANIFEST and the file is not there, so I finally decided to ignore the message (but it was bothersome!) Once etc01 was done - source was easy ... and I am now up and running, and quite impressed!!! -------------------------------------------------------------------- Another method is to use a loop construct in the Bourne shell. For example: for i in (etc01.*) do cat $i done | compress -d | cpio -idalmu -or- for i in (etc01.*) do zcat $i done | cpio -idalmu will also solve the problem handily. This solution solves the problem by running cat multiple times, with one file each. Since cat now only has one file, there are no limits on the number of files that can be used for the distribution set. 2.4 Patch-kit The patchkit has been completely deprecated. FreeBSD and NetBSD are both mature programs that will serve the average user extremely well. The patchkit may still be available, but it is only required if you are installing the original 386BSD 0.1 version. There are two mailing lists dedicated to the patchkit. They are as follows: 386bsd-patchkit@cs.montana.edu, which is primarily for discussion of up-coming patches and patchkit philosophy. patches@cs.montana.edu, which is dedicated to submitting new, untested patches. The current (and final) version of the patchkit is 0.2.4, which has absolutely no relationship with the new version of 386bsd. It is available by anonymous FTP from several sites throughout the net. 2.5 Configuration By far, the most common configuration questions are partitioning, followed closely by all of the other software in the system. Sendmail and named are also problems occasionally, but the documentation that comes with them usually gets you through. If you run into a problem, post a question to comp.os.386bsd.questions. A less frequently asked question is "Where can I get info on how to configure a kernel?" The answer to this question has been provided by Richard Murphey (Email address rich@Rice.edu). -------------------------------------------------------------------- Ready-to-print PostScript files for each section of the net2 system maintainer's manual are on nova.cc.purdue.edu in pub/386bsd/submissions/bsd.manuals. smm.02.config.ps.Z describes kernel configuration for the VAX, however some of it is relevant to 386BSD. There is no freely available rewrite for 386BSD that I know of. -------------------------------------------------------------------- Most of these manuals are now included in the standard release of NetBSD and FreeBSD in the /usr/share/doc directories. 2.5.1 Partitions This section describes many of the questions that people ask about hard disk partitioning. The first is a brief explanation of the BSD system disk partitions. 2.5.1.1 What is a 'disklabel' and why do I need one? The BSD partition table supplements the DOS partition table. The entries in this table are meaningful to BSD. There are eight partitions in the BSD partition table, and they are normally lettered from a: to h:. This supplemental partition table is often refered to as the 'disklabel'. This tutorial is provided by by "" and provides an excellent overview of the hard disk partitioning procedure from start to finish. "Disk Partitioning for the Compleat Idiot" There are times, in our trials with our computers, that it becomes necessary to mess about with the disklabel. For those not knowledgeable of BSD or Unix Systems administration, this somewhat simple task can be somewhat daunting. This document is the result of my own short experience. This does not cover physical installation of the disk. For those who are having trouble with that, I direct you to any of the fine manuals dealing with hard drives and your hardware. It also does not deal with the vagaries of the DOS partition manager. It assumes you have done that as well, if need be... After the drive is physically installed and is recognized in the BSD startup, and it mentions both your drives, in the order you expect them... Or perhaps just the one, if you had special problems with installation. Now all you have to do is "disklabel" the drive... Well, what is *THAT*??? The disklabel is used by the kernel and other utilities to tell how you want or have the drive set up *logically*. In a beautiful world, we might have a very free hand at this set-up and expect it to work. Unfortunately, the authors of the software dealing with the hard drives either decided or were forced by circumstance to make certain things about the disklabel inviolate. When you let the installation disk set the disklabel for you first drive it comes out like this: The a: partition is the primary partition. The b: partition is the swap partition. The c: partition is the amount of the disk used by 386bsd (swap and data) The d: partition is the entire disk. Of these, the only one that could be different is a:... (Note for those of us who have spent far too much time using DOS: the labels a: b: c: d: e: f: g: h: DO NOT refer to DOS drives, but to partitions in your 386bsd partition... confusing, eh? For the sake of consistency I will never make a reference to DOS drives except by saying something like "DOS drive C:". ) It's possible to divide up the disk a bit differently, but three things MUST be: c: must refer to every cylinder you wish 386bsd to use, either for your data or the swap space. d: Must refer to the whole disk, from cylinder 0 to the last one... b: Must always refer to a swap partition. Note that on any other than the first disk it does not have to, but if you enable swapping on that drive, and you are using b: for something else, that something else will be killed. The reason for this is simple: It's hard coded in. "WHY?" you ask? (I did...) Probably time constraints, maybe tradition. But if you look at the code in "isofs" and "ufs" in your sys.386bsd directory, you will see numerous comments asking some of the same questions, which leads me to believe this may change in the future, making our lives both more complicated and easier at the same time... Getting past the esoteric explanations, here is a method for figuring out and "labeling" your disk. We'll start with the disklabel from my second disk, in the form most understandable by humans... #'s signify the start of a comment. # /dev/rwd1d: type: ESDI disk: maxtor7245 label: flags: bytes/sector: 512 sectors/track: 31 tracks/cylinder: 16 sectors/cylinder: 496 cylinders: 967 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 5 partitions: # size offset fstype [fsize bsize cpg] a: 198400 0 4.2BSD 512 4096 16 # (Cyl. 0 - 399) b: 31744 447392 swap # (Cyl. 902 - 965) c: 479136 0 unused 0 0 # (Cyl. 0 - 965) d: 479136 0 unused 0 0 # (Cyl. 0 - 965) e: 248992 198400 4.2BSD 512 4096 16 # (Cyl. 400 - 901) Some math: Looking at the comments at the end and the size and offset columns, size is a function of (last - first + 1) * sectors per cylinder: a: 399 - 0 + 1 = 400 * 496 = 198400 b: 965 - 902 + 1 = 64 * 496 = 31744 c: & d: (Since I have no DOS partition, whatsoever) 965 - 0 = 1 = 966 * 496 = 479136 e: 901 - 400 = 502 * 496 = 248992 248992 + 198400 + 31744 = 479136 (all the parts should equal the whole) Some things I discovered (for all you in novice land like me...) 1. As you can see this disk has 967 cylinders, but I only refer to 966 of them, 0 - 965... This is because it's good practice to leave the "Landing Zone" cylinder out of it... This is usually the last cylinder, and it's where the read/write heads hang out when your disk is off... Note from TSgt Dave: Most modern drive heads come to rest on a polished surface inside the highest cylinder. I could be mistaken, of course, and the Hard Drive Bible (or other appropriate reference manual) will tell the tale for each drive. 2. a: can be a regular partition, b: should be swap, c: everything 386bsd will get to use, including swap. d: is the entire disk from 0 - (cylinder_per_disk - 2) [leaving out the Landing Zone] On the boot drive (The drive that actually contains the kernel), a: is the boot partition. On all other drives, it is a regular partition. You can then use e - h for your other partitions. I am not sure whether you could specify b: as other than a swap partition and not run into trouble, but you could surely make it a zero sized one starting and stopping on the Landing Zone... Note from TSgt Dave: This is a good idea. Another way to accomplish this is to simply not specify it in the map. 3. Stupid human trick: When doing the math don't forget that 400 - 900 refers to 50*1* cylinders. I did, for a while. No great problem I suspect, but why waste a cylinder... 4. newfs'ing really is that simple if you have the label right: "newfs /dev/rwd?x config_template" where the question mark is the physical disk, the x is a partition letter, and the config_template is the configuration from /etc/disktab for your disk drive. * NOTE: This is a thumbnail sketch; read the man page to verify all of the options and be sure about how to proceed... 5. then fsck the partition: fsck /dev/rwd?x Don't forget that fsck should be run on the RAW device. 6. As long as it checks out, you can then mount it and do disk things with it... 7. Add it to the fstab... (follow the man page). Don't forget that your new swap partition won't work if your kernel isn't configured for it, but it won't cause you any problem to have it there. One last note from TSgt Dave: And I have yet to figure out a way to determine if it is or isn't using the swap partition anyway. There is a program called 'swapinfo' and it is part of the NetBSD source tree. On my system, it tells me that I never use the swap area. :) Comnonly used definitions: bsize: Block Size: This is the smallest allocatable area on a disk file system, sort of. A file uses the maximum amount of blocks until it can not completely fill up a block. fsize: Fragment Size: This is the size of the 'leftover' data that didn't fit into a full block. For example, assuming a using an 8K Block Size/1K Fragment Size, a 34.5K file, would use up 4-8K Blocks (4 * 8K = 32K) and 3 1K fragments (3 * 1K = 3K). There is 512 bytes of wasted space, since 32K + 3K = 35K, which is 512 bytes larger than 34.5K. If you want to reduce the amount of wasted space, you can reduce your fragment size, but you also reduce the amount of data you read at one time, so your disk performance decreases also. A good setup is 8K/1K for performance, but if you are really concerned about wasted space you can consider using a 4K/512byte filesystem. For further information, find an article that explains the Berkeley FFS in more detail. cpg: Cylinders Per Group, it determines the cylinder group size, which in turn determines the number and location of the alternate superblocks. Cgd posted a description of how to manually install 386bsd and create 'real' BSD partitions. It is excerpted below: -------------------------------------------------------------------- HOW TO GET 386bsd 0.1 INSTALLED WITH "REAL" PARTITIONING: (remember, if things don't work, they might be in places that aren't normally looked in... things should work as below, but you might have to use explicit paths occasionally... the 'better' stuff -- mount, umount, cp, etc... is in /usr/distbin on the fixit floppy... even mknod is there, if the devices you need aren't on the fixit floppy...) (1) boot the fixit floppy (2) disklabel the disk as appropriate (3) newfs the partitions (4) mount the new root partition under /mnt (5) mkdir /mnt/usr (6) mount the new /usr partition under /mnt/usr (7) cpio the entire contents of the fixit floppy to the hard drive cd / ls .profile * [0-ln-z]*/* */*/* | cpio -pdalmu /mnt (NOTE: [0-ln-z]*/* is to avoid matching mnt/mnt) (8) copy /usr/distbin/mount and /usr/distbin/umount to /mnt (so that they'll be in the new root partition, so you can mount the new /usr partition...) (9) shutdown and the eject the floppy. (10) reboot off the hard drive, then fsck -p If there are any errors, after the fsck is done, hit ctl-alt-delete, and repeat this step. (11) fsck -p (12) mount -u / (13) mount /usr (14) insert 0.1 boot/install floppy (dist.fs) into floppy drive and "mount /dev/fd0a /mnt" (15) cd /mnt and then usr/bin/zcat etc/baselist.Z | usr/bin/cpio -pdalmu / (16) cd / and then /mnt/usr/bin/zcat /mnt/etc/baseutils.cpio.Z | /mnt/usr/bin/cpio -idalmu (17) umount /mnt then eject the floppy (18) umount /usr (19) shutdown (20) reboot off the hard drive, and get all of the various files (the bindist files, srcdist files, etc...). I put them into /usr/tmp, because there wasn't enough space in /tmp (because it was on a small root partition...). (21) cd / ; cat | uncompress | cpio -idalmu (22) rm (23) put your hostname into "/etc/myname" and put your ip addr/hostname into /etc/hosts. (24) make an fstab for yourself. specifically, you want something like: / ufs rw 1 1 /usr ufs rw 1 2 congratulations! you now have a working system! you can repeat step 21 for the srcdist and etcdist files, as well, if you wish... 2.5.2 Common Disk Label Problems. 2.5.2.1 Swap space. Nate Williams provides a short tutorial on swap space in 386bsd, excerpted below: To be able to use additional swap partitions, you need to specify them in the config (/sys/i386/conf/WHATEVER) file. Ex: config "386bsd" root on sd0 swap on sd0 and sd1 Allows swap on sd0 and sd1 config "386bsd" root on wd0 swap on wd0 and sd0 This would allow swap on both wd0 and sd0 OR whichever (both/either) of the two had a valid disklabel. Note, you can really screw yourself up with this, if you should happen to not want to swap to this partition, and it happens to be the first one found... The problem of not being able to swap was from the config file not having wd1 in it. controller wd0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wd0 drive 0 disk wd0 at wd0 drive 1 ^^^ This should have been wd1, and that's why it didn't get added by default. I may be wrong, but I have swapped to two different partitions w/out any problems since patchkit 0.1, and there aren't any patches to swap386bsd.c Once the install is complete, swapping will not be enabled on the second drive. The following steps can be used to make sure that it is enabled correctly. If there is a 'b' partition in your root disk 386bsd partition, it will be used automatically (MAKE SURE B is not the start of the disk, and MAKE SURE b doesn't contain any data you wish to keep). If b starts at disk offset 0, it will promptly wipe out your boot sectors and other important disk stuff. (This appears to be fixed in the current NetBSD sources) If you want an additional partition, put an entry similar to this in /etc/fstab: /dev/sd1b none swap sw I'm swapping on sd0b and sd1b, and 'swapon' is run on this partition on boot up. Swapping to a file is still not implemented. Rumor has it 0.2 will have such things. If someone wanted to add it, the vnops_* files would have to be radically modified to get it to work correctly. 2.5.2.2 Increasing the 386bsd partition size. Once the install is finished, the system has it's 386bsd partition. This includes a 5Meg swap partition, which is altogether too small. There is no easy way to increase this swap partition without relabeling the drive. Unfortunately, relabeling usually involves reinstalling. That involves re-doing just about everything you have just finished doing. The good news is that if all you have done is the base installation, you don't have a lot of time and energy invested in the system. Take the time, and make sure that your swap space is at least as big as your memory; many people recommend even larger. There is no real limit to the size that this space can take. If you have two disk drives, you can have space space on both. Simply follow the instructions above, and you will be all set. If your swap space is smaller than your real memory, system core dumps will be disabled. 2.5.2.3 I can access the DOS partition on my second disk from Unix but not DOS? Any suggestions? One kinky problem that almost got me was when I tried to disklabel my second drive in order to use the DOS partition on it, and use the rest as swap for BSD (FreeBSD-1.0 Eps, SCSI drive on an AHA1542B, to be exact). The DOS partition was visible from UNIX, but *not* from DOS. What I tried to do: Using PFDISK (from DOS), make one big DOS partition at the start and use the rest for a BSD partition (type 165). Something that came out like 1 6 0 69 DOSbi # .. 2 165 70 98 unkno for a 99 cyl drive. Using BSD disklabel generate disk description/label as documented in the FAQ. Make only 'c' (total BSD DOS part), 'd' (complete disk) and 'b' (intended swap) BSD partitions. Problem: When writing the label, disklabel would ask about overwriting DOS partition table. Whether I said y or n, the DOS partition table was screwed up, as seen from DOS (BSD saw the DOS file system very nicely indeed). Cause, solution: BSD disklabel wants to write the label to the start of the 'a' partition; I had *not* defined an 'a' partition (since I was only using the disk for swap). This tells disklabel that the 'a' partition is the start of the disk, which means there is no DOS partition. Disklabel then writes the label at the start of the drive, which is why it talks about overwriting (aha!); this is *bad* for the DOS partition table. One solution is to have a non-empty (e.g. one cylinder) 'a' partition at the start of the BSD part of the disk, and resize the 'b' swap partition accordingly. Now everything works just fine. Note that this solution can be used whenever you want the DOS partition table to be safe and the DOS partition to be mountable. One other fly in this ointment. The disklabel program has historically asked "Overwrite disk with DOS-partition [n]: " then the normal inclination is to believe the prompt and press return for 'no'. The default answer may or may not be 'no'. There are several versions of disklabel where the default answer is actually 'yes' even though the prompt implies that you can press return and get 'no'. In this case, it might be best to assume that the default answer doesn't exist until you have had a chance to actually look at the disklabel code. 2.5.3 How do I set up the system so that I can boot from more than one operating system/file-loader without using floppies? There are many people that wish to be able to boot DOS or 386bsd at will. There are several programs that allow this. The program "os-bs" is one such program, "BOOTEASY" is another, and there are three or four others. There are problems in some configurations using the os/2 boot manager for this, so beware. In addition to being able to boot from either of two partitions, some people want to operate more than one disk drive (and perhaps boot from either as well). Christoph Robitschko provided one description of this. Since there are virtually limitless possibilities for configurations for BSD systems, it will be impossible to answer all of the possible questions about these features. Many people operate with multiple disk drives on one or more controllers. Yu-Han Ting provides this tutorial on partitioning and booting multiple systems with a single hard disk. After spending one day fighting with the nasty partition table, finally I had NetBSD, DOS 5 (Sorry, I don't use DOS 6), and OS/2 2.1 March beta co-existing on my hard drive. Here is the answer: Since that my original hard disk setup was corrupted by NetBSD's installation program, I decided to rebuild it. I would like my partition table looks like this: Partition 0: OS/2 2.1 beta (Primary, HPFS, C:) Partition 1: MS-DOS 5.0 (Primary, C:) Partition 2: MS-DOS 5.0 (Extended, D: & E:) Partition 3: NetBSD You will need the following tools before you can setup a similar environment: 1) Mr. Wolfram's OS-BS. (It's an excellent boot selector, much better than OS/2's boot manager, IMHO) 2) PFDISK.EXE. (It's available from wuarchive.wustl.edu:mirrors/ linux/dos_utils/pfdisktc.zip.) 3) A binary editor. I use Norton Utilities' DiskEdit. 4) 386BSD's 'tinyBSD' distribution disk. After you have the necessary tools handy: 1) Use OS/2 'fdisk' to create partition 0. Make it install-able and install the system as usual. 2) Use OS/2 'fdisk' to create partition 1. Assign drive C: to the partition. Then reboot from DOS. 3) Use DOS 'fdisk' to create the extended partition. Assign logical drive D and E to the partition. 4) Reboot from DOS again. Format drive C: (for DOS), D:, and E:. 5) Use 'tinyBSD', NOT 'NetBSD', to boot the machine. Create a genuine 386BSD partition. Once the 386BSD partition has been made, boot DOS from floppy and execute PFDISK.EXE. For example, issue the following commands once you get into DOS: C>pfdisk 0 pfdisk> L ("pfdisk>" is the command prompt and "L" is the actual command.) The second line, i.e., command 'L', will tell you the starting address and the length of each partition you have. Record the information for step 6. 6) Reboot NetBSD from floppy. Install NetBSD over the original 386BSD partition. Fill out the information you get from step 5 to the installation program. 'halt' the system after you have installed 'install2.fs'. (Ed.Note: This step is the same for 386bsd or NetBSD) 7) Boot OS/2 from floppy. Use fdisk to assign drive C: to the OS/2 partition. In my case, partition 0. Note that fdisk will change the ID of partition 1 from '0x06' to '0x16'. '0x06' stands for 16-bit DOS FAT; while '0x16' stands for non-DOS partition. In the next step, we have to change '0x16' back to '0x06' manually. You can get the ID information by issuing "I" under PFDISK. It will tell you what the IDs represent. 8) Boot DOS from floppy. Use the binary editor to change the partition type as stated in step 7. 9) Install OS-BS under DOS. Remember to enable "Modify startup ID before booting". 10) Now you can boot any partition w/o floppy diskettes during startup. :) The above procedures may not be optimized. But it works for me. I won't spend anytime to deal with tedious work again :) You might feel strange why we need 'tinyBSD'. Simply trust me. By using 'tinyBSD' to create a partition for NetBSD, it will make your life a lot easier. Hope this helps. Ed. Note: The reason is because several versions of NetBSD and FreeBSD will not label a disk that doesn't have a disklabel. Catch-22. PS: %%%%% REMEMBER TO BACKUP YOUR SYSTEM BEFORE YOU CONDUCT THE EXPERIMENT !!! %%%%% Here is Christoph's explanation of how to set up a dual hard drive system so that the 386BSD/NetBSD system is stored entirely on the second hard drive. I have done this with two IDE drives. IDE+SCSI should be a bit simpler. There's a boot selector called BOOTEASY that can load from the second drive (you can get it from ftp.tu-graz.ac.at:pub/386BSD/0.1/unofficial/booteasy). What I have done to boot 386bsd from the second (IDE) drive: - installed booteasy on the first drive - (you can install booteasy on the second drive, too, if you have multiple partitions there) - modified Julian's boot blocks to use the second drive per default (Ed. Note: See below for the illumination of this step) - rebuilt the kernel to have root and swap on wd1 (probably not necessary for you, since your second disk is sd0, which is already in the config file). It worked perfectly for me. This should also work with equal facility for 386bsd users. Julian Elischer (julian@jules.dialix.oz.au) adds: To make the bootcode default to drive 1 look in /sys/{arch/}i386/boot/boot.c for the following (or similar.. It has changed a little) code: loadstart: /***************************************************************\ * As a default set it to the first partition of the first * * floppy or hard drive * \***************************************************************/ part = unit = 0; maj = (drive&0x80 ? 0 : 2); /* a good first bet */ name = names[currname++]; and change it to: loadstart: /***************************************************************\ * As a default set it to the first partition of the SECOND * * floppy or hard drive * \***************************************************************/ ! part = 0; ! unit = 1; maj = (drive&0x80 ? 0 : 2); /* a good first bet */ name = names[currname++]; And in yet another interation, Luke Mewburn (lm@yallara.cs.rmit.oz.au) decided to hack that a bit further in his NetBSD 0.9 (as_shipped i.e., non-current) to set the drive to the unit which the boot blocks loaded off. So, instead of: part = unit = 0; do: part = 0; unit = (drive & 0x7F); (the FAQ suggests `part = 0; unit = 1;' ) This way, whatever drive the bb's loaded from, it has that as default. In my case, I get wd(0,a) when I have my netbsd drive as C:, and wd(1,a) when I have it as D:. (I've been swapping drives left right and centre the last day getting dos to boot on one drive and netbsd on another). 2.5.4 How do I disklabel my second hard drive? The obvious answer is to use 'disklabel -w -r /dev/rwd1d'. Unfortunately, this does not always put a real disklabel on the drive. The symptom is that the drive labels and can be used until the system is reset, at which point the system tries to read the label from the disk. It was never actually written to the disk, so the operation fails. There are also reports that the /usr/mdec files are corrupted in some of the distributions. If you have tried everything else, you can either load the files from one of the many archive sites that keep the /usr/mdec files around, or you can recompile them yourself. Mark Weaver (mhw@cs.brown.edu) provides us with an illuminating answer to this perplexing problem. I had the same problem and there is a simple solution. I'm not sure why this works, but it does. Instead of specifying the entire device path name (i.e. /dev/rsd0c), only specify the two letters of the device type and the unit number (i.e. "sd0"). Disklabel figures out the rest, and it works. For instance, the following line works for me: disklabel -w -r sd0 assuming of course that the boot block files are in /usr/mdec/ and the is in the /etc/disktab. This is also a symptom of some of the versions of FreeBSD and NetBSD where the disklabel code was 'fixed' to only write a disklabel on a drive with a disklabel. Oops. Also, some folks want to mix SCSI and IDE drive together in the same system. A report about someone with an Austin Tower (486DX/50), AMI BIOS, Caviar 2250 IDE, Adaptec 1542CF, and Toshiba SCSI disk (1.2GB) posted this set of instructions: The BIOS is configured to boot from the IDE drive as type 47 (user defined). The IDE drive currently has NetBSD 1.0 BETA on it. The 1542CF switches are 1-4 off (open), 5-8 on. The meaning is as follows: 1(off)=Termination software controlled. 2,3,4(off)=I/O Port x330. 5(on)=disable floppy. I use the Austin floppy controller. 6,7,8(on)=disable Adaptec BIOS. Note that this means the Adaptec 1542CF on-board setup program is also disabled. If I need to change my SCSI termination, I first have to enable the Adapted BIOS (sw 6,7,8), enter 1542CF setup and change termination, then change switches again. I could not configure the system to boot from the SCSI drive having the IDE as a secondary drive. (Ed Note: There is more news on this front all of the time. Since I personally don't have much interest in doing this (I boot from my IDE drives and mount my SCSI drives) I don't see the problem. ) 2.5.5 386bsd/NetBSD/FreeBSD cannot handle disk geometry translations, but it turns out that my disk geometry is translated. It has five zones, each with a different sec/track! What kind of things can I do about the disk translation my hard disk controller uses? It turns out that what *BSD cannot handle is not translation, but translation that changes during the boot-up process. For example, the configuration above will work just fine IF the translation that the controller uses when it powers up is the same one that it uses when it boots. On many PC clones, the BIOS loads a different geometry after it boots to make the geometry agree with one that is loaded in CMOS. This is the fatal flaw for *BSD. Fortunately, once the problem has been identified, it is relatively easy to handle. Simply make sure that the BIOS is configured to set the controller to the translated geometry that the card powers up with. There are several ways to get around these problems with disk geometry translation. If you are using a SCSI controller, you can specify the geometry such that each 'cylinder' is 1 Meg (64 sectors by 32 tracks for example). Most SCSI controllers will blithely ignore what YOU tell it the geometry is and press on using this type of 1 Meg cylinder had to get the job done. NOTE: If you are going to try this, try to ensure that each 'pseudo cylinder' is a reasonable size (like 1Meg or 512K). An interesting method for dealing with disk geometry comes from Alan Barrett (barrett@lucy.ee.und.ac.za): This sort of problem happens when you try to install NetBSD in a partition of a disk whose controller does geometry translation. I have not had time to find the bug that causes the problem. One option is to disable the geometry translation: Use ide_conf to find the true geometry, use the CMOS setup program to tell your BIOS about the true geometry, and reformat everything. I successfully did that on one of my systems. If you are not able to, or do not wish to, disable the geometry translation then the following work-around might work for you. This requires that the disk have unused space on {cylinder 0, head 0}, from sector 2 to sector 16. Almost all DOS disks that I have ever seen satisfy this condition, because they usually start the DOS partition in {cylinder 0, head 0, sector 1}, leaving most of {cylinder 0, head 0} unused apart from the partition sector in {cylinder 0, head 0, sector 1}. However, many partitioning programs like to hide this fact from you, and pretend that the DOS partition starts at the front of the disk; don't believe them until you have checked with a raw disk editor. 0. Make sure you have adequate backups. 1. Use a partition sector editor (fdisk, pfdisk, os-bs, booteasy, Norton utilities, whatever) to mark the partition that you want for NetBSD as bootable with type 0xA5 (decimal 165). 2. Halt the system. Boot the NetBSD kernel copy floppy. When it asks you to insert the floppy for the root file system, switch to the Install-1 floppy and press enter. 3. Answer all the installation prompts, using numbers based on the translated geometry. When it asks if you really want to label the disk, be brave and say yes. 4. Halt the system. Boot to DOS. Run a disk editor program, such as Norton utilities. 5.1. Verify that the partition sector in {cyl 0, head 0, sec 1} is undamaged. Verify that the disklabel program run as part of the NetBSD install has written the NetBSD primary boot block to {cylinder xx, head 0, sector 1}, written the disk label to {cyl xx, head 0, sec 2}, and written the secondary boot program to {cyl xx, head 0, sectors 3 to 16}. ("xx" represents the translated cylinder number you chose for the start of the NetBSD partition. You did choose to start on a cylinder boundary, I hope.) 5.2. Verify that the space in {cyl 0, head 0, sectors 2 to 16} is still available. Copy the fifteen sectors containing the NetBSD disk label and secondary boot block from {cyl xx, head 0, sectors 2 to 16} to {cyl 0, head 0, sectors 2 to 16}. 5.3. Edit the partition table in {cyl 0, head 0, sec 1}. Change the system ID of the NetBSD partition from 0xA5 (decimal 165) to something else (I use 0xA4, decimal 164), but keep it flagged as bootable. This will let you boot to the NetBSD primary boot block. 5.4. Edit one of the previously unused partition table entries (I hope you have one), to contain the following information: {sys id = 0xA5, boot flag = 0, start cylinder/head/sector = 0/0/1, end cylinder/head/sector = anything, initial offset = 0, total size = anything}. This will tell the NetBSD primary boot block, or a NetBSD system booted from a floppy, that it should look for the NetBSD disk label in {cyl 0, head 0, sec 2}. 6. Halt the system. Boot the NetBSD kernel copy floppy. When it asks you to insert the floppy for the root file system, just press enter without changing disks. 7. Copy the kernel, and proceed with the rest of the installation as per the instructions provided with NetBSD. It should now work because of the trickery with the partition table etc. 2.5.6 My disk label is complaining about '256 heads' in the disklabel. This is obviously bogus, but it doesn't seem to be hurting anything. Is it Okay or should I fix it? Steve Gilbert (gilbert@cs.utk.edu) provided us with this answer: First, If you do a "fdisk wd1" (It may be wd1d, I don't remember what it wanted), it will list out the partition table for you. This is something totally different from BSD's idea of a partition, mind you. The last partition (#3) should be BSD. All of those figures are correct except for the "ending head" field which is set to 255 (thus, 256 heads). 1. BACK UP EVERYTHING! 2. fdisk -u wd1 ...this will prompt you for the stuff you want to change. Remember, everything is correct execpt for the ending head. Accept all the default values it gives you at first. You'll have to tell it that you want to explicitly define the beginning and ending values. 3. My 420 MB Conner drive has 16 heads, so I just enter 15 as the ending head number. 4. When you are back out of fdisk, you can do another fdisk wd1 to make sure the values are correct. Don't worry if you mess up, you can always change it again. Anything you didn't back up is probably gone by now anyway :-) 5. Reboot and watch NO error message pop up! ...remember that all you want to do is fdisk the drive. You do NOT want to run disklabel again or newfs the partitions again. This will write the incorrect 256 crap back. I did this three times before I finally got smart and did it right. 2.5.7 What are the options for the bootup prompt? The options are supposed to be as follows: -s............... boot into single user mode -a............... ask the user what device to use as root just before mounting it (Not presently supported) -d............... once you have the kernel loaded and VM and such up and going, drop into the kernel debugger. (great for debugging probe code) (not sure if this is presently working) 2.5.8 I am having trouble installing WRT 'syslogd: bind: Can't assign requested address' errors. What are some of the things I should look at? I also am having trouble with the network: 'starting network ... ifconfig: localhost: badvalue'. This is caused by incorrect settings in /etc/netstart and/or /etc/hosts. In /etc/hosts, you must have a line that says: 127.0.0.1 localhost localhost.my.domain Errors that will result if you don't do this: ifconfig will not be able to figure out what IP address goes with the name 'localhost' and you'll get 'localhost: bad value.' In /etc/netstart, you must do: ifconfig lo0 localhost route add {hostname} localhost Errors that will result if you don't do this: the loopback device will not be properly configured and/or you will have no route to it. The result is that programs expecting to have networking enabled (including syslog and friends) will get horribly confused. *AND*, if you're not going to be directly connected to a network, you should change /etc/host.conf to say: hosts bind It's set up the other way around by default. I don't like it that way myself. Errors that can result if you don't do this: if you don't have a nameserver available to you, the resolver will have trouble translating hostnames into IP addresses. Bogosity levels will be off the scale. (Note also that if you do have access to a nameserver, you need to set up /etc/resolv.conf to point to it.) By changing the order, you'll be telling the resolver to check the host files for matches *first*, then roll over to the nameserver (if any) if no match is found. Make sure that: - There are no typos in any of the three files mentioned above. - There are no bogus non-ASCII characters in the files mentioned above. - All three files have their read permission bits set. Lastly, be very careful with /etc/hosts.equiv. If you add a hostname to it, say 'otherhost.domain,' then root on otherhost.domain will be able to rsh/rlogin to your machine without a password. Once you have everything set correctly, you should be able to type 'telnet localhost' and establish a connection to yourself. If you get an error such as 'localhost: unknown host' or 'network unreachable' then you still have work to do. 2.6 Common installation problems. There are many common installation problems. This section covers the most basic and common of these problems. In addition to this section, you should also read through the other sections of the FAQ, since many of the less common questions are answered in other places in the doc. 2.6.1 Swap space not identified correctly. There are several levels of problems associated with swap space. The first is that the swap space on a second disk will not get used if it is not in your /etc/fstab file. Your /etc/fstab should have the swap space identified. The following is a representative fstab: /dev/wd0a / ufs rw 1 1 /dev/wd1b swap swap sw 0 0 Another common question is that the install program installs the swap partition in the 'b' partition, but does not mark it correctly as a swap partition. The swapping software will use the swap partition regardless of what it is called, but it should still be identified in the disklabel as the swap partition. Use 'disklabel' to change the partition type from 'unused' to 'swap'. NOTE: I mean it when I say that 386bsd will use the b: partition for swap without regard to what you called it. If it was your root partition, it will be toast the first time you try to swap a process out to disk. I'm not kidding! 2.6.2 Endless reboot cycles. Endless reboot cycles are the single most vexing aspect of 386bsd. Part of the problem is that the 0.1 distribution boot routines were never checked against many types of computers and have bugs. Most of the bugs are fixed in the patchkit, but that doesn't do the average novice user any good. In general, this will show up as a "bad disk label" error, and can result in in not booting from the hard drive "most of the time". You may be able to partially (or even completely) work around this problem by making your machine run at a lower clock rate. This problem is the result of the kernel reading the wrong register waiting for the drive controller to come ready. On some controllers, this isn't a problem; on others, it's fatal. This problem is solved for almost all controllers in the patchkit and both FreeBSD and NetBSD. The correct solution is to use a patched "dist.fs" or "fixit.fs" boot disk. Since these are no longer available, using an unpatched 386BSD 0.1 is a not a possibility any longer if you have this problem. You will have to upgrade to either FreeBSD or NetBSD. Another incarnation of this symptom is that the disk geometry on your disk label (as installed by install) is different than the geometry that your hard drive controller thinks it is using. This will most often manifest itself on controllers that insist on operating in some type of translation mode. Normally the fix is to find out what the controller geometry is and make the disk label agree. There are programs available to help with this problem. Julian's new boot blocks may also solve this problem. They are available where fine precompiled kernels may be found. Also, they are included in the patchkit as of version 0.2.2. 2.7 The computer just sits there, or 'that isn't right'. This class of problems is sometimes caused by an incorrect FTP of the boot disk. Make sure that the files were grabbed in 'binary' mode and that the size reported back is 1244000 bytes. Use the Unix program 'dd' or the DOS program RAWRITE to put these files onto the diskette. In addition, this is the 'miscellaneous' section of the FAQ. These problems are included here because they are usually preceded by 'I just finished installing...' Another incarnation of this problem is that, sometimes, the major or minor device numbers for a particular device may not get made correctly in the install (or upgrade) procedure. If you have a problem where you can install and everything seems to go well until you try to boot onto the hard drive, try running the MAKEDEV script that resides in /dev. More the file to see what kind of options you should include (if the sd0a drive needs to be fixed, for example, the command './MAKEDEV sd0' should get your devices back on the road. If that doesn't work, try one of the many things below. It could be any (or all) of them.... 2.7.1 The boot disk works all right on one computer but not another. This could be a problem with many different pieces, some of which are: - Misconfigured hardware. The iomem, IRQ, and other board settings must match the ones listed in the INSTALL.NOTES. Unfortunately, the INSTALL.NOTES are on the disk that will not boot. You can grab them via FTP from many archive sites. This installation file may have many names. Look for something kind of obvious (like 'install.notes' or 'readme' or 'configuration guide') and you should find it. Finally, there have been many reports (particularly with the BusLogic SCSI cards (specifically reported was the BT445C VLB host adapter) where the system seems to boot up, but starts getting 'stray interrupt c' messages. This is usually caused by people having there SCSI card set up on some IRQ other than the one that the kernel expects. The factory default for this card seems to be IRQ 12, but the kernel wants the card at IRQ 11. Setting the card (using the configuration program supplied) changes the setting so that it matches the kernel and the card then works. - Unsupported hardware. There are several SCSI controllers on the market that are not fully supported by 386bsd. The Ultrastore 24F (when not running in ISA emulation mode) is a good example of this. There are also some network cards that are not directly supported in 386bsd. If you get into a real bind, you can post a question to comp.os.386bsd.questions, and one of the many experienced 386bsd gurus that reads that group will probably try to help you. - One or more of the devices in the /dev directory on the intended root partition was either not created correctly or was not created at all. Run the program MAKEDEV in the /dev/ directory to ensure that all of the correct devices are built. 2.7.2 Really strange errors in the various *BSD flavors. 2.7.2.1 I am using the original 386bsd 0.1 with no patches installed and I get flashing multicolored characters and a "ptdi 81061" prompt error? Since 386BSD 0.1 is no longer available, you will have to upgrade to either FreeBSD or NetBSD, which both deal with this problem directly. 2.7.2.2 Using the new code in NetBSD, I get a "panic: pdti 206067" in pmap_enter(). What should I do? Increase NKPDE in /sys/i386/include/pmap.h. Be sure to keep the changes around as a patch file, since this is one of the files that will get overwritten during a source code update. 2.7.3a I get the error "isr 15 and error: isr 17" on an NE2000 card. 2.7.3b I have some card on IRQ2 and it doesn't work; why? 2.7.3c I am getting lousy performance out of my network card. What are some of the other possibilities? The description of this problem is that one of the cards in your system (most likely the VGA card) is either generating interrupts or is causing the IRQ 2 to be actively disabled. Older VGA card uses IRQ 2 during vertical retrace to prevent sparklies. One solution would be to plan on not using your Ethernet card (or any other card you want on IRQ 2) until you have rebuilt the kernel so that it expects it at an interrupt other than IRQ 2 or 9, re-jumper or reconfigure the card to match the IRQ you have selected, and enable it. From time to time, this problem will manifest itself as a general tendency of the network card to transfer either very sporadically or very slowly. It is precisely the same problem. James Van Artsdalen (james@bigtex.cactus.org) has offered at least one solution: If this is the problem, you can use Scotch tape to cover the IRQ 2 signal on the VGA's ISA connector. There has been some discussion as to whether scotch tape is really appropriate inside a card slot. My answer would be "yes". This is because the alternate solution of cutting the trace on the video board seems, to my mind, to reduce the value of the board. It is possible that, in the future, with a bi-bipartite driver, you would want to catch the retrace interrupt to get rid of "sparklies" or to implement a driver for a very high resolution monitor for X. If this happens, given a choice between alcohol and solder, I vote for alcohol. Either way, you will probably find that your VGA card uses IRQ 2 strictly for compatibility with older cards. With the advent of dual-ported memory for video cards, virtually all of these types of problems have disappeared. 2.7.4 What is the difference between IRQ2 and IRQ9? Are they really the same, or are they really different? On the XT, there was one interrupt controller, an Intel 8259, which handled 8 interrupts numbered IRQ0 through IRQ7. IRQs 2 through 7 were accessible via bus lines IRQ2 through IRQ7. The AT had two interrupt controllers. Due to the design of the 8259, one has to be the master and the rest (up to 8) must be slaves. Each slave controller output its interrupt request to and input on the master controller. In the case of the AT, the master controller handles IRQ0 through IRQ7. The slave handles IRQ8 through IRQ15. The interrupt request from the slave to the master goes through IRQ2, which is termed the cascase input. This means. of course, that the bus line for IRQ2 could no longer be used for external interrupts. Instead, the bus line that WAS IRQ2 in the XT became IRQ9 on the AT. This whole issue is confused further by the fact that some vendors refer to this external interrupt as IRQ2, while others refer to it as IRQ9. In either case, if you are talking about an external interrupt, it means the same thing. BTW, IRQ8 is used for the Real Time Clock, and does not have an external interrupt. Here is a map, in case anyone still needs it: Internal External Function IRQ0 n/a Refresh/Timer IRQ1 n/a Keyboard IRQ2 n/a Cascade Input to Master IRQ3 IRQ3 Free (Com port) IRQ4 IRQ4 Free (Com port) IRQ5 IRQ5 Free IRQ6 IRQ6 Floppy Controller IRQ7 IRQ7 Free (Printer/Sound Card*) IRQ8 n/a Real Time Clock IRQ9 IRQ2 Free (Network card) IRQ10 IRQ10 Free etc. * NOTE: The IRQ7 entry is spooky. If you use the interruptless printer driver (either from 386bsd, NetBSD, or FreeBSD) then you can still have an interrupting device (like a sound card) on interrupt 7. Basically, you can as many devices on each IRQ as you want, but only one of them can be 'actively' interrupting. There are very few drivers for *BSD that support an interruptless mode that it almost doesn't pay to even include this. 2.7.5 Some of my SCSI devices (like a tape drive) don't work; why? That is because the original 386bsd 0.1 SCSI drivers didn't recognize any devices past the first two (ID 0 and ID 1). Also, there was a bug in the distribution floppy regarding the devices at ID 6. The 'dev' files in 386bsd 0.1 for that id need to be remade. Use MAKEDEV to do that. The disks and tapes will be recognized and configured when they are first accessed. A new and improved SCSI driver has been written by Julian Elischer and is available from many sources. It includes support for many new types of SCSI controllers and many devices that are thereby attached. This driver is included in the patchkit. In addition, many of these types of devices are supported in FreeBSD and NetBSD. If one of the devices you are interested in using is not supported in 386BSD, you might try one of these newer systems. Even with the newer systems, you run the risk of having a problem with a SCSI device from time to time. There are some cards (like the new Adaptec 27* series) that software drivers are either not in the works or the documentation is simply unavailable. Another culprit here is that some machines are very touchy about the quality and length of cables, as well as SCSI IDs. There was one report of a older hard drive that took a little longer to spin up than the rest of the drives in the chain. Whenever this drive was put early in the ID string (like 1 or 2) it would be 'not found' but if it was placed near the end (like after the tape drive) it would have spun up and been found. Who says computers are logical? 2.7.6 I try to run 'ps' or 'w' and get ': cannot get namelist' from the TinyBSD kernel. What did I do wrong? Nothing. There is a class of programs that interact directly with the current kernel. These programs include 'ps', 'w', 'uptime', and others. The kernel on the TinyBSD disk is not capable of supporting these programs because the symbol table that these programs use has been stripped out of the kernel to save space. The easiest way to fix this is to get a different kernel (build it yourself). Of course, you can have a fully functional system with these programs, but they are nice to have. 2.7.7 I get a 'Floating point constant out of range' when I try to compile package 'n'. What is broke? This problem was encountered during many package compilations, including compiling gcc-2.3.3 under NetBSD-0.8. NetBSD-0.9, and presumably FreeBSD, contain a repaired printf() function, which corrects this problem. The easiest solution for this (and MANY other) problems is to upgrade. In addition, these systems also include gcc-2.3.3 (or newer) as the default compiler. There is also a circular dependency for protoize.o/unprotoize.o in the Makefile. Add the lines touch protoize.o touch unprotoize.o after the line: touch stamp-proto After this "make bootstrap" will run to completion. gas apparently has bugs too. It should produce +Infinity. I think it is OK internally but it may be trusting the library too much. gcc can easily be changed to avoid printf for output, but input is harder. One of the problems is that various pieces of code rely on the value of DBL_MAX. A kludge to fix it is to change the line below: #define DBL_MAX 1.7976931348623157E+308 One value that works is #define DBL_MAX 1.7976931348623147E+308 ^ was 5 This is a kludge, but it does mostly work. The problem is entirely in printf() (really in cvt()), NOT in atof(). I have inspected the output of atof() bit by bit, and it is well within IEEE specification. The digits `157' are the `best' approximation. The code for printf() generates a representation which is not even in the range of doubles. Below are the details: atof("1.7976931348623157e+308") returns 0x7fefffffffffffff which is the maximum double value and is correct. However, printf() of the previous yields `1.7976931348623168e+308', which isn't even within the floating point range. It is clearly printf() that is broken, and a quick inspection of the code is enough to determine that it uses a pessimal algorithm. atof() has been tested with many other values, and it has never been off by more than is allowed by IEEE 754 (though it is not optimal). 2.7.8 I want to use the Adaptec 1542C SCSI controller. What are the problems/tricks you need to know to get it working? The first thing to check when trying to use the 1542C is the setting of 'Enable Disconnection' under the 'SCSI Device Configuration' menu. It should be set to YES for all devices, as the manual warns you. Matthias Urlichs (urlichs@smurf.ira.uka.de) has provided this description of the types of things that can cause problems for the controller and devices attached to it. The problem is that the Adaptec 1542C has (a) rather powerful line drivers, and (b) is sensitive to transient signals which can be induced by them via either a bad cable or a bad external terminator. A bad cable is almost any cable which doesn't meet SCSI-2 specs. A bad external terminator is one which doesn't adequately buffer its resistor network. So... - Remove the internal terminator from the last drive in your chain. Replace with an active SCSI-2 external terminator. Side improvement: active terminators consume a bit less power. - Check cables. Specifically, some cables carry less than the nominal 50 signal wires. Manufacturers sometimes think they can get away with this because almost all odd-numbered pins are GROUND anyway. So, if pins 1 and 3 or 3 and 5 are connected, you're likely to have a marginal cable. - Make sure that the terminator power is supplied by all devices and that the power pin is actually connected on your cable. The problem here is that some idiot device manufacturers save on 2-cent diodes, which means that the thing will pull terminator power to ground if it's not plugged in. (Two of these on one bus are even worse.) - Consider creating your own cabling. Take a 50-wire flat ribbon and press the appropriate connectors onto it in precisely the right places. (Move your devices as to minimize cable length.) Be aware that if a device has two external connectors, you must take the SCSI bus in at one connector and out at the other -- don't leave the other connector dangling; this isn't within the SCSI specs because the cable usually is too long. - Better but more expensive: use 2-twisted cable. (I.e., wires 1&2 are twisted around each other, wire 3&4, ...) This will improve reliability because the wires are twisted at different rates. These cables have short non-twisted segments every 50 cm (1.5') so that you can press on your connectors instead of heating up that soldering iron. - While you're rebuilding your system anyway...: If you have more than one drive per power supply, check if these drives have adequate condensors to buffer their power. I have two 80-MB Seagates which refused to work more than a few hours without glitches -- then I soldered two 10-uF Tantals onto their power connector and they've been flawless ever since. The terminator power is pin 26. Be aware that SCSI counts pins as they appear on a ribbon cable, not as they're sometimes numbered on the connectors. Pin 25 is supposed to be disconnected. 2.7.9 My system boots OK off the floppy, but once I try to boot from the hard drive, the message "changing root device to sd0a" appears and the system hangs. What is the most likely thing that I have done wrong? A common cause for this is when all of the right devices aren't created on the root partition. Since you say you can boot off of a floppy, do so and check to make sure everything in /dev exists. You might consider running "MAKEDEV all" to be sure everything is created. (Ed.Note: I find that whenever I create a new kernel, it isn't a 'bad' idea to run a precautionary MAKEDEV to make sure that the devices are created correctly. Since I only build a new kernal about once a month, it isn't a very costly insurance policy.) Also, there are known problems with IRQ configurations and the PCI bus. The system hanging right after the changing root device message usually indicates a misconfigured IRQ for the controller. The initial probes by most (all?) drivers are done in polled mode, only when mounting the disk for real does the kernel begin to do interrupt driven I/O and DMA. Is this system a PCI system? Is the SCSI controller a PCI board? If so, make sure the IRQ configured in the PCI bios matches the IRQ configured for the card. Also, with PCI, forgetting to enable the slot for "master" in the BIOS setup or motherboard jumpers or putting a bus mastering card in a slave only slot will give simlar symptoms. The system may not have problems under DOS because some SCSI BIOS or device drivers don't actually use the DMA or bus mastering features of the card... {sigh}, they run in PIO mode under DOS. 2.8 Other common problems that are attributed to the installation process but are caused other places. 2.8.1 Why don't the man pages for "magic" and "file" work? The manual page for magic and file all have two dots before the commands, e.g.. "..SH" it should be ".SH" just delete one of the double dots in the whole file and then it will work. These man pages are fixed by both the patch-kit, NetBSD, and FreeBSD. The only time this problem every occurs is when you are using the distribution from one of the old CD-ROM distributions are get the original 386bsd 0.1 release. 2.8.2 Why is apropos broke? The Makefile in /usr/othersrc/share/man/Makefile creates the whatis.db. The problem is that it doesn't strip the backspaces in the title and apropos can't handle that. So add a "col -b" to strip those. excerpt from the Makefile. makedb: for file in `find /usr/share/man -type f -name '*.0' -print`; do \ sed -n -f /usr/share/man/makewhatis.sed $$file; \ done | col -b | sort -u > whatis.db install -o ${BINOWN} -g ${BINGRP} -m 444 whatis.db \ ${DESTDIR}/usr/share/man This problem is also solved in the patchkit, and other *BSD releases. Also, if the Makefile is moved to the /usr/share/man directory, the whatis.db will reside where it needs to eventually reside, and the install will wipe it out. An easy fix for that problem is to change the two references of whatis.db in the excerpt above to /tmp/whatis.db. This will ensure the file is correctly built and installed. 2.8.3 I want to use more than 16 Megabytes of memory. Will any of the BSD based systems support it? Early on, 386bsd 0.1 would choke radically on any system that had more than 8M of memory. With the advent of the patchkit, this problem was, for the most part, solved; memory could then expand to the 16M limit inherent in the ISA bus. As people started using VESA and EISA busses, however, attempts were made to push the envelope even further. Memory limits have expanded seemingly without limit. Since the EISA bus (for example) has 32 address lines, it is capable of supporting more memory than the ISA bus with its 24 address lines. While the 386 and 486 are capable of addresses up to 4 Gigabytes (considerably more than the ISA bus allows) the ISA bus is still the primary limitation. When using NetBSD and FreeBSD, there is no SOFTWARE limitation on more than 16Meg of memory. There are still hardware limitations. The limit is caused by DMA controllers which copy memory images around the system. Many cards which people use in VESA and EISA machines either emulate ISA cards (in order to work with *BSD) or are really ISA cards. There are reports of people having trouble with more than 64Meg of memory, but anyone rich enough to have that kind of memory should be paying for his OS. :-) Recently some folks have been reporting that they are getting warnings like these: hostname /netbsd: sd0: not queued hostname /netbsd: aha0: DMA beyond end of ISA hostname /netbsd: sd0: not queuedaha0: DMA beyond end of ISA This error is caused when the buffer for I/O is beyond the address range that the ISA bus can reach. With 16M you should be okay, however, some motherboards do reclaim all or part of the "lost" 384K (from the I/O "hole" from A0000-FFFFF) and put it just beyond the end of the rest of the memory, so you actually get 16M plus a little bit. One fix is bounce buffers. FreeBSD has implemented this, and NetBSD will as soon as they come up with a method that is compatible with all of the machines that NetBSD supports. Another fix is to either turn off the reclaiming of the extra memory (most motherboards that do this allow you to disable it), hack machdep.c to force the physical memory used to 16M, or use a 32 bit bus (EISA, VLB, or PCI) controller. Jordan K Hubbard (jkh@thrush.lotus.com) has provided this explanation of the distinction: Just so long as you're using a DMA-using disk controller in EISA mode, rather than ISA mode, you can use more than 16 Meg of memory. For those who may find such a distinction confusing, let me explain: You can use an ISA controller (such as an Adaptec 1542) in an EISA machine, but as it will still think it's in an ISA box and refuse to use the extra address lines, this is no different than having an ISA machine as far as >16MB is concerned. You can use an EISA controller in "ISA mode", meaning it uses the older protocols for compatability reasons (examples being Adaptec 1742 in "standard" mode, DTC 3290 in "Adaptec" mode, etc.) and again, does not use the extra address lines. The only way to get full EISA, 32MB-of-memory-and-everything, mode is to use an EISA controller in full EISA mode (for Adaptec 1742, this is "enhanced" mode, for DTC 3290 it's "DTC" mode, the Ultrastor 24F in EISA (rather than IDE emulation) mode, etc.). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In addition, several other types of ISA controllers which do NOT use DMA will not cause problems. IDE, ESDI, and RLL controllers are examples of this type of card. The discussion above also applies to VESA and VLB cards. So, the bottom line is that you are limited to the amount of memory that your DMA equipped devices can access. Once again, the weakest link is the strength of your machine. 2.8.4 I tried to use a device in my computer that should be there. When I did, I got a "Device not configured error." What do I do now? Garrett A. Wollman (wollman@emba.uvm.edu) provides us with this brief discussion in answer to a specific question. It wears well as a generic answer as well. When any program tells you ``Device not configured'', it's trying to tell you something very important about what you tried to do: namely, that the device you tried to access is not configured into the running operating system. This is the error message corresponding to ENXIO. There are three major causes for this error: 1) The kind of device you requested was not configured into the system. This is R.W.'s problem; the generic kernels are not distributed with the Berkeley Packet Filter enabled by default. To correct this, you must add the appropriate device or pseudo-device to your kernel configuration file and recompile. (In this particular case, `pseudo-device bpfilter number-of-network-interfaces'.) 2) The kind of device you requested was configured into the system, but either the device you requested would use more than the maximum you configured into the system, or if a physical device, was not found during autoconfiguration. To solve this, either change your configuration file, or change the I/O settings on the device to match what the file says. 3) The major or minor device number specified by the device's entry(ies) in /dev is incorrect. To solve this, re-MAKEDEV the device (read the MAKEDEV script for more details). Hopefully whatever change caused the kernel's internal device tables to get changed also updated your MAKEDEV script; otherwise, you will have to grovel through the kernel to see what is going on. 4) A special case: Although the 'c' drive on most BSD disks is the entire disk, in many NetBSD and FreeBSD systems, the entire drive is the 'd' disk. This special case is wired into many programs, and is recognized by the kernel. From time to time, folks will try and access the 'c' partition on their harddrive, only to be rebuffed with a 'device not configured' error. Mostly, the 'c' partition is unavailable simply because the partition type is 'unused' even though it is allocated and has space set aside for it. -- TSgt Dave Burgess | Dave Burgess NCOIC, USSTRATCOM/J6844 | *BSD FAQ Maintainer Offutt AFB, NE | Burgess@s069.infonet.net From csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail Thu Apr 13 15:16:24 1995 Path: csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 3 of 10) Supersedes: <386bsd-faq-3-796287611@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 13 Apr 1995 01:00:19 -0500 Organization: Dave's House in Omaha Lines: 1963 Sender: burgess@cynjut.netins.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 05/01/95 01:00:08 CDT Message-ID: <386bsd-faq-3-797752808@s069.netins.net> References: <386bsd-faq-1-797752808@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.netins.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:28 comp.unix.bsd.freebsd.announce:31 comp.answers:11171 news.answers:41787 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part3 Section 2. (Common installation questions) 2.0 Install process The 386bsd system is distributed in many ways. One of the most common is via DOS diskettes, (either 3 1/2 or 5 1/4, both high density) with the actual distribution being a 'CPIO archive' broken into 240K pieces. This allows the distribution to fit onto a minimum number of floppies. Once the files are on floppies, thoughts usually turn to questions about how to install the boot image on a floppy. The rawrite program (for DOS) is used to write the bootable images (dist.fs and fixit.fs) onto floppies. The same image can used for 3 1/2 and 5 1/4 high density diskettes. Low density diskettes are not supported in this version of 386bsd. NetBSD uses the same file extension for its floppy images. FreeBSD uses the .flp extension. Once the bootable images are written onto the floppies, insert the dist.fs disk into the A: drive and reboot. If the system does not boot, see section 2.5 below for more information. If the disk boots, type install and proceed to use the INSTALL.NOTES to get more information. Problems with the install are either related to hardware (i.e. Do you want to install on your T.V.?) or software. Of the hardware issues, the most common FAQs are usually straight out of the installation notes. Of the software issues, there are only two that really concern us. The first is bad files. On some systems, files that are loaded from floppy appear to 'go bad' when they arrive on the hard disk. Try some of these solutions: - You forgot binary. Don't get insulted. Those of us that FTP for a living forget sometimes. If so, the distribution will come out with all different sizes and install will complain about every disk. - One or two of the files are no good. Try getting them again. As a precaution, rename the bad files on your hard drive to names like foo.1 and bob.23. Copy the files again from floppy. If they are still bad, rename the file, and the one immediately before the first bad file (bin01.23 if bin01.24 is bad) and copy them again. If they are still bad, download those files again from the distribution site (including the one before and after the bad one) and try again. The reason for renaming the files is that sometimes, especially with drive that do not auto-magically record bad sectors, you could copy a distribution file onto a bad spot on the disk. If this happens, you want to isolate the bad spot. The easiest way to do that is just leave the bad file on it. Keep trying, these same files have been used by literally thousands of people to install 386bsd. For those of you that have received your system on a CD-ROM, you will need to find at least three things. One is this file. Since you are reading it, I assume that you got it already. :-) If you can't read this file (you got it from the newsgroup, for example) there is one thing that you need to know so you don't look like a complete idiot on the net. There is no such thing as a Unix CD-ROM. They are all in something called the ISO CD-ROM format. You can read them as the D: drive in DOS, or mount them on your Sun or SVR4 system or whatever. Second, you will need to find the directory with the bootable disk images in it. They will have self explanatory names like: kerncopy.fs base0-9.fs fred.fs genericaha.fs boot-me-first.fs this-is-the-file-with-the-fs-extension.fs You get the idea, right? Look for the MS-DOS program "RAWRITE.EXE". It should be right near the file system (.fs) files. Another clue for the truly lost will be that the file system files will all be 1.2 Meg big. These files will fit onto either a 1.2Meg 5.25 inch diskette, or a 1.44Meg 2.5 inch diskette. Use rawrite to write the fs files to diskettes and boot from the diskettes. The FreeBSD system uses a system 'pretty much' the same as this, except that the filesystem files are 1.2 Meg files and they all have a '.flp' extension. Other than that, the instructions apply. You did back your system up, right? 2.0.1 Boot disks (versions and media formats) There is currently one official 386bsd 0.1 boot disk, referred to as the "Tiny" boot disk. Because of the nature of the agreement between USL and Berkeley, it is rapidly becoming impossible to get 386bsd 0.1 diskettes. The archive at agate.berkeley.edu has been eliminated completely. The NetBSD archive that was there has also been eliminated. There are a few FAQs from the boot/install disk. 2.0.1.1 Where does extract go when I reboot? It was in /tmp, which is cleaned the first time you reboot the system from the hard drive. If you have just booted from the hard drive for the second time, chances are you just wiped out extract. It is not really needed, since the instructions for building your own install are included in section 2.5.2 of the FAQ, under custom installation. When installing NetBSD, the set_tmp_dir and extract programs are part of the .profile that is booted when you are installing. This .profile is overwritten as part of the install process, and extract then disappears. If you need extract again, you can mount the install disk and source .profile. This will recreate these two routines. There is also an install procedure that FreeBSD uses that does the same job. It is defined as part of the .profile on one of the installation floppies. You can either copy it from there, or use the procedure for 'real disk partitioning'. 2.0.1.2 I put the floppy in and try to boot, and nothing happens. What now? There are lots of possibilities. We will start with the oldest (386bsd 0.1) problems. This is usually referred to as the Compaq boot problem. The easiest solution is to get a patched boot disk. Another source of possible hope for you is to grab the NetBSD bootable disks. They are compatible with 386BSD and allow you to install on some of the more recalcitrant hardware. The FreeBSD install process is said to be better than the NetBSD program for some machines. Could be. They are all available for free from the net. Try it. 2.0.1.3a The floppy booted, but now the hard disk won't boot? 2.0.1.3b I am trying to reinstall. I run install and it loops asking me if I want to use the whole disk? The most likely culprit is your hard disk controller. It is probably doing some type of disk translation for you. If this is the case (assume it is) then you will need to find out the real disk controller geometry, and rewrite your disk label. See section 2.6.2, but before doing that get the program pfdisk.exe. This program will tell you what the controller geometry is (right before it reboots your computer). Make the disklabel agree with this program and your system should boot. You may have to reinstall, but at least your disklabel will be right. Note that this is a nearly required step for all NetBSD and FreeBSD installs. You need to know what the disk geometry is before the BIOS messes with it. If you start having these kinds of installation problems, I can virtually assure you that it is because your controller geometry and your disklabel geometry are different. NOTE: If the hard disk controller does NOT have an option for turning off the geometry, you may well be completely out of luck. There are very few controllers that fall into this category. The ones that do full time translation will often boot up in translated mode. pfdisk will help you determine the correct geometry for your drive by telling you what the geometry looks like when 386bsd boots up. But on the other hand, maybe not... See section 2.5.5 below for a detailed set of instructions about getting NetBSD (and by implication 386BSD and FreeBSD) to work with a system that uses full time translation. 2.0.1.4 What are the options on the boot prompt? The most amazing thing about the boot process in *BSD is the boot up alternatives that are available. There is little that a person can NOT do from the boot prompt. The boot diskette or disk can be selected (fd(1,a) for fd1a (my B: drive is DOS)) can be the source of my kernel. In addition, the name of the kernel can be chosen (this allows you to boot with a test kernel or reboot an older kernel if the new one gets hosed). Finally, there are three choices for options that may or may not work, depending on the age and proclivities of your boot blocks. These options are: -s............... boot into single user mode -a............... ask the user what device to use as root just before mounting it (Not presently supported) -d............... once you have the kernel loaded and VM and such up and going, drop into the kernel debugger. Great for debugging probe code. ( not sure if this is presently working) I have noticed that there is a fourth one. I'll write it up later. 2.0.1.5 I just used the '-s' option on the boot, but I can't write anything onto the disk. What is wrong? If I use a plain 'mount' command it tells me that my root file system is read-only. In single-user (system booted with -s or an error in one of the processes started by /etc/rc) the root filesystem mounts as read-only by default. This was intended so that some range of problems would not be made worse by writes to the disk. The 'dos' partitions mount as read-only in that there are reservations as to how well some of the FreeBSD tools work with the pcfs. The same kind of reservations exist with NetBSD and the '-t msdosfs' option. These options (-r for read-only, -w for read-write) can be set in /etc/fstab. The status of both can be changed with 'mount -wu /{mount.dir}' (where {mount-dir} is the name of the directory that the offending partition is mounted) to read-write. Particularly for the dos filesystem, the man page for mount should be read in detail and the 'noexec' option examined. Note that mounting the file systems using the '-a' option will mount all of the file systems that are normally mounted with their usual read-write bits set normally. Using this option makes your root partition writable, and also mounts the rest of the partitions in your /etc/fstab that are normally mounted during boot-up. 2.0.2 Fix-it boot disk The fix-it disk contains a series of programs that are particularly handy for 'fixing' your disk in case you can't get logged in. It includes the disklabel program and other utilities for system maintenance. For NetBSD and FreeBSD, you will probably have to build your own Fixit disk. You can mount the original file system floppy and beat it to death if you want. Put programs on it that you will need to build a new system. As I think of them, I will put them in. 2.1 Binary distribution The binary distribution 386bsd 0.1 consists of virtually all of the programs that a typical *nix system would be expected to have. The list includes mail, UUCP, GCC version 1.39, and others. Known problems with the binary distribution include the following: 1. Mtools as shipped in the bindist does not always work. The ones on the install disk seem to work fine. 2. The install script built into the binary distribution does not correctly install all of the files and symbolic links that it should. For example, some of the symbolic links to the /usr/include directory are botched up. 3. 'tip', the modem control program, does not always work right out of the box. 4. Any program that relies on a valid symbol table in the kernel (e.g. ps) will not work because the kernel is stripped so that it will fit onto the bootable disk. These problems are all cured either by patches available in the patchkit, or through re-compilation. FreeBSD and NetBSD have solved these problems. This information is included primarily for those few people that get sucked into using an old version of 386bsd for a class or something. 2.1.1 I want to install by NFS but I am having all kinds of problems. There is an unusual problem when installing over NFS. This solution may have been corrected in the documentation that comes with FreeBSD and NetBSD, but if not, here it is. The most common problem seems to be that FreeBSD (and by inference NetBSD and all the other 4.4 based systems) do not send out NFS requests over privileged ports. Sun's NFS implementation (and others, once again by inference) expect precisely the opposite. These systems will quietly fail if you try to NFS to them. The usual error message (which may ONLY appear in /var/adm/messages) is "nfs_server: weak authentication, source IP address=xx.xx.xx.xx" SunOS is particularly insidious at this point. The mount succeeds, but then everything else after that fails. This means that your FreeBSD or NetBSD system will return ann EACCESS error whenever you try to grab a file from the NFS filesystem. The solution (tested in FreeBSD) is to include the 'resvport' flag like this: # mount -o resvport server:/fs /mnt_point or to use the -P flag (which does the same thing). See the mount and mount_nfs man pages for the details. In fact, the -P flag provides a solution to the FreeBSD NFS installation problem. When prompted for server/filesystem, type in the flag before the server/filesystem pair: -P server:/fs If you are using an 8-bit network card, and want to avoid the ring buffer overflow problems that seem to come standard with this class of cards, you can also include the "-r4096 -w4096" flags between the -P and the server. 2.2 Source distribution The source distribution 386bsd 0.1 contains all of the source code for every program in the bindist. Known problems (which are fixed in the patchkit) include the following: 1. There is an error message during install about install.src01 not being found. It is not an error, there isn't an install.src01. Think of it as Bill and Lynne's idea of a practical joke. 2. There are several symbolic links that are not made correctly. In addition, there are several files that should have been deleted (to ensure clean 'make's) before the files were packed. This is fixed by the patchkit, as of 0.2.3. 3. The /usr/src tree does not compile cleanly. This is fixed by the patchkit, as of 0.2.3, or by NetBSD or FreeBSD. 2.3 Additional software distribution The etc distribution contains source trees for many programs that are of interest to 386bsd users. The complete ISO software development environment, as well as many additional software packages (and all of the games) are included in this distribution. The most common problem with the etc distribution is the error "too many files open". Followed closely by "install.etc01 not found". The latter is a annoyance (see above) but the former can be easily overcome in a couple of ways. The "too many files open" is a result of the "cat" command leaving files open after it has read a file. Dwight E. Cass (his Email address is dec@lazarus.nrtc.northrop.com) has provided us with this anecdotal work around for his own experiences: -------------------------------------------------------------------- So - back to installation. This time, when I get to the etc01 partition, I am a bit more awake, so I run it from Csh (with the open file limit at 256). Works pretty well - but complains at the end that it could not do the final configuration because it could not find the configuration file - I checked the MANIFEST and the file is not there, so I finally decided to ignore the message (but it was bothersome!) Once etc01 was done - source was easy ... and I am now up and running, and quite impressed!!! -------------------------------------------------------------------- Another method is to use a loop construct in the Bourne shell. For example: for i in (etc01.*) do cat $i done | compress -d | cpio -idalmu -or- for i in (etc01.*) do zcat $i done | cpio -idalmu will also solve the problem handily. This solution solves the problem by running cat multiple times, with one file each. Since cat now only has one file, there are no limits on the number of files that can be used for the distribution set. 2.4 Patch-kit The patchkit has been completely deprecated. FreeBSD and NetBSD are both mature programs that will serve the average user extremely well. The patchkit may still be available, but it is only required if you are installing the original 386BSD 0.1 version. There are two mailing lists dedicated to the patchkit. They are as follows: 386bsd-patchkit@cs.montana.edu, which is primarily for discussion of up-coming patches and patchkit philosophy. patches@cs.montana.edu, which is dedicated to submitting new, untested patches. The current (and final) version of the patchkit is 0.2.4, which has absolutely no relationship with the new version of 386bsd. It is available by anonymous FTP from several sites throughout the net. 2.5 Configuration By far, the most common configuration questions are partitioning, followed closely by all of the other software in the system. Sendmail and named are also problems occasionally, but the documentation that comes with them usually gets you through. If you run into a problem, post a question to comp.os.386bsd.questions. A less frequently asked question is "Where can I get info on how to configure a kernel?" The answer to this question has been provided by Richard Murphey (Email address rich@Rice.edu). -------------------------------------------------------------------- Ready-to-print PostScript files for each section of the net2 system maintainer's manual are on nova.cc.purdue.edu in pub/386bsd/submissions/bsd.manuals. smm.02.config.ps.Z describes kernel configuration for the VAX, however some of it is relevant to 386BSD. There is no freely available rewrite for 386BSD that I know of. -------------------------------------------------------------------- Most of these manuals are now included in the standard release of NetBSD and FreeBSD in the /usr/share/doc directories. 2.5.1 Partitions This section describes many of the questions that people ask about hard disk partitioning. The first is a brief explanation of the BSD system disk partitions. 2.5.1.1 What is a 'disklabel' and why do I need one? The BSD partition table supplements the DOS partition table. The entries in this table are meaningful to BSD. There are eight partitions in the BSD partition table, and they are normally lettered from a: to h:. This supplemental partition table is often refered to as the 'disklabel'. This tutorial is provided by by "" and provides an excellent overview of the hard disk partitioning procedure from start to finish. "Disk Partitioning for the Compleat Idiot" There are times, in our trials with our computers, that it becomes necessary to mess about with the disklabel. For those not knowledgeable of BSD or Unix Systems administration, this somewhat simple task can be somewhat daunting. This document is the result of my own short experience. This does not cover physical installation of the disk. For those who are having trouble with that, I direct you to any of the fine manuals dealing with hard drives and your hardware. It also does not deal with the vagaries of the DOS partition manager. It assumes you have done that as well, if need be... After the drive is physically installed and is recognized in the BSD startup, and it mentions both your drives, in the order you expect them... Or perhaps just the one, if you had special problems with installation. Now all you have to do is "disklabel" the drive... Well, what is *THAT*??? The disklabel is used by the kernel and other utilities to tell how you want or have the drive set up *logically*. In a beautiful world, we might have a very free hand at this set-up and expect it to work. Unfortunately, the authors of the software dealing with the hard drives either decided or were forced by circumstance to make certain things about the disklabel inviolate. When you let the installation disk set the disklabel for you first drive it comes out like this: The a: partition is the primary partition. The b: partition is the swap partition. The c: partition is the amount of the disk used by 386bsd (swap and data) The d: partition is the entire disk. Of these, the only one that could be different is a:... (Note for those of us who have spent far too much time using DOS: the labels a: b: c: d: e: f: g: h: DO NOT refer to DOS drives, but to partitions in your 386bsd partition... confusing, eh? For the sake of consistency I will never make a reference to DOS drives except by saying something like "DOS drive C:". ) It's possible to divide up the disk a bit differently, but three things MUST be: c: must refer to every cylinder you wish 386bsd to use, either for your data or the swap space. d: Must refer to the whole disk, from cylinder 0 to the last one... b: Must always refer to a swap partition. Note that on any other than the first disk it does not have to, but if you enable swapping on that drive, and you are using b: for something else, that something else will be killed. The reason for this is simple: It's hard coded in. "WHY?" you ask? (I did...) Probably time constraints, maybe tradition. But if you look at the code in "isofs" and "ufs" in your sys.386bsd directory, you will see numerous comments asking some of the same questions, which leads me to believe this may change in the future, making our lives both more complicated and easier at the same time... Getting past the esoteric explanations, here is a method for figuring out and "labeling" your disk. We'll start with the disklabel from my second disk, in the form most understandable by humans... #'s signify the start of a comment. # /dev/rwd1d: type: ESDI disk: maxtor7245 label: flags: bytes/sector: 512 sectors/track: 31 tracks/cylinder: 16 sectors/cylinder: 496 cylinders: 967 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 5 partitions: # size offset fstype [fsize bsize cpg] a: 198400 0 4.2BSD 512 4096 16 # (Cyl. 0 - 399) b: 31744 447392 swap # (Cyl. 902 - 965) c: 479136 0 unused 0 0 # (Cyl. 0 - 965) d: 479136 0 unused 0 0 # (Cyl. 0 - 965) e: 248992 198400 4.2BSD 512 4096 16 # (Cyl. 400 - 901) Some math: Looking at the comments at the end and the size and offset columns, size is a function of (last - first + 1) * sectors per cylinder: a: 399 - 0 + 1 = 400 * 496 = 198400 b: 965 - 902 + 1 = 64 * 496 = 31744 c: & d: (Since I have no DOS partition, whatsoever) 965 - 0 = 1 = 966 * 496 = 479136 e: 901 - 400 = 502 * 496 = 248992 248992 + 198400 + 31744 = 479136 (all the parts should equal the whole) Some things I discovered (for all you in novice land like me...) 1. As you can see this disk has 967 cylinders, but I only refer to 966 of them, 0 - 965... This is because it's good practice to leave the "Landing Zone" cylinder out of it... This is usually the last cylinder, and it's where the read/write heads hang out when your disk is off... Note from TSgt Dave: Most modern drive heads come to rest on a polished surface inside the highest cylinder. I could be mistaken, of course, and the Hard Drive Bible (or other appropriate reference manual) will tell the tale for each drive. 2. a: can be a regular partition, b: should be swap, c: everything 386bsd will get to use, including swap. d: is the entire disk from 0 - (cylinder_per_disk - 2) [leaving out the Landing Zone] On the boot drive (The drive that actually contains the kernel), a: is the boot partition. On all other drives, it is a regular partition. You can then use e - h for your other partitions. I am not sure whether you could specify b: as other than a swap partition and not run into trouble, but you could surely make it a zero sized one starting and stopping on the Landing Zone... Note from TSgt Dave: This is a good idea. Another way to accomplish this is to simply not specify it in the map. 3. Stupid human trick: When doing the math don't forget that 400 - 900 refers to 50*1* cylinders. I did, for a while. No great problem I suspect, but why waste a cylinder... 4. newfs'ing really is that simple if you have the label right: "newfs /dev/rwd?x config_template" where the question mark is the physical disk, the x is a partition letter, and the config_template is the configuration from /etc/disktab for your disk drive. * NOTE: This is a thumbnail sketch; read the man page to verify all of the options and be sure about how to proceed... 5. then fsck the partition: fsck /dev/rwd?x Don't forget that fsck should be run on the RAW device. 6. As long as it checks out, you can then mount it and do disk things with it... 7. Add it to the fstab... (follow the man page). Don't forget that your new swap partition won't work if your kernel isn't configured for it, but it won't cause you any problem to have it there. One last note from TSgt Dave: And I have yet to figure out a way to determine if it is or isn't using the swap partition anyway. There is a program called 'swapinfo' and it is part of the NetBSD source tree. On my system, it tells me that I never use the swap area. :) Comnonly used definitions: bsize: Block Size: This is the smallest allocatable area on a disk file system, sort of. A file uses the maximum amount of blocks until it can not completely fill up a block. fsize: Fragment Size: This is the size of the 'leftover' data that didn't fit into a full block. For example, assuming a using an 8K Block Size/1K Fragment Size, a 34.5K file, would use up 4-8K Blocks (4 * 8K = 32K) and 3 1K fragments (3 * 1K = 3K). There is 512 bytes of wasted space, since 32K + 3K = 35K, which is 512 bytes larger than 34.5K. If you want to reduce the amount of wasted space, you can reduce your fragment size, but you also reduce the amount of data you read at one time, so your disk performance decreases also. A good setup is 8K/1K for performance, but if you are really concerned about wasted space you can consider using a 4K/512byte filesystem. For further information, find an article that explains the Berkeley FFS in more detail. cpg: Cylinders Per Group, it determines the cylinder group size, which in turn determines the number and location of the alternate superblocks. Cgd posted a description of how to manually install 386bsd and create 'real' BSD partitions. It is excerpted below: -------------------------------------------------------------------- HOW TO GET 386bsd 0.1 INSTALLED WITH "REAL" PARTITIONING: (remember, if things don't work, they might be in places that aren't normally looked in... things should work as below, but you might have to use explicit paths occasionally... the 'better' stuff -- mount, umount, cp, etc... is in /usr/distbin on the fixit floppy... even mknod is there, if the devices you need aren't on the fixit floppy...) (1) boot the fixit floppy (2) disklabel the disk as appropriate (3) newfs the partitions (4) mount the new root partition under /mnt (5) mkdir /mnt/usr (6) mount the new /usr partition under /mnt/usr (7) cpio the entire contents of the fixit floppy to the hard drive cd / ls .profile * [0-ln-z]*/* */*/* | cpio -pdalmu /mnt (NOTE: [0-ln-z]*/* is to avoid matching mnt/mnt) (8) copy /usr/distbin/mount and /usr/distbin/umount to /mnt (so that they'll be in the new root partition, so you can mount the new /usr partition...) (9) shutdown and the eject the floppy. (10) reboot off the hard drive, then fsck -p If there are any errors, after the fsck is done, hit ctl-alt-delete, and repeat this step. (11) fsck -p (12) mount -u / (13) mount /usr (14) insert 0.1 boot/install floppy (dist.fs) into floppy drive and "mount /dev/fd0a /mnt" (15) cd /mnt and then usr/bin/zcat etc/baselist.Z | usr/bin/cpio -pdalmu / (16) cd / and then /mnt/usr/bin/zcat /mnt/etc/baseutils.cpio.Z | /mnt/usr/bin/cpio -idalmu (17) umount /mnt then eject the floppy (18) umount /usr (19) shutdown (20) reboot off the hard drive, and get all of the various files (the bindist files, srcdist files, etc...). I put them into /usr/tmp, because there wasn't enough space in /tmp (because it was on a small root partition...). (21) cd / ; cat | uncompress | cpio -idalmu (22) rm (23) put your hostname into "/etc/myname" and put your ip addr/hostname into /etc/hosts. (24) make an fstab for yourself. specifically, you want something like: / ufs rw 1 1 /usr ufs rw 1 2 congratulations! you now have a working system! you can repeat step 21 for the srcdist and etcdist files, as well, if you wish... 2.5.2 Common Disk Label Problems. 2.5.2.1 Swap space. Nate Williams provides a short tutorial on swap space in 386bsd, excerpted below: To be able to use additional swap partitions, you need to specify them in the config (/sys/i386/conf/WHATEVER) file. Ex: config "386bsd" root on sd0 swap on sd0 and sd1 Allows swap on sd0 and sd1 config "386bsd" root on wd0 swap on wd0 and sd0 This would allow swap on both wd0 and sd0 OR whichever (both/either) of the two had a valid disklabel. Note, you can really screw yourself up with this, if you should happen to not want to swap to this partition, and it happens to be the first one found... The problem of not being able to swap was from the config file not having wd1 in it. controller wd0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wd0 drive 0 disk wd0 at wd0 drive 1 ^^^ This should have been wd1, and that's why it didn't get added by default. I may be wrong, but I have swapped to two different partitions w/out any problems since patchkit 0.1, and there aren't any patches to swap386bsd.c Once the install is complete, swapping will not be enabled on the second drive. The following steps can be used to make sure that it is enabled correctly. If there is a 'b' partition in your root disk 386bsd partition, it will be used automatically (MAKE SURE B is not the start of the disk, and MAKE SURE b doesn't contain any data you wish to keep). If b starts at disk offset 0, it will promptly wipe out your boot sectors and other important disk stuff. (This appears to be fixed in the current NetBSD sources) If you want an additional partition, put an entry similar to this in /etc/fstab: /dev/sd1b none swap sw I'm swapping on sd0b and sd1b, and 'swapon' is run on this partition on boot up. Swapping to a file is still not implemented. Rumor has it 0.2 will have such things. If someone wanted to add it, the vnops_* files would have to be radically modified to get it to work correctly. 2.5.2.2 Increasing the 386bsd partition size. Once the install is finished, the system has it's 386bsd partition. This includes a 5Meg swap partition, which is altogether too small. There is no easy way to increase this swap partition without relabeling the drive. Unfortunately, relabeling usually involves reinstalling. That involves re-doing just about everything you have just finished doing. The good news is that if all you have done is the base installation, you don't have a lot of time and energy invested in the system. Take the time, and make sure that your swap space is at least as big as your memory; many people recommend even larger. There is no real limit to the size that this space can take. If you have two disk drives, you can have space space on both. Simply follow the instructions above, and you will be all set. If your swap space is smaller than your real memory, system core dumps will be disabled. 2.5.2.3 I can access the DOS partition on my second disk from Unix but not DOS? Any suggestions? One kinky problem that almost got me was when I tried to disklabel my second drive in order to use the DOS partition on it, and use the rest as swap for BSD (FreeBSD-1.0 Eps, SCSI drive on an AHA1542B, to be exact). The DOS partition was visible from UNIX, but *not* from DOS. What I tried to do: Using PFDISK (from DOS), make one big DOS partition at the start and use the rest for a BSD partition (type 165). Something that came out like 1 6 0 69 DOSbi # .. 2 165 70 98 unkno for a 99 cyl drive. Using BSD disklabel generate disk description/label as documented in the FAQ. Make only 'c' (total BSD DOS part), 'd' (complete disk) and 'b' (intended swap) BSD partitions. Problem: When writing the label, disklabel would ask about overwriting DOS partition table. Whether I said y or n, the DOS partition table was screwed up, as seen from DOS (BSD saw the DOS file system very nicely indeed). Cause, solution: BSD disklabel wants to write the label to the start of the 'a' partition; I had *not* defined an 'a' partition (since I was only using the disk for swap). This tells disklabel that the 'a' partition is the start of the disk, which means there is no DOS partition. Disklabel then writes the label at the start of the drive, which is why it talks about overwriting (aha!); this is *bad* for the DOS partition table. One solution is to have a non-empty (e.g. one cylinder) 'a' partition at the start of the BSD part of the disk, and resize the 'b' swap partition accordingly. Now everything works just fine. Note that this solution can be used whenever you want the DOS partition table to be safe and the DOS partition to be mountable. One other fly in this ointment. The disklabel program has historically asked "Overwrite disk with DOS-partition [n]: " then the normal inclination is to believe the prompt and press return for 'no'. The default answer may or may not be 'no'. There are several versions of disklabel where the default answer is actually 'yes' even though the prompt implies that you can press return and get 'no'. In this case, it might be best to assume that the default answer doesn't exist until you have had a chance to actually look at the disklabel code. 2.5.3 How do I set up the system so that I can boot from more than one operating system/file-loader without using floppies? There are many people that wish to be able to boot DOS or 386bsd at will. There are several programs that allow this. The program "os-bs" is one such program, "BOOTEASY" is another, and there are three or four others. There are problems in some configurations using the os/2 boot manager for this, so beware. In addition to being able to boot from either of two partitions, some people want to operate more than one disk drive (and perhaps boot from either as well). Christoph Robitschko provided one description of this. Since there are virtually limitless possibilities for configurations for BSD systems, it will be impossible to answer all of the possible questions about these features. Many people operate with multiple disk drives on one or more controllers. Yu-Han Ting provides this tutorial on partitioning and booting multiple systems with a single hard disk. After spending one day fighting with the nasty partition table, finally I had NetBSD, DOS 5 (Sorry, I don't use DOS 6), and OS/2 2.1 March beta co-existing on my hard drive. Here is the answer: Since that my original hard disk setup was corrupted by NetBSD's installation program, I decided to rebuild it. I would like my partition table looks like this: Partition 0: OS/2 2.1 beta (Primary, HPFS, C:) Partition 1: MS-DOS 5.0 (Primary, C:) Partition 2: MS-DOS 5.0 (Extended, D: & E:) Partition 3: NetBSD You will need the following tools before you can setup a similar environment: 1) Mr. Wolfram's OS-BS. (It's an excellent boot selector, much better than OS/2's boot manager, IMHO) 2) PFDISK.EXE. (It's available from wuarchive.wustl.edu:mirrors/ linux/dos_utils/pfdisktc.zip.) 3) A binary editor. I use Norton Utilities' DiskEdit. 4) 386BSD's 'tinyBSD' distribution disk. After you have the necessary tools handy: 1) Use OS/2 'fdisk' to create partition 0. Make it install-able and install the system as usual. 2) Use OS/2 'fdisk' to create partition 1. Assign drive C: to the partition. Then reboot from DOS. 3) Use DOS 'fdisk' to create the extended partition. Assign logical drive D and E to the partition. 4) Reboot from DOS again. Format drive C: (for DOS), D:, and E:. 5) Use 'tinyBSD', NOT 'NetBSD', to boot the machine. Create a genuine 386BSD partition. Once the 386BSD partition has been made, boot DOS from floppy and execute PFDISK.EXE. For example, issue the following commands once you get into DOS: C>pfdisk 0 pfdisk> L ("pfdisk>" is the command prompt and "L" is the actual command.) The second line, i.e., command 'L', will tell you the starting address and the length of each partition you have. Record the information for step 6. 6) Reboot NetBSD from floppy. Install NetBSD over the original 386BSD partition. Fill out the information you get from step 5 to the installation program. 'halt' the system after you have installed 'install2.fs'. (Ed.Note: This step is the same for 386bsd or NetBSD) 7) Boot OS/2 from floppy. Use fdisk to assign drive C: to the OS/2 partition. In my case, partition 0. Note that fdisk will change the ID of partition 1 from '0x06' to '0x16'. '0x06' stands for 16-bit DOS FAT; while '0x16' stands for non-DOS partition. In the next step, we have to change '0x16' back to '0x06' manually. You can get the ID information by issuing "I" under PFDISK. It will tell you what the IDs represent. 8) Boot DOS from floppy. Use the binary editor to change the partition type as stated in step 7. 9) Install OS-BS under DOS. Remember to enable "Modify startup ID before booting". 10) Now you can boot any partition w/o floppy diskettes during startup. :) The above procedures may not be optimized. But it works for me. I won't spend anytime to deal with tedious work again :) You might feel strange why we need 'tinyBSD'. Simply trust me. By using 'tinyBSD' to create a partition for NetBSD, it will make your life a lot easier. Hope this helps. Ed. Note: The reason is because several versions of NetBSD and FreeBSD will not label a disk that doesn't have a disklabel. Catch-22. PS: %%%%% REMEMBER TO BACKUP YOUR SYSTEM BEFORE YOU CONDUCT THE EXPERIMENT !!! %%%%% Here is Christoph's explanation of how to set up a dual hard drive system so that the 386BSD/NetBSD system is stored entirely on the second hard drive. I have done this with two IDE drives. IDE+SCSI should be a bit simpler. There's a boot selector called BOOTEASY that can load from the second drive (you can get it from ftp.tu-graz.ac.at:pub/386BSD/0.1/unofficial/booteasy). What I have done to boot 386bsd from the second (IDE) drive: - installed booteasy on the first drive - (you can install booteasy on the second drive, too, if you have multiple partitions there) - modified Julian's boot blocks to use the second drive per default (Ed. Note: See below for the illumination of this step) - rebuilt the kernel to have root and swap on wd1 (probably not necessary for you, since your second disk is sd0, which is already in the config file). It worked perfectly for me. This should also work with equal facility for 386bsd users. Julian Elischer (julian@jules.dialix.oz.au) adds: To make the bootcode default to drive 1 look in /sys/{arch/}i386/boot/boot.c for the following (or similar.. It has changed a little) code: loadstart: /***************************************************************\ * As a default set it to the first partition of the first * * floppy or hard drive * \***************************************************************/ part = unit = 0; maj = (drive&0x80 ? 0 : 2); /* a good first bet */ name = names[currname++]; and change it to: loadstart: /***************************************************************\ * As a default set it to the first partition of the SECOND * * floppy or hard drive * \***************************************************************/ ! part = 0; ! unit = 1; maj = (drive&0x80 ? 0 : 2); /* a good first bet */ name = names[currname++]; And in yet another interation, Luke Mewburn (lm@yallara.cs.rmit.oz.au) decided to hack that a bit further in his NetBSD 0.9 (as_shipped i.e., non-current) to set the drive to the unit which the boot blocks loaded off. So, instead of: part = unit = 0; do: part = 0; unit = (drive & 0x7F); (the FAQ suggests `part = 0; unit = 1;' ) This way, whatever drive the bb's loaded from, it has that as default. In my case, I get wd(0,a) when I have my netbsd drive as C:, and wd(1,a) when I have it as D:. (I've been swapping drives left right and centre the last day getting dos to boot on one drive and netbsd on another). 2.5.4 How do I disklabel my second hard drive? The obvious answer is to use 'disklabel -w -r /dev/rwd1d'. Unfortunately, this does not always put a real disklabel on the drive. The symptom is that the drive labels and can be used until the system is reset, at which point the system tries to read the label from the disk. It was never actually written to the disk, so the operation fails. There are also reports that the /usr/mdec files are corrupted in some of the distributions. If you have tried everything else, you can either load the files from one of the many archive sites that keep the /usr/mdec files around, or you can recompile them yourself. Mark Weaver (mhw@cs.brown.edu) provides us with an illuminating answer to this perplexing problem. I had the same problem and there is a simple solution. I'm not sure why this works, but it does. Instead of specifying the entire device path name (i.e. /dev/rsd0c), only specify the two letters of the device type and the unit number (i.e. "sd0"). Disklabel figures out the rest, and it works. For instance, the following line works for me: disklabel -w -r sd0 assuming of course that the boot block files are in /usr/mdec/ and the is in the /etc/disktab. This is also a symptom of some of the versions of FreeBSD and NetBSD where the disklabel code was 'fixed' to only write a disklabel on a drive with a disklabel. Oops. Also, some folks want to mix SCSI and IDE drive together in the same system. A report about someone with an Austin Tower (486DX/50), AMI BIOS, Caviar 2250 IDE, Adaptec 1542CF, and Toshiba SCSI disk (1.2GB) posted this set of instructions: The BIOS is configured to boot from the IDE drive as type 47 (user defined). The IDE drive currently has NetBSD 1.0 BETA on it. The 1542CF switches are 1-4 off (open), 5-8 on. The meaning is as follows: 1(off)=Termination software controlled. 2,3,4(off)=I/O Port x330. 5(on)=disable floppy. I use the Austin floppy controller. 6,7,8(on)=disable Adaptec BIOS. Note that this means the Adaptec 1542CF on-board setup program is also disabled. If I need to change my SCSI termination, I first have to enable the Adapted BIOS (sw 6,7,8), enter 1542CF setup and change termination, then change switches again. I could not configure the system to boot from the SCSI drive having the IDE as a secondary drive. (Ed Note: There is more news on this front all of the time. Since I personally don't have much interest in doing this (I boot from my IDE drives and mount my SCSI drives) I don't see the problem. ) 2.5.5 386bsd/NetBSD/FreeBSD cannot handle disk geometry translations, but it turns out that my disk geometry is translated. It has five zones, each with a different sec/track! What kind of things can I do about the disk translation my hard disk controller uses? It turns out that what *BSD cannot handle is not translation, but translation that changes during the boot-up process. For example, the configuration above will work just fine IF the translation that the controller uses when it powers up is the same one that it uses when it boots. On many PC clones, the BIOS loads a different geometry after it boots to make the geometry agree with one that is loaded in CMOS. This is the fatal flaw for *BSD. Fortunately, once the problem has been identified, it is relatively easy to handle. Simply make sure that the BIOS is configured to set the controller to the translated geometry that the card powers up with. There are several ways to get around these problems with disk geometry translation. If you are using a SCSI controller, you can specify the geometry such that each 'cylinder' is 1 Meg (64 sectors by 32 tracks for example). Most SCSI controllers will blithely ignore what YOU tell it the geometry is and press on using this type of 1 Meg cylinder had to get the job done. NOTE: If you are going to try this, try to ensure that each 'pseudo cylinder' is a reasonable size (like 1Meg or 512K). An interesting method for dealing with disk geometry comes from Alan Barrett (barrett@lucy.ee.und.ac.za): This sort of problem happens when you try to install NetBSD in a partition of a disk whose controller does geometry translation. I have not had time to find the bug that causes the problem. One option is to disable the geometry translation: Use ide_conf to find the true geometry, use the CMOS setup program to tell your BIOS about the true geometry, and reformat everything. I successfully did that on one of my systems. If you are not able to, or do not wish to, disable the geometry translation then the following work-around might work for you. This requires that the disk have unused space on {cylinder 0, head 0}, from sector 2 to sector 16. Almost all DOS disks that I have ever seen satisfy this condition, because they usually start the DOS partition in {cylinder 0, head 0, sector 1}, leaving most of {cylinder 0, head 0} unused apart from the partition sector in {cylinder 0, head 0, sector 1}. However, many partitioning programs like to hide this fact from you, and pretend that the DOS partition starts at the front of the disk; don't believe them until you have checked with a raw disk editor. 0. Make sure you have adequate backups. 1. Use a partition sector editor (fdisk, pfdisk, os-bs, booteasy, Norton utilities, whatever) to mark the partition that you want for NetBSD as bootable with type 0xA5 (decimal 165). 2. Halt the system. Boot the NetBSD kernel copy floppy. When it asks you to insert the floppy for the root file system, switch to the Install-1 floppy and press enter. 3. Answer all the installation prompts, using numbers based on the translated geometry. When it asks if you really want to label the disk, be brave and say yes. 4. Halt the system. Boot to DOS. Run a disk editor program, such as Norton utilities. 5.1. Verify that the partition sector in {cyl 0, head 0, sec 1} is undamaged. Verify that the disklabel program run as part of the NetBSD install has written the NetBSD primary boot block to {cylinder xx, head 0, sector 1}, written the disk label to {cyl xx, head 0, sec 2}, and written the secondary boot program to {cyl xx, head 0, sectors 3 to 16}. ("xx" represents the translated cylinder number you chose for the start of the NetBSD partition. You did choose to start on a cylinder boundary, I hope.) 5.2. Verify that the space in {cyl 0, head 0, sectors 2 to 16} is still available. Copy the fifteen sectors containing the NetBSD disk label and secondary boot block from {cyl xx, head 0, sectors 2 to 16} to {cyl 0, head 0, sectors 2 to 16}. 5.3. Edit the partition table in {cyl 0, head 0, sec 1}. Change the system ID of the NetBSD partition from 0xA5 (decimal 165) to something else (I use 0xA4, decimal 164), but keep it flagged as bootable. This will let you boot to the NetBSD primary boot block. 5.4. Edit one of the previously unused partition table entries (I hope you have one), to contain the following information: {sys id = 0xA5, boot flag = 0, start cylinder/head/sector = 0/0/1, end cylinder/head/sector = anything, initial offset = 0, total size = anything}. This will tell the NetBSD primary boot block, or a NetBSD system booted from a floppy, that it should look for the NetBSD disk label in {cyl 0, head 0, sec 2}. 6. Halt the system. Boot the NetBSD kernel copy floppy. When it asks you to insert the floppy for the root file system, just press enter without changing disks. 7. Copy the kernel, and proceed with the rest of the installation as per the instructions provided with NetBSD. It should now work because of the trickery with the partition table etc. 2.5.6 My disk label is complaining about '256 heads' in the disklabel. This is obviously bogus, but it doesn't seem to be hurting anything. Is it Okay or should I fix it? Steve Gilbert (gilbert@cs.utk.edu) provided us with this answer: First, If you do a "fdisk wd1" (It may be wd1d, I don't remember what it wanted), it will list out the partition table for you. This is something totally different from BSD's idea of a partition, mind you. The last partition (#3) should be BSD. All of those figures are correct except for the "ending head" field which is set to 255 (thus, 256 heads). 1. BACK UP EVERYTHING! 2. fdisk -u wd1 ...this will prompt you for the stuff you want to change. Remember, everything is correct execpt for the ending head. Accept all the default values it gives you at first. You'll have to tell it that you want to explicitly define the beginning and ending values. 3. My 420 MB Conner drive has 16 heads, so I just enter 15 as the ending head number. 4. When you are back out of fdisk, you can do another fdisk wd1 to make sure the values are correct. Don't worry if you mess up, you can always change it again. Anything you didn't back up is probably gone by now anyway :-) 5. Reboot and watch NO error message pop up! ...remember that all you want to do is fdisk the drive. You do NOT want to run disklabel again or newfs the partitions again. This will write the incorrect 256 crap back. I did this three times before I finally got smart and did it right. 2.5.7 What are the options for the bootup prompt? The options are supposed to be as follows: -s............... boot into single user mode -a............... ask the user what device to use as root just before mounting it (Not presently supported) -d............... once you have the kernel loaded and VM and such up and going, drop into the kernel debugger. (great for debugging probe code) (not sure if this is presently working) 2.5.8 I am having trouble installing WRT 'syslogd: bind: Can't assign requested address' errors. What are some of the things I should look at? I also am having trouble with the network: 'starting network ... ifconfig: localhost: badvalue'. This is caused by incorrect settings in /etc/netstart and/or /etc/hosts. In /etc/hosts, you must have a line that says: 127.0.0.1 localhost localhost.my.domain Errors that will result if you don't do this: ifconfig will not be able to figure out what IP address goes with the name 'localhost' and you'll get 'localhost: bad value.' In /etc/netstart, you must do: ifconfig lo0 localhost route add {hostname} localhost Errors that will result if you don't do this: the loopback device will not be properly configured and/or you will have no route to it. The result is that programs expecting to have networking enabled (including syslog and friends) will get horribly confused. *AND*, if you're not going to be directly connected to a network, you should change /etc/host.conf to say: hosts bind It's set up the other way around by default. I don't like it that way myself. Errors that can result if you don't do this: if you don't have a nameserver available to you, the resolver will have trouble translating hostnames into IP addresses. Bogosity levels will be off the scale. (Note also that if you do have access to a nameserver, you need to set up /etc/resolv.conf to point to it.) By changing the order, you'll be telling the resolver to check the host files for matches *first*, then roll over to the nameserver (if any) if no match is found. Make sure that: - There are no typos in any of the three files mentioned above. - There are no bogus non-ASCII characters in the files mentioned above. - All three files have their read permission bits set. Lastly, be very careful with /etc/hosts.equiv. If you add a hostname to it, say 'otherhost.domain,' then root on otherhost.domain will be able to rsh/rlogin to your machine without a password. Once you have everything set correctly, you should be able to type 'telnet localhost' and establish a connection to yourself. If you get an error such as 'localhost: unknown host' or 'network unreachable' then you still have work to do. 2.6 Common installation problems. There are many common installation problems. This section covers the most basic and common of these problems. In addition to this section, you should also read through the other sections of the FAQ, since many of the less common questions are answered in other places in the doc. 2.6.1 Swap space not identified correctly. There are several levels of problems associated with swap space. The first is that the swap space on a second disk will not get used if it is not in your /etc/fstab file. Your /etc/fstab should have the swap space identified. The following is a representative fstab: /dev/wd0a / ufs rw 1 1 /dev/wd1b swap swap sw 0 0 Another common question is that the install program installs the swap partition in the 'b' partition, but does not mark it correctly as a swap partition. The swapping software will use the swap partition regardless of what it is called, but it should still be identified in the disklabel as the swap partition. Use 'disklabel' to change the partition type from 'unused' to 'swap'. NOTE: I mean it when I say that 386bsd will use the b: partition for swap without regard to what you called it. If it was your root partition, it will be toast the first time you try to swap a process out to disk. I'm not kidding! 2.6.2 Endless reboot cycles. Endless reboot cycles are the single most vexing aspect of 386bsd. Part of the problem is that the 0.1 distribution boot routines were never checked against many types of computers and have bugs. Most of the bugs are fixed in the patchkit, but that doesn't do the average novice user any good. In general, this will show up as a "bad disk label" error, and can result in in not booting from the hard drive "most of the time". You may be able to partially (or even completely) work around this problem by making your machine run at a lower clock rate. This problem is the result of the kernel reading the wrong register waiting for the drive controller to come ready. On some controllers, this isn't a problem; on others, it's fatal. This problem is solved for almost all controllers in the patchkit and both FreeBSD and NetBSD. The correct solution is to use a patched "dist.fs" or "fixit.fs" boot disk. Since these are no longer available, using an unpatched 386BSD 0.1 is a not a possibility any longer if you have this problem. You will have to upgrade to either FreeBSD or NetBSD. Another incarnation of this symptom is that the disk geometry on your disk label (as installed by install) is different than the geometry that your hard drive controller thinks it is using. This will most often manifest itself on controllers that insist on operating in some type of translation mode. Normally the fix is to find out what the controller geometry is and make the disk label agree. There are programs available to help with this problem. Julian's new boot blocks may also solve this problem. They are available where fine precompiled kernels may be found. Also, they are included in the patchkit as of version 0.2.2. 2.7 The computer just sits there, or 'that isn't right'. This class of problems is sometimes caused by an incorrect FTP of the boot disk. Make sure that the files were grabbed in 'binary' mode and that the size reported back is 1244000 bytes. Use the Unix program 'dd' or the DOS program RAWRITE to put these files onto the diskette. In addition, this is the 'miscellaneous' section of the FAQ. These problems are included here because they are usually preceded by 'I just finished installing...' Another incarnation of this problem is that, sometimes, the major or minor device numbers for a particular device may not get made correctly in the install (or upgrade) procedure. If you have a problem where you can install and everything seems to go well until you try to boot onto the hard drive, try running the MAKEDEV script that resides in /dev. More the file to see what kind of options you should include (if the sd0a drive needs to be fixed, for example, the command './MAKEDEV sd0' should get your devices back on the road. If that doesn't work, try one of the many things below. It could be any (or all) of them.... 2.7.1 The boot disk works all right on one computer but not another. This could be a problem with many different pieces, some of which are: - Misconfigured hardware. The iomem, IRQ, and other board settings must match the ones listed in the INSTALL.NOTES. Unfortunately, the INSTALL.NOTES are on the disk that will not boot. You can grab them via FTP from many archive sites. This installation file may have many names. Look for something kind of obvious (like 'install.notes' or 'readme' or 'configuration guide') and you should find it. Finally, there have been many reports (particularly with the BusLogic SCSI cards (specifically reported was the BT445C VLB host adapter) where the system seems to boot up, but starts getting 'stray interrupt c' messages. This is usually caused by people having there SCSI card set up on some IRQ other than the one that the kernel expects. The factory default for this card seems to be IRQ 12, but the kernel wants the card at IRQ 11. Setting the card (using the configuration program supplied) changes the setting so that it matches the kernel and the card then works. - Unsupported hardware. There are several SCSI controllers on the market that are not fully supported by 386bsd. The Ultrastore 24F (when not running in ISA emulation mode) is a good example of this. There are also some network cards that are not directly supported in 386bsd. If you get into a real bind, you can post a question to comp.os.386bsd.questions, and one of the many experienced 386bsd gurus that reads that group will probably try to help you. - One or more of the devices in the /dev directory on the intended root partition was either not created correctly or was not created at all. Run the program MAKEDEV in the /dev/ directory to ensure that all of the correct devices are built. 2.7.2 Really strange errors in the various *BSD flavors. 2.7.2.1 I am using the original 386bsd 0.1 with no patches installed and I get flashing multicolored characters and a "ptdi 81061" prompt error? Since 386BSD 0.1 is no longer available, you will have to upgrade to either FreeBSD or NetBSD, which both deal with this problem directly. 2.7.2.2 Using the new code in NetBSD, I get a "panic: pdti 206067" in pmap_enter(). What should I do? Increase NKPDE in /sys/i386/include/pmap.h. Be sure to keep the changes around as a patch file, since this is one of the files that will get overwritten during a source code update. 2.7.3a I get the error "isr 15 and error: isr 17" on an NE2000 card. 2.7.3b I have some card on IRQ2 and it doesn't work; why? 2.7.3c I am getting lousy performance out of my network card. What are some of the other possibilities? The description of this problem is that one of the cards in your system (most likely the VGA card) is either generating interrupts or is causing the IRQ 2 to be actively disabled. Older VGA card uses IRQ 2 during vertical retrace to prevent sparklies. One solution would be to plan on not using your Ethernet card (or any other card you want on IRQ 2) until you have rebuilt the kernel so that it expects it at an interrupt other than IRQ 2 or 9, re-jumper or reconfigure the card to match the IRQ you have selected, and enable it. From time to time, this problem will manifest itself as a general tendency of the network card to transfer either very sporadically or very slowly. It is precisely the same problem. James Van Artsdalen (james@bigtex.cactus.org) has offered at least one solution: If this is the problem, you can use Scotch tape to cover the IRQ 2 signal on the VGA's ISA connector. There has been some discussion as to whether scotch tape is really appropriate inside a card slot. My answer would be "yes". This is because the alternate solution of cutting the trace on the video board seems, to my mind, to reduce the value of the board. It is possible that, in the future, with a bi-bipartite driver, you would want to catch the retrace interrupt to get rid of "sparklies" or to implement a driver for a very high resolution monitor for X. If this happens, given a choice between alcohol and solder, I vote for alcohol. Either way, you will probably find that your VGA card uses IRQ 2 strictly for compatibility with older cards. With the advent of dual-ported memory for video cards, virtually all of these types of problems have disappeared. 2.7.4 What is the difference between IRQ2 and IRQ9? Are they really the same, or are they really different? On the XT, there was one interrupt controller, an Intel 8259, which handled 8 interrupts numbered IRQ0 through IRQ7. IRQs 2 through 7 were accessible via bus lines IRQ2 through IRQ7. The AT had two interrupt controllers. Due to the design of the 8259, one has to be the master and the rest (up to 8) must be slaves. Each slave controller output its interrupt request to and input on the master controller. In the case of the AT, the master controller handles IRQ0 through IRQ7. The slave handles IRQ8 through IRQ15. The interrupt request from the slave to the master goes through IRQ2, which is termed the cascase input. This means. of course, that the bus line for IRQ2 could no longer be used for external interrupts. Instead, the bus line that WAS IRQ2 in the XT became IRQ9 on the AT. This whole issue is confused further by the fact that some vendors refer to this external interrupt as IRQ2, while others refer to it as IRQ9. In either case, if you are talking about an external interrupt, it means the same thing. BTW, IRQ8 is used for the Real Time Clock, and does not have an external interrupt. Here is a map, in case anyone still needs it: Internal External Function IRQ0 n/a Refresh/Timer IRQ1 n/a Keyboard IRQ2 n/a Cascade Input to Master IRQ3 IRQ3 Free (Com port) IRQ4 IRQ4 Free (Com port) IRQ5 IRQ5 Free IRQ6 IRQ6 Floppy Controller IRQ7 IRQ7 Free (Printer/Sound Card*) IRQ8 n/a Real Time Clock IRQ9 IRQ2 Free (Network card) IRQ10 IRQ10 Free etc. * NOTE: The IRQ7 entry is spooky. If you use the interruptless printer driver (either from 386bsd, NetBSD, or FreeBSD) then you can still have an interrupting device (like a sound card) on interrupt 7. Basically, you can as many devices on each IRQ as you want, but only one of them can be 'actively' interrupting. There are very few drivers for *BSD that support an interruptless mode that it almost doesn't pay to even include this. 2.7.5 Some of my SCSI devices (like a tape drive) don't work; why? That is because the original 386bsd 0.1 SCSI drivers didn't recognize any devices past the first two (ID 0 and ID 1). Also, there was a bug in the distribution floppy regarding the devices at ID 6. The 'dev' files in 386bsd 0.1 for that id need to be remade. Use MAKEDEV to do that. The disks and tapes will be recognized and configured when they are first accessed. A new and improved SCSI driver has been written by Julian Elischer and is available from many sources. It includes support for many new types of SCSI controllers and many devices that are thereby attached. This driver is included in the patchkit. In addition, many of these types of devices are supported in FreeBSD and NetBSD. If one of the devices you are interested in using is not supported in 386BSD, you might try one of these newer systems. Even with the newer systems, you run the risk of having a problem with a SCSI device from time to time. There are some cards (like the new Adaptec 27* series) that software drivers are either not in the works or the documentation is simply unavailable. Another culprit here is that some machines are very touchy about the quality and length of cables, as well as SCSI IDs. There was one report of a older hard drive that took a little longer to spin up than the rest of the drives in the chain. Whenever this drive was put early in the ID string (like 1 or 2) it would be 'not found' but if it was placed near the end (like after the tape drive) it would have spun up and been found. Who says computers are logical? 2.7.6 I try to run 'ps' or 'w' and get ': cannot get namelist' from the TinyBSD kernel. What did I do wrong? Nothing. There is a class of programs that interact directly with the current kernel. These programs include 'ps', 'w', 'uptime', and others. The kernel on the TinyBSD disk is not capable of supporting these programs because the symbol table that these programs use has been stripped out of the kernel to save space. The easiest way to fix this is to get a different kernel (build it yourself). Of course, you can have a fully functional system with these programs, but they are nice to have. 2.7.7 I get a 'Floating point constant out of range' when I try to compile package 'n'. What is broke? This problem was encountered during many package compilations, including compiling gcc-2.3.3 under NetBSD-0.8. NetBSD-0.9, and presumably FreeBSD, contain a repaired printf() function, which corrects this problem. The easiest solution for this (and MANY other) problems is to upgrade. In addition, these systems also include gcc-2.3.3 (or newer) as the default compiler. There is also a circular dependency for protoize.o/unprotoize.o in the Makefile. Add the lines touch protoize.o touch unprotoize.o after the line: touch stamp-proto After this "make bootstrap" will run to completion. gas apparently has bugs too. It should produce +Infinity. I think it is OK internally but it may be trusting the library too much. gcc can easily be changed to avoid printf for output, but input is harder. One of the problems is that various pieces of code rely on the value of DBL_MAX. A kludge to fix it is to change the line below: #define DBL_MAX 1.7976931348623157E+308 One value that works is #define DBL_MAX 1.7976931348623147E+308 ^ was 5 This is a kludge, but it does mostly work. The problem is entirely in printf() (really in cvt()), NOT in atof(). I have inspected the output of atof() bit by bit, and it is well within IEEE specification. The digits `157' are the `best' approximation. The code for printf() generates a representation which is not even in the range of doubles. Below are the details: atof("1.7976931348623157e+308") returns 0x7fefffffffffffff which is the maximum double value and is correct. However, printf() of the previous yields `1.7976931348623168e+308', which isn't even within the floating point range. It is clearly printf() that is broken, and a quick inspection of the code is enough to determine that it uses a pessimal algorithm. atof() has been tested with many other values, and it has never been off by more than is allowed by IEEE 754 (though it is not optimal). 2.7.8 I want to use the Adaptec 1542C SCSI controller. What are the problems/tricks you need to know to get it working? The first thing to check when trying to use the 1542C is the setting of 'Enable Disconnection' under the 'SCSI Device Configuration' menu. It should be set to YES for all devices, as the manual warns you. Matthias Urlichs (urlichs@smurf.ira.uka.de) has provided this description of the types of things that can cause problems for the controller and devices attached to it. The problem is that the Adaptec 1542C has (a) rather powerful line drivers, and (b) is sensitive to transient signals which can be induced by them via either a bad cable or a bad external terminator. A bad cable is almost any cable which doesn't meet SCSI-2 specs. A bad external terminator is one which doesn't adequately buffer its resistor network. So... - Remove the internal terminator from the last drive in your chain. Replace with an active SCSI-2 external terminator. Side improvement: active terminators consume a bit less power. - Check cables. Specifically, some cables carry less than the nominal 50 signal wires. Manufacturers sometimes think they can get away with this because almost all odd-numbered pins are GROUND anyway. So, if pins 1 and 3 or 3 and 5 are connected, you're likely to have a marginal cable. - Make sure that the terminator power is supplied by all devices and that the power pin is actually connected on your cable. The problem here is that some idiot device manufacturers save on 2-cent diodes, which means that the thing will pull terminator power to ground if it's not plugged in. (Two of these on one bus are even worse.) - Consider creating your own cabling. Take a 50-wire flat ribbon and press the appropriate connectors onto it in precisely the right places. (Move your devices as to minimize cable length.) Be aware that if a device has two external connectors, you must take the SCSI bus in at one connector and out at the other -- don't leave the other connector dangling; this isn't within the SCSI specs because the cable usually is too long. - Better but more expensive: use 2-twisted cable. (I.e., wires 1&2 are twisted around each other, wire 3&4, ...) This will improve reliability because the wires are twisted at different rates. These cables have short non-twisted segments every 50 cm (1.5') so that you can press on your connectors instead of heating up that soldering iron. - While you're rebuilding your system anyway...: If you have more than one drive per power supply, check if these drives have adequate condensors to buffer their power. I have two 80-MB Seagates which refused to work more than a few hours without glitches -- then I soldered two 10-uF Tantals onto their power connector and they've been flawless ever since. The terminator power is pin 26. Be aware that SCSI counts pins as they appear on a ribbon cable, not as they're sometimes numbered on the connectors. Pin 25 is supposed to be disconnected. 2.7.9 My system boots OK off the floppy, but once I try to boot from the hard drive, the message "changing root device to sd0a" appears and the system hangs. What is the most likely thing that I have done wrong? A common cause for this is when all of the right devices aren't created on the root partition. Since you say you can boot off of a floppy, do so and check to make sure everything in /dev exists. You might consider running "MAKEDEV all" to be sure everything is created. (Ed.Note: I find that whenever I create a new kernel, it isn't a 'bad' idea to run a precautionary MAKEDEV to make sure that the devices are created correctly. Since I only build a new kernal about once a month, it isn't a very costly insurance policy.) Also, there are known problems with IRQ configurations and the PCI bus. The system hanging right after the changing root device message usually indicates a misconfigured IRQ for the controller. The initial probes by most (all?) drivers are done in polled mode, only when mounting the disk for real does the kernel begin to do interrupt driven I/O and DMA. Is this system a PCI system? Is the SCSI controller a PCI board? If so, make sure the IRQ configured in the PCI bios matches the IRQ configured for the card. Also, with PCI, forgetting to enable the slot for "master" in the BIOS setup or motherboard jumpers or putting a bus mastering card in a slave only slot will give simlar symptoms. The system may not have problems under DOS because some SCSI BIOS or device drivers don't actually use the DMA or bus mastering features of the card... {sigh}, they run in PIO mode under DOS. 2.8 Other common problems that are attributed to the installation process but are caused other places. 2.8.1 Why don't the man pages for "magic" and "file" work? The manual page for magic and file all have two dots before the commands, e.g.. "..SH" it should be ".SH" just delete one of the double dots in the whole file and then it will work. These man pages are fixed by both the patch-kit, NetBSD, and FreeBSD. The only time this problem every occurs is when you are using the distribution from one of the old CD-ROM distributions are get the original 386bsd 0.1 release. 2.8.2 Why is apropos broke? The Makefile in /usr/othersrc/share/man/Makefile creates the whatis.db. The problem is that it doesn't strip the backspaces in the title and apropos can't handle that. So add a "col -b" to strip those. excerpt from the Makefile. makedb: for file in `find /usr/share/man -type f -name '*.0' -print`; do \ sed -n -f /usr/share/man/makewhatis.sed $$file; \ done | col -b | sort -u > whatis.db install -o ${BINOWN} -g ${BINGRP} -m 444 whatis.db \ ${DESTDIR}/usr/share/man This problem is also solved in the patchkit, and other *BSD releases. Also, if the Makefile is moved to the /usr/share/man directory, the whatis.db will reside where it needs to eventually reside, and the install will wipe it out. An easy fix for that problem is to change the two references of whatis.db in the excerpt above to /tmp/whatis.db. This will ensure the file is correctly built and installed. 2.8.3 I want to use more than 16 Megabytes of memory. Will any of the BSD based systems support it? Early on, 386bsd 0.1 would choke radically on any system that had more than 8M of memory. With the advent of the patchkit, this problem was, for the most part, solved; memory could then expand to the 16M limit inherent in the ISA bus. As people started using VESA and EISA busses, however, attempts were made to push the envelope even further. Memory limits have expanded seemingly without limit. Since the EISA bus (for example) has 32 address lines, it is capable of supporting more memory than the ISA bus with its 24 address lines. While the 386 and 486 are capable of addresses up to 4 Gigabytes (considerably more than the ISA bus allows) the ISA bus is still the primary limitation. When using NetBSD and FreeBSD, there is no SOFTWARE limitation on more than 16Meg of memory. There are still hardware limitations. The limit is caused by DMA controllers which copy memory images around the system. Many cards which people use in VESA and EISA machines either emulate ISA cards (in order to work with *BSD) or are really ISA cards. There are reports of people having trouble with more than 64Meg of memory, but anyone rich enough to have that kind of memory should be paying for his OS. :-) Recently some folks have been reporting that they are getting warnings like these: hostname /netbsd: sd0: not queued hostname /netbsd: aha0: DMA beyond end of ISA hostname /netbsd: sd0: not queuedaha0: DMA beyond end of ISA This error is caused when the buffer for I/O is beyond the address range that the ISA bus can reach. With 16M you should be okay, however, some motherboards do reclaim all or part of the "lost" 384K (from the I/O "hole" from A0000-FFFFF) and put it just beyond the end of the rest of the memory, so you actually get 16M plus a little bit. One fix is bounce buffers. FreeBSD has implemented this, and NetBSD will as soon as they come up with a method that is compatible with all of the machines that NetBSD supports. Another fix is to either turn off the reclaiming of the extra memory (most motherboards that do this allow you to disable it), hack machdep.c to force the physical memory used to 16M, or use a 32 bit bus (EISA, VLB, or PCI) controller. Jordan K Hubbard (jkh@thrush.lotus.com) has provided this explanation of the distinction: Just so long as you're using a DMA-using disk controller in EISA mode, rather than ISA mode, you can use more than 16 Meg of memory. For those who may find such a distinction confusing, let me explain: You can use an ISA controller (such as an Adaptec 1542) in an EISA machine, but as it will still think it's in an ISA box and refuse to use the extra address lines, this is no different than having an ISA machine as far as >16MB is concerned. You can use an EISA controller in "ISA mode", meaning it uses the older protocols for compatability reasons (examples being Adaptec 1742 in "standard" mode, DTC 3290 in "Adaptec" mode, etc.) and again, does not use the extra address lines. The only way to get full EISA, 32MB-of-memory-and-everything, mode is to use an EISA controller in full EISA mode (for Adaptec 1742, this is "enhanced" mode, for DTC 3290 it's "DTC" mode, the Ultrastor 24F in EISA (rather than IDE emulation) mode, etc.). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In addition, several other types of ISA controllers which do NOT use DMA will not cause problems. IDE, ESDI, and RLL controllers are examples of this type of card. The discussion above also applies to VESA and VLB cards. So, the bottom line is that you are limited to the amount of memory that your DMA equipped devices can access. Once again, the weakest link is the strength of your machine. 2.8.4 I tried to use a device in my computer that should be there. When I did, I got a "Device not configured error." What do I do now? Garrett A. Wollman (wollman@emba.uvm.edu) provides us with this brief discussion in answer to a specific question. It wears well as a generic answer as well. When any program tells you ``Device not configured'', it's trying to tell you something very important about what you tried to do: namely, that the device you tried to access is not configured into the running operating system. This is the error message corresponding to ENXIO. There are three major causes for this error: 1) The kind of device you requested was not configured into the system. This is R.W.'s problem; the generic kernels are not distributed with the Berkeley Packet Filter enabled by default. To correct this, you must add the appropriate device or pseudo-device to your kernel configuration file and recompile. (In this particular case, `pseudo-device bpfilter number-of-network-interfaces'.) 2) The kind of device you requested was configured into the system, but either the device you requested would use more than the maximum you configured into the system, or if a physical device, was not found during autoconfiguration. To solve this, either change your configuration file, or change the I/O settings on the device to match what the file says. 3) The major or minor device number specified by the device's entry(ies) in /dev is incorrect. To solve this, re-MAKEDEV the device (read the MAKEDEV script for more details). Hopefully whatever change caused the kernel's internal device tables to get changed also updated your MAKEDEV script; otherwise, you will have to grovel through the kernel to see what is going on. 4) A special case: Although the 'c' drive on most BSD disks is the entire disk, in many NetBSD and FreeBSD systems, the entire drive is the 'd' disk. This special case is wired into many programs, and is recognized by the kernel. From time to time, folks will try and access the 'c' partition on their harddrive, only to be rebuffed with a 'device not configured' error. Mostly, the 'c' partition is unavailable simply because the partition type is 'unused' even though it is allocated and has space set aside for it. -- Dave Burgess (The man of a thousand E-Mail addresses) 386bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom "Just because something is stupid doesn't mean that there isn't someone that wants to do it...." From csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail Thu Apr 13 15:16:27 1995 Path: csus.edu!csulb.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 4 of 10) Supersedes: <386bsd-faq-4-795078010@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 27 Mar 1995 01:00:27 -0600 Organization: Dave's House in Omaha Lines: 1395 Sender: burgess@cynjut.infonet.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 04/14/95 02:00:10 CDT Message-ID: <386bsd-faq-4-796287611@s069.netins.net> References: <386bsd-faq-1-796287611@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.infonet.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:17 comp.unix.bsd.freebsd.announce:16 comp.answers:10853 news.answers:40663 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part4 Section 3. (Kernel Building and Maintenance) 3.0 System Internals One of the interesting aspects of *BSD is the fact that it comes with the complete source. This allows you to make changes to the system, recompile, and test out your new ideas. This section of the FAQ describes many of the different aspects of this endeavor and common problems and pitfalls that are encountered. Kevin Lahey provided the substantial portion of this section. You can contact him via E-Mail at (kml@rokkaku.atl.ga.us) or contact Dave Burgess (burgess@cynjut.infonet.net). 3.1 Kernel 3.1.1 How do I build a kernel? The kernel can be compiled in a variety of ways to support different devices and configurations. Compilation is controlled by a config file that specifies the characteristics of the kernel. A set of different config files is located in /sys/i386/conf or /sys/arch/i386/conf. The configuration file names are in upper case. To build a particular kernel (in this example, we use the GENERICISA configuration file in NetBSD or FreeBSD): % cd /sys/i386/conf % config GENERICISA % cd /sys/compile/GENERICISA % make depend % make If you are using 386bsd 0.1, you'll need patch 1 from the patchkit to get the compilation to work, because the version file isn't correctly included in the Makefile. In NetBSD, since there are multiple architectures supported, there is an architecture line in the middle of the path to these files. See the build.kernel script in section 3.8 for more information. 3.1.2 I want to do one of the following things: * add a device not in the distributed kernel (third com port, additional disk or tape, line printer driver, etc). * use a patch from the net or the patchkit to fix a kernel bug. * add another swap device. * recompile the kernel to remove extraneous devices so that it takes up less space. * configure more pseudo-terminals to allow for more xterms or network logins. You're going to have to recompile the kernel after you modify the config file. See section 3.2 below for more information about the config file in general. 3.1.3 I don't have the source distribution -- how can I rebuild the kernel? There are reference sites available, as well as the 'good net-neighbor' policy, whereby you could make arrangements with a net neighbor to use a large local machine as a Network File System (NFS), or allow you to compile a new kernel on their machine and transfer it to yours. You can also ask for help from comp.os.386bsd.questions if you get stuck and cannot make any headway. 3.1.4 Now that I have a kernel, how do I install it? Your kernel is called /386bsd or /netbsd. Copy the new kernel from /sys/compile/GENERICISA/386bsd to /, assuming that it is in that directory. This is relatively straightforward; there are a couple of things to remember, though. First, if you really screw up the new kernel, you want to have something to fall back on, so be sure to save /386bsd to /386bsd.old before copying in a new kernel. Second, if you just copy the new kernel over the currently running kernel, funny things can happen. Be sure to move aside the currently running kernel before copying over the new one. There are folks that have reported that overwriting their current kernel has never caused them any real problems. On the other hand, if the old kernel was working and the new one doesn't, and you have made changes that require that old kernel, it should be available to the system, and saving it to /386bsd.alt or /386bsd.old are reasonable things to do. If you are really paranoid, you can mount a new fixit floppy and replace its kernel with the one you just built, and then boot from the fixit floppy to make sure everything will work. This is a pretty good idea if you are making radical changes or if you are unsure about your changes. 3.1.5 After installing the patchkit and recompiling the kernel with the option "WD8013", I am no longer able to reboot the machine. A cold boot (power on) runs fine, but after a reboot no boot drive is found by the BIOS. Besides having a 16-bit WD/SMC Ethernet card installed the machines try to boot using either a Adaptec 1742 or 1542 SCSI board to boot from. This answer was provided by Hellmuth Michaelis (hm@hcshh.hcs.de) and by Rodney Grimes (rgrimes@acacia). Remove "option WD8013" from the config files and recompile and reinstall the kernel. The reason that option WD8013 often causes this reboot problem is this: There is a requirement that all memory within a 128k bank in the 0xA0000 to 0xFFFFF region be either 16-bit or 8-bit. On a cold boot, the WD8013 boards are reset to 8-bit mode, the POST (Power On Self Test) passes without error. 386bsd comes up, the if_we.c driver places the WD8013 in 16-bit mode. Now on a soft boot when the BIOS runs some quick POST tests it finds a problem in the 0xA000 to 0xF000 region. You probably get a "beep-beep" when this happens. It means you have a memory size conflict. The machine has been mis-configured. This is a little known fact about 16-bit vs 8-bit option cards. It has caused more than one person to go crazy tracking down what they swear is a bug in the program. It is not, it is a flaw in the design of the ISA bus. The signal MEMCS16- must be returned the same for every 128k block of memory: A0000-BFFFF Must all be either 8-bit or 16-bit. B0000-CFFFF Must all be either 8-bit or 16-bit. D0000-FFFFF Must all be either 8-bit or 16-bit. In your particular configuration (WD8013 @ cc000) I suspect that you have another board in the B0000-CFFFFF region that is 8-bit, i.e. your Adaptec has an 8-bit BIOS on it! Try moving the board to the 0xD0000 region and see if it works there, you may still have a problem as many modern system BIOSes are now 8-bit. If your system BIOS is 8-bit, try shadowing the system BIOS region at 0xF0000 to 0xFFFFF, this effectively turns it into a 16-bit BIOS. Do not attempt to shadow the WD8013, it will cause you many headaches. In fact, it sometimes helps to turn on BIOS shadowing. Some BIOSes allow to copy ROM contents to unused RAM pages for selected 16KB-regions. While it is generally a good idea to turn BIOS shadowing off, I have also observed that sometimes it helps to turn shadowing of true ROM regions on. 3.1.6 My system is complaining about stray interrupt 7. Is my machine going to explode or anything? No. They are caused by lots of things. They are, as far as anyone that should be expected to know about this stuff, harmless. There are ramifications on them being there, but for MOST users they do not pose a real threat to your operations. For those of you that are doing REALLY interrupt intensive stuff, you may want to grab a technical reference and figure out why the 8259 is not getting reset correctly. In spite of the number of times this has come up (and people have even referenced this section) there are still at least two questions on the net about this. A memorable one was a guy who was just vehement that the stray int 7 was what was keeping his system from booting. In fact, he went so far as to say that this document was practically worthless because I didn't tell him how to fix it. Of course, once he configured his hard drive controller so that it was on the right interrupt, his booting problem went away. I have said it before and I will say it again. For MOST users they do not pose a real threat to your operations. I have heard of three people (out of at least 2000) that have actually have problems so bad that they couldn't proceed. They bought new computers, and the problem went away. These stray interrupts are caused by something in the PC. I have yet to see a convincing explanation of precisely what, but they are definitely caused by something. There are four ways to deal with this problem. 1) Ignore them. They are spurious and do not effect the operation of your computer. 2) Implement the lpt driver. This way, the driver traps (the lpt driver expects IRQ 7) and then quietly discards them. That is why when folks implement the lpt driver the 'problem' goes away. The computer is taught how to ignore them. 3) Do what the original 386bsd code did. Comment out the diagnostic and associated code that tries to deal with them so you don't see the error message. 4) Buy a new computer that doesn't cause this problem. It is a known hardware problem with the 8259 being reset incorrectly in hardware. Kalevi Suominen (jks@geom.helsinki.fi) offers this technical explanation of the 'stray interrupt 7' phenomenom. In the section of the Intel Peripheral Handbook dealing with the 8259A there is a description of the 6-step interrupt sequence for an 80x86 system (and 7-step for an MCS-80/85), and then the following paragraph: "If no interrupt request is present at step 4 of either sequence (i.e., the request was too short in duration) the 8259A will issue an interrupt level 7. Both the vectoring bytes and the CAS lines will look like an interrupt level 7 was requested." This explains how some transient disturbances or improperly functioning adapter cards could trigger a stray interrupt 7 in a system operating in the *level* interrupt mode (such as a PS/2 with MCA): An interrupt request will disappear as soon as the interrupt line goes inactive. That such interrupts may also occur in a system operating in the *edge* triggered mode (such as an ordinary PC/AT with ISA) is a little harder to see. Yet it is possible - even without malfunctioning hardware - because masking an interrupt request will hide its presence from the 8259A as well: 1. The interrupt flag (IF) of the 80x86 is reset either directly (e.g., by a "cli" instruction) or because an interrupt handler is entered. In the latter case the corresponding in-service (IS) bit of the 8259A is set (effectively blocking interrupts of lower priority). 2. The 8259A receives an unmasked interrupt request (IRQn), and, in case an interrupt is being served and has higher priority than IRQn, the IS bit of the 8259A is reset by an end of interrupt (EOI) command. (These steps may occur in either order.) If IRQn has higher priority (e.g. IRQ0), no EOI is necessary. 3. The 8259A activates the interrupt (INT) line to the 80x86 (which will ignore it - for the moment). 4. The interrupt mask (IM) bit of the 8259A for IRQn is set. (A little late, though. The sequence has already started.) 5. The interrupt flag (IF) of the 80x86 is set (either directly, or as a consequence of e.g. an "iret" instruction). 6. The 80x86 will now acknowledge the INT request by activating the INTA line of the 8259A. 7. The 8259A will not see the masked IRQn and will continue by issuing a spurious interrupt of level 7 instead. The original interrupt request (IRQn) will not be lost, however. It is preserved by the associated edge sense latch of the 8259A, and will be acted on after the IM bit has been reset again. The net result is that a single interrupt request will be delivered *twice* to the 80x86: first as a stray interrupt 7 and later as the proper interrupt. In particular, it is perfectly safe to ignore the stray interrupt (other than sending an EOI). It is just the ghost of an aborted interrupt sequence: the system was not prepared for it yet. 3.1.7 I keep getting "wd0c: extra interrupt". What does it mean? It means that the drive was already processing a command (active) when it recieved an interrupt from the system telling it to see if it had anything to do. This is mostly harmless but could indicate that the drive/controller is having problems if the message appears often. 3.1.8 I found a bug in the kernel. How do I report it? Both NetBSD and FreeBSD include a facility called 'bugfiler'. While the instructions are included in both system, there is still some apparent confusion about when to use (and when to NOT use) bugfiler. Jordan K. Hubbard (jkh@whisker.lotus.ie) provides us with this short article for FreeBSD. To send bug reports, you want to use the sendbug(1) command. The entire package for sending and filing these bugs is known as "the bugfiler", which is where the confusion stepped in, but sendbug is definately the command you want to use. Second, it doesn't take a "net connection" to use sendbug, since all it does is package up your "bug report form" and mail it to us; no direct internet connectivity is required, just mail. So if you can send internet mail you can use sendbug, or you can also send mail to the `FreeBSD-bugs@freefall.cdrom.com' address (do NOT send it to FreeBSD.cdrom.com since it will BOUNCE, this is not the place to send bugs to, just to ftp stuff from!). NetBSD has a similar facility, but has a different program and host for bug reports. The program for NetBSD is called send-pr and is slightly different in several respects. It is recommended that NetBSD users see the man page on send-pr before filing bug reports. 3.1.9 Can someone please give a reasonably clear set of instructions as to how to get a "current" version of NetBSD running? Marc Wandschneider provided this description of what he did to upgrade to the (then) current version of NetBSD: 1. Delete the old source tree, saving what I wanted to (a bunch of files moved around, and just unpacking the new one over the old will cause some problems) 2. Unpacked the new source tree. 3. ran the following sequence of commands: cd /usr/src/share/mk; make install cd /usr/src/include; make && make install setenv LDSTATIC -static setenv NOPIC cd /usr/src/lib/libc; make && make install cd /usr/src/gnu/lib/libmalloc; make && make install cd /usr/src/gnu/usr.bin/gas; make && make install cd /usr/src/gnu/usr.bin/ld; make && make install # You'll probably get some barfage from the above because # ld.so won't build yet. Ignore it and install ld anyway. cd /usr/src/gnu/usr.bin/gcc; make && make install unsetenv NOPIC LDSTATIC cd /usr/src/lib ; make && make install cd /usr/src/gnu/lib ; make && make install cd /usr/src/gnu/usr.bin/ld; make && make install cd /usr/src; make && make install At some point during the installation, your system will be fixed enough that many of these steps will no longer be required. For example, the new 'make' defines the variables OBJDIR and MACHINE_ARCH for you, so you will not need those once you get to that point. Until then, the following procedure may suit your needs better. #! /bin/csh unsetenv NOPIC LDSTATIC setenv MACHINE_ARCH i386 # Pick one of these three setenv lines. # setenv MAKE "make clean " # setenv MAKE "make obj " setenv MAKE cd /usr/src/share/mk make install cd /usr/src/include $MAKE make && make install setenv LDSTATIC -static setenv NOPIC cd /usr/src/usr.bin/make $MAKE make && make install cd /usr/src/usr.bin/rpcgen $MAKE make && make install cd /usr/src/lib/libc $MAKE make && make install cd /usr/src/gnu/lib/libmalloc $MAKE make && make install cd /usr/src/gnu/usr.bin/gas $MAKE make && make install cd /usr/src/gnu/usr.bin/ld $MAKE make && make install cd /usr/src/gnu/usr.bin/gcc2 $MAKE make && make install # unsetenv NOPIC LDSTATIC cd /usr/src/lib $MAKE make && make install cd /usr/src/gnu/lib $MAKE make && make install cd /usr/src/gnu/usr.bin/ld $MAKE make && make install cd /usr/src make && make install NOTE: At some point, you might very well come across an unresolved external __DYNAMIC in crt0.o. If this happens, edit the makefile for crt0.o (lib/csu/i386) and remove the -DDYNAMIC flag) make && make install. Then put the flag back in the makefile (but don't rebuild it until the natural order of things dicates that it happen) And Theo Deraadt provides this guidance when you get an error like "init_main.o: Undefined symbol _pdevinit referenced from text segment." You need to (1) install new config (2) make clean (3) re-config your kernel then this goes away 3.2 What exactly is this config file, anyway? What are all of these cryptic notations? I've annotated the distributed 386bsd GENERICISA file; my comments are delineated by the '--' symbols. THIS IS NOT A COOK-BOOK. YOU WILL NEED TO DO THE RESEARCH (LIKE LOOKING AT THE 20 OTHER CONFIG FILES) TO SEE WHAT IS CURRENT AND WHAT YOU WILL NEED IN YOUR CONFIG FILE. # # GENERICISA -- Generic ISA machine -- distribution floppy # -- BSD can be compiled for different hardware platforms, so it is important to -- define the hardware types. 386bsd can only be built for 386 or -- compatible machines, so this is sort of superfluous, but maintains -- compatibility with standard BSD config files. machine "i386" cpu "i386" -- The ident describes the machine for which this kernel is to be built. -- It is usually the system name -- "ROKKAKU", "REF", or whatever. -- This can be used for conditional compilation, so that kernel changes -- can be compiled in only for one machine. ident GENERICISA -- This should indicate the timezone of the system relative the -- Greenwich. 8 is PST; 4 is EST. A fuller explanation is provided -- below. timezone 8 dst 7 -- maxusers isn't strictly checked; it is just used to size several -- system data parameters. maxusers 10 -- The options control the conditional compilation of features into the -- kernel. The options can be listed all on a line separated by commas. -- They are #define'ed when the kernel is compiled, so that #ifdef's -- will work. An option can be given a value by appending an equals sign -- and a value (enclosed in double quotes) to the option name. -- Hopefully the names are at least somewhat self-explanatory. To -- discover what everything does, you'd have to go through the kernel -- looking for all of the appropriate #ifdef's. -- [Perhaps somebody else could list the *exact* meanings of these -- options and some of the other possible options?] options INET,ISOFS,NFS options "COMPAT_43" options "TCP_COMPAT_42" -- The config line controls the location of the root, swap, and dump -- devices. Anything not specified is defaulted. This is where you add -- support for multiple swap devices. Just list 'em, separated by 'and'. -- The config line below identifies the root drive as wd0 and the -- swap drives as wd0 and as0. See the section on swap devices in FAQ_02 -- for additional information. config "386bsd" root on wd0 swap on wd0 and as0 -- A 'controller' is a device or bus controller. 'isa' is obviously for -- the ISA bus. 'wd0' is for regular disk controllers, 'fd0' is for the -- floppies, and 'as0' is for SCSI disk controllers. controller isa0 -- The fields work as follows: -- a. What do you call this device? -- b. What controller is this on? As you can see, the disk controller -- talks to the ISA bus, and the disks talk to the disk controller. -- c. Where are the registers for the controller mapped into memory? -- This is #defined in /sys/i386/isa/isa.h. -- d. What IRQ is this device set up for? -- e. What routine should be called on an interrupt from the device? -- a b c d e -- vvv vvv vvvvvvv vv vvvvvv controller wd0 at isa? port "IO_WD1" bio irq 14 vector wdintr -- You need a 'disk' entry for every disk on the controller. In the -- config file originally shipped with 386bsd, both hard disks were -- incorrectly identified as wd0. Be sure to change the second occurrence -- to wd1, as I have done in below. disk wd0 at wd0 drive 0 disk wd1 at wd0 drive 1 controller fd0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fd0 drive 0 disk fd1 at fd0 drive 1 -- The 'drq' specifies the channel used for bus-mastering DMA. controller as0 at isa? port 0x330 bio irq 11 drq 5 vector asintr disk as0 at as0 drive 0 disk as1 at as0 drive 1 -- Define other physical devices. pc0 is the keyboard, npx0 drives the -- math coprocessor, and com* controls the com ports. device pc0 at isa? port "IO_KBD" tty irq 1 vector pcrint device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device com1 at isa? port "IO_COM1" tty irq 4 vector comintr device com2 at isa? port "IO_COM2" tty irq 3 vector comintr -- Ethernet drivers of various sorts and the particular configuration -- information they require. For most installations, only one of these -- devices would normally be defined. device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr device ne0 at isa? port 0x300 net irq 2 vector neintr device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr device is0 at isa? port 0x280 net irq 10 drq 7 vector isintr -- Tape driver device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr -- The TCP/IP loop-back device, ethernet interface, slip interface, log -- device, and pseudo-terminals. pseudo-device loop pseudo-device ether pseudo-device sl 2 pseudo-device log pseudo-device pty 4 -- Devices required by VM. pseudo-device swappager pseudo-device vnodepager pseudo-device devpager Normally, there is an annotated configuration file called ALL which gives a list of all of the options for the configuration file. The configuration file that was used to create the list above was for a 386BSD system. Many things have changed in the config files for NetBSD and FreeBSD. As an example, the psuedo-devices swappager, vnodepager, and devpager are now full fledged devices. Like it said up at the top, use the config files that come with your system as a basis for your own experiments in kernel building. 3.2.1 Okay, fine. Why shouldn't I just add every device I can find to the kernel, so I'll never have to recompile this again? Because it takes up space. The kernel is wired into memory, so every byte it uses comes out of the pool of memory for everything else. It can't page out sections that aren't in use. If your kernel is larger than 640K, then it can't be loaded. You'll need to use Julian Elischer's bootblocks to put it in high memory, which seem to be fairly complex. Installing them (once they are compiled) is as easy as using disklabel. Newer versions of the *BSD kith provide the capability to build a kernel that is larger than 640K. Complete instructions are provided in the appropriate systems. 3.2.2 What should I remove from the kernel? What do you need? If you only have an SCSI controller, you don't need the wd0 device; if you have another kind of disk controller, you don't need as0. Unless you actually HAVE more than one Ethernet controller, you should comment out all but one of them. If you don't have an ethernet controller, you don't need any of the controllers or NFS compiled in. Without a CD-ROM, ISOFS is kind of pointless. Just look at what you have and think about what you really need. 3.2.3 I can't get enough remote login sessions or xterm sessions. I also can only get four sessions working at a time. What can I do? Increase the count of pseudo-terminals -- pseudo-device pty 12 # or whatever Every pseudo terminal should have a /dev/pty* entry. If you have 12 pseudo terminals, you should also have at least 12 pty devices in the /dev directory. The MAKEDEV script in /dev will create as many pseudo- terminals as you tell it to. 3.2.4 How do I get ddb, the kernel debugger, compiled into the kernel and running? If you are using older versions of the 386BSD family, you will need to add a line in your config file that looks like this: device-pseudo ddb If you are using a more recent version (the division is pretty unclear about when the switch was made) and do not have any device-pseudo entries, you will need to add the line: options DDB to your config file. Build the kernel, then run dbsym on it: % dbsym ./386bsd Install it and go for it. Ctl-Alt-Esc drops you into the debugger. Note: DDB as shipped originally is a memory hog, and it is very difficult to get a kernel small enough with enough fun things in it to debug in 640K On the NetBSD-sparc system, the L1-A is used by the the DDB routines to drop you into the debugger. 3.2.5 Can I patch the current running OS image? In general, I think, the answer is no. The prevailing philosophy seems to be that one should use sysctl for such things, but that requires that one has already compiled in the ability to change the specific variable in question. (I discovered this when I wanted to patch tickadj at runtime; I added it to kernfs, and when I offered the patches (which are quite small) I was told sysctl was the `correct' way. What's incorrect about /kern was never quite explained; the closest anyone came was to invoke internationalization concerns. Of course, using /kern also requires having compiled in support for tweaking the variable you want to change.) Besides, unless you've patched securelevel, I don't think there is any good way to twiddle variables in the running kernel. /dev/{,k}mem are, I believe, read-only once init sets securelevel to 1. Der Mouse (mouse@collatz.mcrcim.mcgill.edu) 3.2.6 Can I have more than one config file? Should I rename it to something else? Any other hints? You can create as many (or as few) config files as you desire. The system, once the patchkit is applied, will have between 10 and 15, each of which implements certain functions or features. In addition, the normal place for the patchkit to make changes to the config files is in the GENERICISA file. Since this file should remain unchanged and available, it is always a good idea to copy this file to a meaningful name and modify that file. In other words, change every reference in 3.1.1 from GENERICISA to HAL (or whatever you call your system). One final note. Every /sys/compile directory takes up 800K or so; you might want to watch to see how big these all get. 3.2.7 What is the meaning of the trap codes I get in panic messages? Sometimes this message appears in the form "trap type nn". That message means that the system received an unexpected (and unwanted) trap that probably indicates some form of kernel bug. These traps, are usually received from the kernel, in which case the trap.h definitions should be used. The number (which appears in place of "nn" above) is *NOT* the i386 or i386 trap type, it is a BSD-defined trap type number. The definitions of the various trap types can be found in /usr/include/machine/trap.h. two of the more common ones are: 9 T_PROTFLT protection fault (The kernel tried executing code which was not noted as "executable". This happens if the kernel jumps to a bogus location.) 12 T_PAGEFLT page fault (The kernel tried to access a bogus area of memory. This can happen if an invalid pointer is dereferenced.) This is a list of i386 trap codes (just to confuse the issue). Trap 0 Divide Error The DIV or IDIV instruction is executed with a zero denominator or the quotient is too large for the destination operand. Trap 1 Debug Exceptions Used in conjunction with DR6 and DR7, The following flags need to be tested to determine what caused the trap: BS=1 Single-step trap B0=1 AND (GE0=1 or LE0=1) Breakpoint, DR0, LEN0, R/W0 B1=1 AND (GE1=1 or LE1=1) Breakpoint, DR1, LEN1, R/W1 B2=1 AND (GE2=1 or LE2=1) Breakpoint, DR2, LEN2, R/W2 B3=1 AND (GE3=1 or LE3=1) Breakpoint, DR3, LEN3, R/W3 BD=1 Debug registers not available, in use by ICE-386 BT=1 Task Switch Trap 2 NMI Interrupt On PC/AT systems, the NMI input to the CPU is usually connected to the main memory parity circuit. By the time the error signal is generated, the data may have already been used in an instruction, so it isn't possible to reliably recover. And some not-so-common causes (from various sources): PS50+ : I/O channel check, system watch-dog timer time-out interrupt, DMA timer time-out interrupt parity errors on any 8-bit or 16-bit board pulling the IOCHCK* line low first generation of auto-switching EGA cards used NMI to trap port access for CGA emulation (e.g., ATI's EGA Wonder) Zeos Notebook low battery (perhaps other battery-based computers) Trap 3 Breakpoint The result of executing an INT 3 instruction. MS-DOS and Windows and some other non-386 systems use this for debugging. Code specific to the 386 and later processors should use the debugging features tied to Trap 1. Trap 4 INT0 Detected Overflow Occurs if an INT0 instruction is executed and the overflow flag (OF) is currently set. Trap 5 BOUND Range Exceeded Occurs if the BOUND instruction is executed and the array index points beyond the area of memory containing the array being tested. Trap 6 Invalid Opcode The value read at CS:IP is not a valid opcode. Trap 7 Coprocessor Not Available This occurs if the processor fetches an instruction that is for the coprocessor and no coprocessor is present. Trap 8 Double Exception (Fault) An exception occurred while trying to execute the handler for a prior exception. Example, an application causes a General Protection Fault (13) and the area of memory where the GPF handler should be is flagged not-present (paged-out?). The double-fault handler is invoked in these conditions. If a fault occurs while trying to run the double-fault handler, a triple-fault occurs and the CPU resets. The rules for deciding if a double-fault should occur or if the two faults can be handled serially are discussed in more detail in the Intel song book. Trap 9 Coprocessor Segment Overrun A page or segment violation occurred while transferring the middle part of a coprocessor operand to the NPX. Trap 10 Invalid Task State Segment During a task switch, the new TSS was invalid. Here is a table of conditions that Invalidate the TSS: TSS id + EXT The limit in the TSS descriptor is < 103 LTD id + EXT Invalid LDT selector or LDT not present SS id + EXT Stack segment selector is outside table limit SS id + EXT Stack segment is not a writable segment SS id + EXT Stack segment DPL does not match new CPL SS id + EXT Stack segment selector RPL <> CPL CS id + EXT Code segment is outside table limit CS id + EXT Code segment selector does not refer to code segment CS id + EXT DPL of non-conforming code segment <> new CPL CS id + EXT CPL of conforming code segment > new CPL DS/ES/FS/GS id + EXT DS, ES, FS or GS segment selector is outside table limits DS/ES/FS/FS id + EXT DS, ES, FS, or GS is not readable segment Trap 11 Segment Not Present Occurs when the "present" bit of a descriptor is zero. This can occur while loading any of these segment registers CS, DS, ES, FS, or GS. Loading SS causes a Stack fault. Also occurs when attempting to use a gate descriptor that is marked "not present", and if attempting to load the LDT with an LLDT instruction. Note that loading the LDT during a task switch causes an "invalid TSS" trap. Trap 12 Stack Fault A limit violation relating to an address referenced off the SS register. Includes POP, PUSH, ENTER and LEAVE opcodes, as well as references such as MOV AX,[BP+8] (which has an implied SS:). Also causes by loading SS with a descriptor that is marked "not present". Trap 13 General Protection Fault (GPF) Americas Favorite, in the Windows 3.0 world, it is known as the UAE error. The instruction tried to access data out of the bounds designated by the descriptors. The access that failed can be a read, write or instruction fetch. There are 15 classifications of GPFs: 1. Exceeding segment limit when using CS, DE, ES, FS or GS. 2. Exceeding segment limit when referencing a descriptor table. 3. Transferring control to a segment that is not executable. 4. Writing into a read-only data segment or into a code segment. 5. Reading from an execute-only segment. 6. Loading the SS register with a read-only descriptor (unless the selector comes from the TSS during a task switch, in which case a TSS exception occurs.) 7. Loading SS, DS, ES, FS or GS with the descriptor of a system segment. 8. Loading, DS, ES, FS or GS with the descriptor of an executable segment that is not also readable. 9. Loading SS with the descriptor of an executable segment. 10. Accessing memory via, DS, ES, FS or GS when the segment register contains a null selector. 11. Switching to a busy task. 12. Violating privilege rules. 13. Loading CR0 with a PG=1 and PE=0. 14. Interrupt or exception via trap or interrupt gate from V86 mode to privilege level other than zero. 15. Exceeding the instruction limit of 15 bytes (this can only occur if redundant prefixes are placed before an instruction). To determine which condition caused the trap, you need the instruction, the contents of all associated registers, particularly the segment registers involved, then the various LDT, GDT and page control tables. Lots of common coding errors cause the GPFs. Even a stack imbalance will usually show up as a GPF. Even MOV AX,7 MOV ES,AX or MOV AX,5 PUSH AX POP DS will get a GPF error. You can't use a segment register for "temporary storage" of any old value the way you could on the 8086. The values loaded into the segment registers are checked in protected mode. Trap 14 Page Fault The page directory or page table entry needed for the address translation has a zero in the present bit, or the current procedure does not have sufficient privilege to access the indicated page. Trap 15 (reserved) Trap 16 Coprocessor Error The coprocessor asserted the ERROR# input pin on the 386 (internal on the 486) Trap 17 Alignment Check (486 and later) If enabled, this trap will occur if a data fetch does not occur on a word boundary. I don't know of any software that activates this feature yet. I have seen SCO UNIX get this error on early Cyrix processors, even though SCO had not enabled the feature. Trap 18-32 (reserved) [answered by Frank Durda IV and jim mullens jcm@ornl.gov -or- mullens@jamsun.ic.ornl.gov] ------------------------------------------------------------------------------- 3.2.8 I have been getting a lot of "virtual memory exhausted" errors when I am compiling a program with a really big static array. I have 128Meg of memory and 8Gig of swap. How can this be happening? If you are using Csh, you can simply unlimit your processes in your system level /etc/csh.cshrc file or your personal .cshrc file. You can also modify your kernel so that the amount of memory available is less limiting. J"org Wunsch (j@tcd-dresden.de) provides us with this brief description: From a recent posting i just made, regarding the problem how much virtual memory one could get. | On the other hand, i've also changed the definitions you | mentioned. But i didn't like to modify the header files, and | actually, modifying the values is as easy as: | | options "DFLDSIZ='(16 * 1024 * 1024)'" | options "MAXDSIZ='(64 * 1024 * 1024)'" | | Include the above lines into your kernel's config file, reconfig | and rebuild it. | This is just a hint for those people poking around with compiling large source files. Especially, due to some gcc problems with large static arrays, compiling X applications with huge bitmaps would cause virtual memory trouble. Increasing the limits (o'course, as long as the h/w resources suffice) could help there. The default definitions for the above parameters are found in /usr/include/machine/vmparam.h. 3.2.9 Where can I learn more about all this? We've skipped over a lot of details here; the straight dope comes from "Building Berkeley UNIX Kernels with Config", by Samuel J. Leffler and Michael J. Karels. 3.2.10 Does anyone have a system building script that takes things like building a new config and multiple config files into account? This is the program that I use to rebuild my kernel. See the note in the file about my 'test' program. You may elect to build a new config every time, or not, depending on your requirements. #! /bin/sh # # Script to rebuild the kernel. # if [ `whoami` != 'root' ] ; then echo 'You must be root to successfully proceed from this point' exit 1 fi # # Set up the environment # if [ X$MACHINE_ARCH = "X" ] ; then MACHINE_ARCH=i386 fi if [ -f /netbsd ] ; then ARCHDIR='/arch' fi # # Rebuild Config # # I am using a modified test(1) that allows for file date comparisons. # You can either get my patches (if they aren't already included), # modify test() yourself, or get the GNU ShellUtils test(1) program. # if [ /usr/src/usr.sbin/config -ot /usr/sbin/config ] ; then echo "Config Up To Date" else cd /usr/src/usr.sbin/config make clean make depend make make install fi cd /sys make make install # # Modify the local Configuration File # echo `tput clr` cd /sys$ARCHDIR/i386/conf if [ "X$CONFIG_NAME" = "X" ]; then CONFIG_NAME=GENERIC fi if [ "X$1" = "X" ]; then echo "Configuration Files available:" ls [A-Z]* echo " " echo -n "Enter the name of the config file to use: " read CONFIG_NAME echo else CONFIG_NAME=$1 fi if [ ! -f $CONFIG_NAME ]; then cp GENERIC $CONFIG_NAME fi echo "Modifying $CONFIG_NAME config file" echo -n "Press return to continue (q to quit) " read ans ans=`echo $ans | cut -c1 | tr 'QqYy' 'qqqq'` if [ "X$ans" = "Xq" ] ; then exit 0 fi vi $CONFIG_NAME #config.new $CONFIG_NAME config $CONFIG_NAME COMPILE_DIR=/sys$ARCHDIR/i386/compile/$CONFIG_NAME cd $COMPILE_DIR make depend make if [ $? -ge 1 ] ; then echo "Errors encountered" else if [ -f netbsd ] ; then PROGNAME=netbsd else if [ -f freebsd ] ; then PROGNAME=freebsd else PROGNAME=386bsd fi fi echo `tput clr` echo "" echo " Manual Installation is recommended. The following files should be" echo "copied/linked/moved to the root directory. The following steps are" echo "suggested:" echo "" echo " mv /$PROGNAME /$PROGNAME.old" echo " mv $COMPILE_DIR/$PROGNAME /$PROGNAME" echo " reboot" echo "" echo "Remember that the new kernel changes will not take place until you " echo "re-boot the system." fi 3.3 X11/XFree86/XS3 3.3.1 What options should I define to get the X extensions included? Once you have applied the patch kit, the only thing left to do is to modify the config file to include the following line: options XSERVER, UCONSOLE recompile the kernel and the kernel should support X. 3.3.2 Where can I get the FAQ for 'X'? Steve Kotsopoulos' general 'X on Intel-based Unix' FAQ available by anonymous ftp from export.lcs.mit.edu in /contrib/Intel-Unix-X-faq. 3.3.3 Why does X drop characters when using xdm? When I run xdm from the console, it keeps losing keystrokes and the shift keys don't always work. Why? You need to run xdm with the -nodaemon flag. The reason is xdm normally detaches from the keyboard. This allows other processes (like getty) to return to reading from the keyboard. A race condition results, where some keystrokes are sent to xdm and others are sent to other processes. Using the -nodaemon flag causes xdm to stay attached to the keyboard so no other process can use it. This answer comes from Michael C. Newell (root@wanderer.nsi.nasa.gov) This bit of trivia is also covered in detail in the X FAQ and the README that accompanies XFree86. 3.4 Compiler and Library routines There are several questions that could probably be included here. See also Section 4 for some of the more common 'missing modules' that also happen to be library routines. 3.4.1 Which C compiler is shipped with my 386BSD derived system? The standard compiler released with 386bsd 0.1 is GCC 1.38. This version is considered by many people to be the most stable of the GCC versions. All other Net/2 derived BSD systems have both 1.38 and 2.4+ available. NetBSD 0.9, for example, is completely compilable using GCC 2.4.5, which is included as the default compiler. FreeBSD also ships with the same compiler. 3.4.2 Where is libcompat.a? The library libcompat.a is (working from memory here) completely deprecated in 386bsd. The only exceptions might be the re_comp and re_exec routines, which are discussed in detail in section 4. In addition, things will be added to libcompat.a as they are deprecated in the newer versions of NetBSD and FreeBSD. The getreuid() and setreuid() stuff may be heading that way (if they aren't there already. The easiest way around not having a libcompat.a is to simply link it to a small library, since virtually every other function that is expected in libcompat.a is already include libc.a. 3.5 You promised to talk about timezones below. Are you going to? >I've seen lots of stuff about timezone's being a bit dodgy, >especially with most European timezones changing over to DST on >the 27th March. I must say that that was NOT the case for me - >pumpy (the author's system) is running off the >/usr/share/zoneinfo/GB-Eire timezone file, (symbolically) linked >to /etc/localtime, the CMOS clock is running off GMT, and the >kernel is compiled with "timezone 0". I use /usr/share/zoneinfo/MET as /etc/localtime and have the kernel configured as timezone -1 dst 4 (My wife is running DOS on this machine for doom sometimes ;-) I set this strange dst value after diging in some old ultrix(?) man pages. There were several dst-changing-method listed and 4 was the code for the central europe one. This gave me an idea... I use an Ultrix box every day, so why not... Now, I don't know how closely this applies to NetBSD since Ultrix is based on a much older version of BSD, and this isn't for the kernel config, but for an envar of timezone values, but it's at least somewhat enlightening on possible meanings for these things. Could someone in the know shed light on how accurately this models the timezone stuff in the kernel config? When I did "man timezone" this is what I got (portion of this quoted from the DEC MIPS Ultrix 4.3a timezone(3) manpage, slightly hacked by me (Michael L. VanLoon (michaelv@iastate.edu)) STD offset [DST [offset][,start[/time],end[/time]]] the components of the string have the following meaning: STD and DST Three or more characters that are the designation for the standard (STD) or summer (DST) time zone. Only STD is required; if DST is missing, then summer time does not apply in this locale. Upper- and lowercase letters are explicitly allowed. Any characters except a leading colon (:), digits, comma (,), minus (-), plus (+), and ASCII NUL are allowed. offset Indicates the value to be added to the local time to arrive at Coordinated Universal Time. The offset has the form: hh[:mm[:ss]] The minutes (mm) and seconds (ss) are optional. The hour (hh) is required and may be a single digit. The offset following STD is required. If no offset follows DST, summer time is assumed to be one hour ahead of standard time. One or more digits may be used; the value is always interpreted as a decimal number. The hour must be between 0 and 24, and the minutes (and seconds) - if present - between zero and 59. If preceded by a "-", the time zone is east of the Prime Meridian; otherwise it is west (which may be indicated by an optional preceding "+"). start and end Indicates when to change to and back from summer time. Start describes the date when the change from standard to summer time occurs and end describes the date when the change back happens. The format of start and end must be one of the following: Jn The Julian day n (1 < n < 365). Leap days are not counted. That is, in all years, including leap years, February 28 is day 59 and March 1 is day 60. It is impossible to explicitly refer to the occasional February 29. n The zero-based Julian day (0 < n < 365). Leap days are counted, and it is possible to refer to February 29. Mm.n.d The nth d day of month m (1 < n < 5, 0 < d < 6, 1 < m < 12). When n is 5 it refers to the last d day of month m. Day 0 is Sunday. time The time field describes the time when, in current time, the change to or from summer time occurs. Time has the same format as offset except that no leading sign (a minus (-) or a plus (+) sign) is allowed. The default, if time is not given, is 02:00:00. As an example of the previous format, if the TZ environment variable had the value EST5EDT4,M4.1.0,M10.5.0 it would describe the rule, which went into effect in 1987, for the Eastern time zone in the USA. Specifically, EST would be the designation for standard time, which is 5 hours behind GMT. EDT would be the designation for DST, which is 4 hours behind GMT. DST starts on the first Sunday in April and ends on the last Sunday in October. In both cases, since the time was not specified, the change to and from DST would occur at the default time of 2:00 AM. The timezone call remains for compatibility reasons only; it is impossible to reliably map timezone's arguments (zone, a `minutes west of GMT' value and DST, a `daylight saving time in effect' flag) to a time zone abbreviation. 3.5.1 How do you change the timezone on NetBSD (FreeBSD also?)? Relink /etc/localtime. This will correct the difference from GMT (or its trendy equivelant) to your local timezone. In addition, the kernel needs to be modified to take the clock time in your CMOS into account. Since most folks that run DOS prefer to have their clocks set to local time, the timezone hack was introduced to allow the kernel to adjust the CMOS clock time to GMT. Once GMT has been computed, the /etc/localtime file can be referenced to determine the corrected local time. All generic kernels are built using the offset from California (why is anyone's guess:-) so just about everyone's clock will be off by their timezone offset from Berkeley. Also, it may pay to actually copy the correct timezone file rather than link it. That way, you clock will be correct even in single users mode (when the /usr partition is not even mounted. The disadvantage of this is that anytime the timezone file gets updated, you will need to make certain that the file is copied into the /etc directory. 3.5.2 The translation between seconds-since-the-epoch and date differs by about 18 seconds between BSD and other Unixes when running ntp; why? See ntp FAQ. Apparently, the time correction takes leap seconds into account twice. The timezone files in our system take the leap seconds into account in the kernel, and nntp takes the same 18 leap seconds into account when syncing the time. Because of that, the time will appear to be off by eighteen seconds. (Henning Schulzrinne) 3.6 Optional Op-codes for NetBSD, FreeBSD, and other systems. MNEMONIC INSTRUCTION ---------------------------------- AAC Alter All Commands AAR Alter At Random AB Add Backwards AFVC Add Finagle's Variable Constant AIB Attack Innocent Bystander AWTT Assemble With Tinker Toys BAC Branch to Alpha Centauri BAF Blow All Fuses BAFL Branch And Flush BBIL Branch on Blown Indicator Light BBT Branch on Binary Tree BBW Branch Both Ways BCIL Branch Creating Infinite Loop BDC Break Down and Cry BDT Burn Data Tree BEW Branch Either Way BF Belch Fire BH Branch and Hang BOB Branch On Bug BOD Beat On the Disk BOI Bite Operator Immediately BPDI Be Polite, Don't Interrupt BPO Branch on Power Off BRSS Branch on Sunspot BST Backspace and Stretch Tape BW Branch on Whim CDC Close Disk Cover CDIOOAZ Calm Down, It's Only Ones and Zeros CEMU Close Eyes and Monkey with User space CH Create Havoc CLBR Clobber Register CM Circulate Memory CML Compute Meaning of Life COLB Crash for Operators Lunch Break CPPR Crumple Printer Paper and Rip CRASH Continue Running After Stop or Halt CRB Crash and Burn CRN Convert to Roman Numerals CS Crash System CSL Curse and Swear Loudly CU Convert to Unary CVG Convert to Garbage CWOM Complement Write-Only Memory CZZC Convert Zone to Zip Code DBZ Divide By Zero DC Divide and Conquer DMNS Do what I Mean, Not what I Say DMPK Destroy Memory Protect Key DPMI Declare Programmer Mentally Incompetent DPR Destroy Program DTC Destroy This Command DTE Decrement Telephone Extension DTVFL Destroy Third Variable From Left DW Destroy World ECO Electrocute Computer Operator EFD Emulate Frisbee Using Disk Pack EIAO Execute In Any Order EIOC Execute Invalid Opcode ENF Emit Noxious Fumes EROS Erase Read-Only Storage FLI Flash Lights Impressively FSM Fold, Spindle and Mutilate GCAR Get Correct Answer Regardless GDP Grin Defiantly at Programmer GFM Go Forth and Multiply IAE Ignore All Exceptions IBP Insert Bug and Proceed ISC Insert Sarcastic Comments JTZ Jump to Twilight Zone LCC Load and Clear Core MAZ Multiply Answer by Zero MLR Move and Lose Record MWAG Make Wild-Assed Guess MWT Malfunction Without Telling OML Obey Murphy's Laws PD Play Dead PDSK Punch Disk PEHC Punch Extra Holes on Cards POCL Punch Out Console Lights POPI Punch Operator Immediately RA Randomize Answer RASC Read And Shred Card RCB Read Command Backwards RD Reverse Directions RDA Refuse to Disclose Answer RDB Run Disk Backwards RIRG Read Inter-Record Gap RLI Rotate Left Indefinitely ROC Randomize Opcodes RPB Read, Print and Blush RPM Read Programmer's Mind RSD On Read Error Self-Destruct RWCR Rewind Card Reader SAI Skip All Instructions SAS Sit and Spin SCCA Short Circuit on Correct Answer SFH Set Flags to Half mast SLP Sharpen Light Pen SPS Set Panel Switches SPSW Scramble Program Status Word SQPC Sit Quietly and Play with your Crayons SRDR Shift Right Double Ridiculous STA Store Anywhere TARC Take Arithmetic Review Course TPF Turn Power Off TPN Turn Power On UCB Uncouple CPU and Branch ULDA Unload Accumulator UP Understand Program WBT Water Binary Tree WHFO Wait Until Hell Freezes Over WI Write Illegibly WSWW Work in Strange and Wondrous Ways XSP Execute Systems Programmer ZAR Zero Any Register If you have gotten this far, you deserve some humor. -- TSgt Dave Burgess | Dave Burgess NCOIC, USSTRATCOM/J6844 | *BSD FAQ Maintainer Offutt AFB, NE | Burgess@s069.infonet.net From csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail Thu Apr 13 15:16:28 1995 Path: csus.edu!news.ucdavis.edu!agate!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!insosf1.infonet.net!s069.netins.net!cynjut.netins.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 4 of 10) Supersedes: <386bsd-faq-4-796287611@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 13 Apr 1995 01:00:23 -0500 Organization: Dave's House in Omaha Lines: 1395 Sender: burgess@cynjut.netins.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 05/01/95 01:00:08 CDT Message-ID: <386bsd-faq-4-797752808@s069.netins.net> References: <386bsd-faq-1-797752808@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.netins.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:29 comp.unix.bsd.freebsd.announce:32 comp.answers:11172 news.answers:41788 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part4 Section 3. (Kernel Building and Maintenance) 3.0 System Internals One of the interesting aspects of *BSD is the fact that it comes with the complete source. This allows you to make changes to the system, recompile, and test out your new ideas. This section of the FAQ describes many of the different aspects of this endeavor and common problems and pitfalls that are encountered. Kevin Lahey provided the substantial portion of this section. You can contact him via E-Mail at (kml@rokkaku.atl.ga.us) or contact Dave Burgess (burgess@cynjut.infonet.net). 3.1 Kernel 3.1.1 How do I build a kernel? The kernel can be compiled in a variety of ways to support different devices and configurations. Compilation is controlled by a config file that specifies the characteristics of the kernel. A set of different config files is located in /sys/i386/conf or /sys/arch/i386/conf. The configuration file names are in upper case. To build a particular kernel (in this example, we use the GENERICISA configuration file in NetBSD or FreeBSD): % cd /sys/i386/conf % config GENERICISA % cd /sys/compile/GENERICISA % make depend % make If you are using 386bsd 0.1, you'll need patch 1 from the patchkit to get the compilation to work, because the version file isn't correctly included in the Makefile. In NetBSD, since there are multiple architectures supported, there is an architecture line in the middle of the path to these files. See the build.kernel script in section 3.8 for more information. 3.1.2 I want to do one of the following things: * add a device not in the distributed kernel (third com port, additional disk or tape, line printer driver, etc). * use a patch from the net or the patchkit to fix a kernel bug. * add another swap device. * recompile the kernel to remove extraneous devices so that it takes up less space. * configure more pseudo-terminals to allow for more xterms or network logins. You're going to have to recompile the kernel after you modify the config file. See section 3.2 below for more information about the config file in general. 3.1.3 I don't have the source distribution -- how can I rebuild the kernel? There are reference sites available, as well as the 'good net-neighbor' policy, whereby you could make arrangements with a net neighbor to use a large local machine as a Network File System (NFS), or allow you to compile a new kernel on their machine and transfer it to yours. You can also ask for help from comp.os.386bsd.questions if you get stuck and cannot make any headway. 3.1.4 Now that I have a kernel, how do I install it? Your kernel is called /386bsd or /netbsd. Copy the new kernel from /sys/compile/GENERICISA/386bsd to /, assuming that it is in that directory. This is relatively straightforward; there are a couple of things to remember, though. First, if you really screw up the new kernel, you want to have something to fall back on, so be sure to save /386bsd to /386bsd.old before copying in a new kernel. Second, if you just copy the new kernel over the currently running kernel, funny things can happen. Be sure to move aside the currently running kernel before copying over the new one. There are folks that have reported that overwriting their current kernel has never caused them any real problems. On the other hand, if the old kernel was working and the new one doesn't, and you have made changes that require that old kernel, it should be available to the system, and saving it to /386bsd.alt or /386bsd.old are reasonable things to do. If you are really paranoid, you can mount a new fixit floppy and replace its kernel with the one you just built, and then boot from the fixit floppy to make sure everything will work. This is a pretty good idea if you are making radical changes or if you are unsure about your changes. 3.1.5 After installing the patchkit and recompiling the kernel with the option "WD8013", I am no longer able to reboot the machine. A cold boot (power on) runs fine, but after a reboot no boot drive is found by the BIOS. Besides having a 16-bit WD/SMC Ethernet card installed the machines try to boot using either a Adaptec 1742 or 1542 SCSI board to boot from. This answer was provided by Hellmuth Michaelis (hm@hcshh.hcs.de) and by Rodney Grimes (rgrimes@acacia). Remove "option WD8013" from the config files and recompile and reinstall the kernel. The reason that option WD8013 often causes this reboot problem is this: There is a requirement that all memory within a 128k bank in the 0xA0000 to 0xFFFFF region be either 16-bit or 8-bit. On a cold boot, the WD8013 boards are reset to 8-bit mode, the POST (Power On Self Test) passes without error. 386bsd comes up, the if_we.c driver places the WD8013 in 16-bit mode. Now on a soft boot when the BIOS runs some quick POST tests it finds a problem in the 0xA000 to 0xF000 region. You probably get a "beep-beep" when this happens. It means you have a memory size conflict. The machine has been mis-configured. This is a little known fact about 16-bit vs 8-bit option cards. It has caused more than one person to go crazy tracking down what they swear is a bug in the program. It is not, it is a flaw in the design of the ISA bus. The signal MEMCS16- must be returned the same for every 128k block of memory: A0000-BFFFF Must all be either 8-bit or 16-bit. B0000-CFFFF Must all be either 8-bit or 16-bit. D0000-FFFFF Must all be either 8-bit or 16-bit. In your particular configuration (WD8013 @ cc000) I suspect that you have another board in the B0000-CFFFFF region that is 8-bit, i.e. your Adaptec has an 8-bit BIOS on it! Try moving the board to the 0xD0000 region and see if it works there, you may still have a problem as many modern system BIOSes are now 8-bit. If your system BIOS is 8-bit, try shadowing the system BIOS region at 0xF0000 to 0xFFFFF, this effectively turns it into a 16-bit BIOS. Do not attempt to shadow the WD8013, it will cause you many headaches. In fact, it sometimes helps to turn on BIOS shadowing. Some BIOSes allow to copy ROM contents to unused RAM pages for selected 16KB-regions. While it is generally a good idea to turn BIOS shadowing off, I have also observed that sometimes it helps to turn shadowing of true ROM regions on. 3.1.6 My system is complaining about stray interrupt 7. Is my machine going to explode or anything? No. They are caused by lots of things. They are, as far as anyone that should be expected to know about this stuff, harmless. There are ramifications on them being there, but for MOST users they do not pose a real threat to your operations. For those of you that are doing REALLY interrupt intensive stuff, you may want to grab a technical reference and figure out why the 8259 is not getting reset correctly. In spite of the number of times this has come up (and people have even referenced this section) there are still at least two questions on the net about this. A memorable one was a guy who was just vehement that the stray int 7 was what was keeping his system from booting. In fact, he went so far as to say that this document was practically worthless because I didn't tell him how to fix it. Of course, once he configured his hard drive controller so that it was on the right interrupt, his booting problem went away. I have said it before and I will say it again. For MOST users they do not pose a real threat to your operations. I have heard of three people (out of at least 2000) that have actually have problems so bad that they couldn't proceed. They bought new computers, and the problem went away. These stray interrupts are caused by something in the PC. I have yet to see a convincing explanation of precisely what, but they are definitely caused by something. There are four ways to deal with this problem. 1) Ignore them. They are spurious and do not effect the operation of your computer. 2) Implement the lpt driver. This way, the driver traps (the lpt driver expects IRQ 7) and then quietly discards them. That is why when folks implement the lpt driver the 'problem' goes away. The computer is taught how to ignore them. 3) Do what the original 386bsd code did. Comment out the diagnostic and associated code that tries to deal with them so you don't see the error message. 4) Buy a new computer that doesn't cause this problem. It is a known hardware problem with the 8259 being reset incorrectly in hardware. Kalevi Suominen (jks@geom.helsinki.fi) offers this technical explanation of the 'stray interrupt 7' phenomenom. In the section of the Intel Peripheral Handbook dealing with the 8259A there is a description of the 6-step interrupt sequence for an 80x86 system (and 7-step for an MCS-80/85), and then the following paragraph: "If no interrupt request is present at step 4 of either sequence (i.e., the request was too short in duration) the 8259A will issue an interrupt level 7. Both the vectoring bytes and the CAS lines will look like an interrupt level 7 was requested." This explains how some transient disturbances or improperly functioning adapter cards could trigger a stray interrupt 7 in a system operating in the *level* interrupt mode (such as a PS/2 with MCA): An interrupt request will disappear as soon as the interrupt line goes inactive. That such interrupts may also occur in a system operating in the *edge* triggered mode (such as an ordinary PC/AT with ISA) is a little harder to see. Yet it is possible - even without malfunctioning hardware - because masking an interrupt request will hide its presence from the 8259A as well: 1. The interrupt flag (IF) of the 80x86 is reset either directly (e.g., by a "cli" instruction) or because an interrupt handler is entered. In the latter case the corresponding in-service (IS) bit of the 8259A is set (effectively blocking interrupts of lower priority). 2. The 8259A receives an unmasked interrupt request (IRQn), and, in case an interrupt is being served and has higher priority than IRQn, the IS bit of the 8259A is reset by an end of interrupt (EOI) command. (These steps may occur in either order.) If IRQn has higher priority (e.g. IRQ0), no EOI is necessary. 3. The 8259A activates the interrupt (INT) line to the 80x86 (which will ignore it - for the moment). 4. The interrupt mask (IM) bit of the 8259A for IRQn is set. (A little late, though. The sequence has already started.) 5. The interrupt flag (IF) of the 80x86 is set (either directly, or as a consequence of e.g. an "iret" instruction). 6. The 80x86 will now acknowledge the INT request by activating the INTA line of the 8259A. 7. The 8259A will not see the masked IRQn and will continue by issuing a spurious interrupt of level 7 instead. The original interrupt request (IRQn) will not be lost, however. It is preserved by the associated edge sense latch of the 8259A, and will be acted on after the IM bit has been reset again. The net result is that a single interrupt request will be delivered *twice* to the 80x86: first as a stray interrupt 7 and later as the proper interrupt. In particular, it is perfectly safe to ignore the stray interrupt (other than sending an EOI). It is just the ghost of an aborted interrupt sequence: the system was not prepared for it yet. 3.1.7 I keep getting "wd0c: extra interrupt". What does it mean? It means that the drive was already processing a command (active) when it recieved an interrupt from the system telling it to see if it had anything to do. This is mostly harmless but could indicate that the drive/controller is having problems if the message appears often. 3.1.8 I found a bug in the kernel. How do I report it? Both NetBSD and FreeBSD include a facility called 'bugfiler'. While the instructions are included in both system, there is still some apparent confusion about when to use (and when to NOT use) bugfiler. Jordan K. Hubbard (jkh@whisker.lotus.ie) provides us with this short article for FreeBSD. To send bug reports, you want to use the sendbug(1) command. The entire package for sending and filing these bugs is known as "the bugfiler", which is where the confusion stepped in, but sendbug is definately the command you want to use. Second, it doesn't take a "net connection" to use sendbug, since all it does is package up your "bug report form" and mail it to us; no direct internet connectivity is required, just mail. So if you can send internet mail you can use sendbug, or you can also send mail to the `FreeBSD-bugs@freefall.cdrom.com' address (do NOT send it to FreeBSD.cdrom.com since it will BOUNCE, this is not the place to send bugs to, just to ftp stuff from!). NetBSD has a similar facility, but has a different program and host for bug reports. The program for NetBSD is called send-pr and is slightly different in several respects. It is recommended that NetBSD users see the man page on send-pr before filing bug reports. 3.1.9 Can someone please give a reasonably clear set of instructions as to how to get a "current" version of NetBSD running? Marc Wandschneider provided this description of what he did to upgrade to the (then) current version of NetBSD: 1. Delete the old source tree, saving what I wanted to (a bunch of files moved around, and just unpacking the new one over the old will cause some problems) 2. Unpacked the new source tree. 3. ran the following sequence of commands: cd /usr/src/share/mk; make install cd /usr/src/include; make && make install setenv LDSTATIC -static setenv NOPIC cd /usr/src/lib/libc; make && make install cd /usr/src/gnu/lib/libmalloc; make && make install cd /usr/src/gnu/usr.bin/gas; make && make install cd /usr/src/gnu/usr.bin/ld; make && make install # You'll probably get some barfage from the above because # ld.so won't build yet. Ignore it and install ld anyway. cd /usr/src/gnu/usr.bin/gcc; make && make install unsetenv NOPIC LDSTATIC cd /usr/src/lib ; make && make install cd /usr/src/gnu/lib ; make && make install cd /usr/src/gnu/usr.bin/ld; make && make install cd /usr/src; make && make install At some point during the installation, your system will be fixed enough that many of these steps will no longer be required. For example, the new 'make' defines the variables OBJDIR and MACHINE_ARCH for you, so you will not need those once you get to that point. Until then, the following procedure may suit your needs better. #! /bin/csh unsetenv NOPIC LDSTATIC setenv MACHINE_ARCH i386 # Pick one of these three setenv lines. # setenv MAKE "make clean " # setenv MAKE "make obj " setenv MAKE cd /usr/src/share/mk make install cd /usr/src/include $MAKE make && make install setenv LDSTATIC -static setenv NOPIC cd /usr/src/usr.bin/make $MAKE make && make install cd /usr/src/usr.bin/rpcgen $MAKE make && make install cd /usr/src/lib/libc $MAKE make && make install cd /usr/src/gnu/lib/libmalloc $MAKE make && make install cd /usr/src/gnu/usr.bin/gas $MAKE make && make install cd /usr/src/gnu/usr.bin/ld $MAKE make && make install cd /usr/src/gnu/usr.bin/gcc2 $MAKE make && make install # unsetenv NOPIC LDSTATIC cd /usr/src/lib $MAKE make && make install cd /usr/src/gnu/lib $MAKE make && make install cd /usr/src/gnu/usr.bin/ld $MAKE make && make install cd /usr/src make && make install NOTE: At some point, you might very well come across an unresolved external __DYNAMIC in crt0.o. If this happens, edit the makefile for crt0.o (lib/csu/i386) and remove the -DDYNAMIC flag) make && make install. Then put the flag back in the makefile (but don't rebuild it until the natural order of things dicates that it happen) And Theo Deraadt provides this guidance when you get an error like "init_main.o: Undefined symbol _pdevinit referenced from text segment." You need to (1) install new config (2) make clean (3) re-config your kernel then this goes away 3.2 What exactly is this config file, anyway? What are all of these cryptic notations? I've annotated the distributed 386bsd GENERICISA file; my comments are delineated by the '--' symbols. THIS IS NOT A COOK-BOOK. YOU WILL NEED TO DO THE RESEARCH (LIKE LOOKING AT THE 20 OTHER CONFIG FILES) TO SEE WHAT IS CURRENT AND WHAT YOU WILL NEED IN YOUR CONFIG FILE. # # GENERICISA -- Generic ISA machine -- distribution floppy # -- BSD can be compiled for different hardware platforms, so it is important to -- define the hardware types. 386bsd can only be built for 386 or -- compatible machines, so this is sort of superfluous, but maintains -- compatibility with standard BSD config files. machine "i386" cpu "i386" -- The ident describes the machine for which this kernel is to be built. -- It is usually the system name -- "ROKKAKU", "REF", or whatever. -- This can be used for conditional compilation, so that kernel changes -- can be compiled in only for one machine. ident GENERICISA -- This should indicate the timezone of the system relative the -- Greenwich. 8 is PST; 4 is EST. A fuller explanation is provided -- below. timezone 8 dst 7 -- maxusers isn't strictly checked; it is just used to size several -- system data parameters. maxusers 10 -- The options control the conditional compilation of features into the -- kernel. The options can be listed all on a line separated by commas. -- They are #define'ed when the kernel is compiled, so that #ifdef's -- will work. An option can be given a value by appending an equals sign -- and a value (enclosed in double quotes) to the option name. -- Hopefully the names are at least somewhat self-explanatory. To -- discover what everything does, you'd have to go through the kernel -- looking for all of the appropriate #ifdef's. -- [Perhaps somebody else could list the *exact* meanings of these -- options and some of the other possible options?] options INET,ISOFS,NFS options "COMPAT_43" options "TCP_COMPAT_42" -- The config line controls the location of the root, swap, and dump -- devices. Anything not specified is defaulted. This is where you add -- support for multiple swap devices. Just list 'em, separated by 'and'. -- The config line below identifies the root drive as wd0 and the -- swap drives as wd0 and as0. See the section on swap devices in FAQ_02 -- for additional information. config "386bsd" root on wd0 swap on wd0 and as0 -- A 'controller' is a device or bus controller. 'isa' is obviously for -- the ISA bus. 'wd0' is for regular disk controllers, 'fd0' is for the -- floppies, and 'as0' is for SCSI disk controllers. controller isa0 -- The fields work as follows: -- a. What do you call this device? -- b. What controller is this on? As you can see, the disk controller -- talks to the ISA bus, and the disks talk to the disk controller. -- c. Where are the registers for the controller mapped into memory? -- This is #defined in /sys/i386/isa/isa.h. -- d. What IRQ is this device set up for? -- e. What routine should be called on an interrupt from the device? -- a b c d e -- vvv vvv vvvvvvv vv vvvvvv controller wd0 at isa? port "IO_WD1" bio irq 14 vector wdintr -- You need a 'disk' entry for every disk on the controller. In the -- config file originally shipped with 386bsd, both hard disks were -- incorrectly identified as wd0. Be sure to change the second occurrence -- to wd1, as I have done in below. disk wd0 at wd0 drive 0 disk wd1 at wd0 drive 1 controller fd0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fd0 drive 0 disk fd1 at fd0 drive 1 -- The 'drq' specifies the channel used for bus-mastering DMA. controller as0 at isa? port 0x330 bio irq 11 drq 5 vector asintr disk as0 at as0 drive 0 disk as1 at as0 drive 1 -- Define other physical devices. pc0 is the keyboard, npx0 drives the -- math coprocessor, and com* controls the com ports. device pc0 at isa? port "IO_KBD" tty irq 1 vector pcrint device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device com1 at isa? port "IO_COM1" tty irq 4 vector comintr device com2 at isa? port "IO_COM2" tty irq 3 vector comintr -- Ethernet drivers of various sorts and the particular configuration -- information they require. For most installations, only one of these -- devices would normally be defined. device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr device ne0 at isa? port 0x300 net irq 2 vector neintr device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr device is0 at isa? port 0x280 net irq 10 drq 7 vector isintr -- Tape driver device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr -- The TCP/IP loop-back device, ethernet interface, slip interface, log -- device, and pseudo-terminals. pseudo-device loop pseudo-device ether pseudo-device sl 2 pseudo-device log pseudo-device pty 4 -- Devices required by VM. pseudo-device swappager pseudo-device vnodepager pseudo-device devpager Normally, there is an annotated configuration file called ALL which gives a list of all of the options for the configuration file. The configuration file that was used to create the list above was for a 386BSD system. Many things have changed in the config files for NetBSD and FreeBSD. As an example, the psuedo-devices swappager, vnodepager, and devpager are now full fledged devices. Like it said up at the top, use the config files that come with your system as a basis for your own experiments in kernel building. 3.2.1 Okay, fine. Why shouldn't I just add every device I can find to the kernel, so I'll never have to recompile this again? Because it takes up space. The kernel is wired into memory, so every byte it uses comes out of the pool of memory for everything else. It can't page out sections that aren't in use. If your kernel is larger than 640K, then it can't be loaded. You'll need to use Julian Elischer's bootblocks to put it in high memory, which seem to be fairly complex. Installing them (once they are compiled) is as easy as using disklabel. Newer versions of the *BSD kith provide the capability to build a kernel that is larger than 640K. Complete instructions are provided in the appropriate systems. 3.2.2 What should I remove from the kernel? What do you need? If you only have an SCSI controller, you don't need the wd0 device; if you have another kind of disk controller, you don't need as0. Unless you actually HAVE more than one Ethernet controller, you should comment out all but one of them. If you don't have an ethernet controller, you don't need any of the controllers or NFS compiled in. Without a CD-ROM, ISOFS is kind of pointless. Just look at what you have and think about what you really need. 3.2.3 I can't get enough remote login sessions or xterm sessions. I also can only get four sessions working at a time. What can I do? Increase the count of pseudo-terminals -- pseudo-device pty 12 # or whatever Every pseudo terminal should have a /dev/pty* entry. If you have 12 pseudo terminals, you should also have at least 12 pty devices in the /dev directory. The MAKEDEV script in /dev will create as many pseudo- terminals as you tell it to. 3.2.4 How do I get ddb, the kernel debugger, compiled into the kernel and running? If you are using older versions of the 386BSD family, you will need to add a line in your config file that looks like this: device-pseudo ddb If you are using a more recent version (the division is pretty unclear about when the switch was made) and do not have any device-pseudo entries, you will need to add the line: options DDB to your config file. Build the kernel, then run dbsym on it: % dbsym ./386bsd Install it and go for it. Ctl-Alt-Esc drops you into the debugger. Note: DDB as shipped originally is a memory hog, and it is very difficult to get a kernel small enough with enough fun things in it to debug in 640K On the NetBSD-sparc system, the L1-A is used by the the DDB routines to drop you into the debugger. 3.2.5 Can I patch the current running OS image? In general, I think, the answer is no. The prevailing philosophy seems to be that one should use sysctl for such things, but that requires that one has already compiled in the ability to change the specific variable in question. (I discovered this when I wanted to patch tickadj at runtime; I added it to kernfs, and when I offered the patches (which are quite small) I was told sysctl was the `correct' way. What's incorrect about /kern was never quite explained; the closest anyone came was to invoke internationalization concerns. Of course, using /kern also requires having compiled in support for tweaking the variable you want to change.) Besides, unless you've patched securelevel, I don't think there is any good way to twiddle variables in the running kernel. /dev/{,k}mem are, I believe, read-only once init sets securelevel to 1. Der Mouse (mouse@collatz.mcrcim.mcgill.edu) 3.2.6 Can I have more than one config file? Should I rename it to something else? Any other hints? You can create as many (or as few) config files as you desire. The system, once the patchkit is applied, will have between 10 and 15, each of which implements certain functions or features. In addition, the normal place for the patchkit to make changes to the config files is in the GENERICISA file. Since this file should remain unchanged and available, it is always a good idea to copy this file to a meaningful name and modify that file. In other words, change every reference in 3.1.1 from GENERICISA to HAL (or whatever you call your system). One final note. Every /sys/compile directory takes up 800K or so; you might want to watch to see how big these all get. 3.2.7 What is the meaning of the trap codes I get in panic messages? Sometimes this message appears in the form "trap type nn". That message means that the system received an unexpected (and unwanted) trap that probably indicates some form of kernel bug. These traps, are usually received from the kernel, in which case the trap.h definitions should be used. The number (which appears in place of "nn" above) is *NOT* the i386 or i386 trap type, it is a BSD-defined trap type number. The definitions of the various trap types can be found in /usr/include/machine/trap.h. two of the more common ones are: 9 T_PROTFLT protection fault (The kernel tried executing code which was not noted as "executable". This happens if the kernel jumps to a bogus location.) 12 T_PAGEFLT page fault (The kernel tried to access a bogus area of memory. This can happen if an invalid pointer is dereferenced.) This is a list of i386 trap codes (just to confuse the issue). Trap 0 Divide Error The DIV or IDIV instruction is executed with a zero denominator or the quotient is too large for the destination operand. Trap 1 Debug Exceptions Used in conjunction with DR6 and DR7, The following flags need to be tested to determine what caused the trap: BS=1 Single-step trap B0=1 AND (GE0=1 or LE0=1) Breakpoint, DR0, LEN0, R/W0 B1=1 AND (GE1=1 or LE1=1) Breakpoint, DR1, LEN1, R/W1 B2=1 AND (GE2=1 or LE2=1) Breakpoint, DR2, LEN2, R/W2 B3=1 AND (GE3=1 or LE3=1) Breakpoint, DR3, LEN3, R/W3 BD=1 Debug registers not available, in use by ICE-386 BT=1 Task Switch Trap 2 NMI Interrupt On PC/AT systems, the NMI input to the CPU is usually connected to the main memory parity circuit. By the time the error signal is generated, the data may have already been used in an instruction, so it isn't possible to reliably recover. And some not-so-common causes (from various sources): PS50+ : I/O channel check, system watch-dog timer time-out interrupt, DMA timer time-out interrupt parity errors on any 8-bit or 16-bit board pulling the IOCHCK* line low first generation of auto-switching EGA cards used NMI to trap port access for CGA emulation (e.g., ATI's EGA Wonder) Zeos Notebook low battery (perhaps other battery-based computers) Trap 3 Breakpoint The result of executing an INT 3 instruction. MS-DOS and Windows and some other non-386 systems use this for debugging. Code specific to the 386 and later processors should use the debugging features tied to Trap 1. Trap 4 INT0 Detected Overflow Occurs if an INT0 instruction is executed and the overflow flag (OF) is currently set. Trap 5 BOUND Range Exceeded Occurs if the BOUND instruction is executed and the array index points beyond the area of memory containing the array being tested. Trap 6 Invalid Opcode The value read at CS:IP is not a valid opcode. Trap 7 Coprocessor Not Available This occurs if the processor fetches an instruction that is for the coprocessor and no coprocessor is present. Trap 8 Double Exception (Fault) An exception occurred while trying to execute the handler for a prior exception. Example, an application causes a General Protection Fault (13) and the area of memory where the GPF handler should be is flagged not-present (paged-out?). The double-fault handler is invoked in these conditions. If a fault occurs while trying to run the double-fault handler, a triple-fault occurs and the CPU resets. The rules for deciding if a double-fault should occur or if the two faults can be handled serially are discussed in more detail in the Intel song book. Trap 9 Coprocessor Segment Overrun A page or segment violation occurred while transferring the middle part of a coprocessor operand to the NPX. Trap 10 Invalid Task State Segment During a task switch, the new TSS was invalid. Here is a table of conditions that Invalidate the TSS: TSS id + EXT The limit in the TSS descriptor is < 103 LTD id + EXT Invalid LDT selector or LDT not present SS id + EXT Stack segment selector is outside table limit SS id + EXT Stack segment is not a writable segment SS id + EXT Stack segment DPL does not match new CPL SS id + EXT Stack segment selector RPL <> CPL CS id + EXT Code segment is outside table limit CS id + EXT Code segment selector does not refer to code segment CS id + EXT DPL of non-conforming code segment <> new CPL CS id + EXT CPL of conforming code segment > new CPL DS/ES/FS/GS id + EXT DS, ES, FS or GS segment selector is outside table limits DS/ES/FS/FS id + EXT DS, ES, FS, or GS is not readable segment Trap 11 Segment Not Present Occurs when the "present" bit of a descriptor is zero. This can occur while loading any of these segment registers CS, DS, ES, FS, or GS. Loading SS causes a Stack fault. Also occurs when attempting to use a gate descriptor that is marked "not present", and if attempting to load the LDT with an LLDT instruction. Note that loading the LDT during a task switch causes an "invalid TSS" trap. Trap 12 Stack Fault A limit violation relating to an address referenced off the SS register. Includes POP, PUSH, ENTER and LEAVE opcodes, as well as references such as MOV AX,[BP+8] (which has an implied SS:). Also causes by loading SS with a descriptor that is marked "not present". Trap 13 General Protection Fault (GPF) Americas Favorite, in the Windows 3.0 world, it is known as the UAE error. The instruction tried to access data out of the bounds designated by the descriptors. The access that failed can be a read, write or instruction fetch. There are 15 classifications of GPFs: 1. Exceeding segment limit when using CS, DE, ES, FS or GS. 2. Exceeding segment limit when referencing a descriptor table. 3. Transferring control to a segment that is not executable. 4. Writing into a read-only data segment or into a code segment. 5. Reading from an execute-only segment. 6. Loading the SS register with a read-only descriptor (unless the selector comes from the TSS during a task switch, in which case a TSS exception occurs.) 7. Loading SS, DS, ES, FS or GS with the descriptor of a system segment. 8. Loading, DS, ES, FS or GS with the descriptor of an executable segment that is not also readable. 9. Loading SS with the descriptor of an executable segment. 10. Accessing memory via, DS, ES, FS or GS when the segment register contains a null selector. 11. Switching to a busy task. 12. Violating privilege rules. 13. Loading CR0 with a PG=1 and PE=0. 14. Interrupt or exception via trap or interrupt gate from V86 mode to privilege level other than zero. 15. Exceeding the instruction limit of 15 bytes (this can only occur if redundant prefixes are placed before an instruction). To determine which condition caused the trap, you need the instruction, the contents of all associated registers, particularly the segment registers involved, then the various LDT, GDT and page control tables. Lots of common coding errors cause the GPFs. Even a stack imbalance will usually show up as a GPF. Even MOV AX,7 MOV ES,AX or MOV AX,5 PUSH AX POP DS will get a GPF error. You can't use a segment register for "temporary storage" of any old value the way you could on the 8086. The values loaded into the segment registers are checked in protected mode. Trap 14 Page Fault The page directory or page table entry needed for the address translation has a zero in the present bit, or the current procedure does not have sufficient privilege to access the indicated page. Trap 15 (reserved) Trap 16 Coprocessor Error The coprocessor asserted the ERROR# input pin on the 386 (internal on the 486) Trap 17 Alignment Check (486 and later) If enabled, this trap will occur if a data fetch does not occur on a word boundary. I don't know of any software that activates this feature yet. I have seen SCO UNIX get this error on early Cyrix processors, even though SCO had not enabled the feature. Trap 18-32 (reserved) [answered by Frank Durda IV and jim mullens jcm@ornl.gov -or- mullens@jamsun.ic.ornl.gov] ------------------------------------------------------------------------------- 3.2.8 I have been getting a lot of "virtual memory exhausted" errors when I am compiling a program with a really big static array. I have 128Meg of memory and 8Gig of swap. How can this be happening? If you are using Csh, you can simply unlimit your processes in your system level /etc/csh.cshrc file or your personal .cshrc file. You can also modify your kernel so that the amount of memory available is less limiting. J"org Wunsch (j@tcd-dresden.de) provides us with this brief description: From a recent posting i just made, regarding the problem how much virtual memory one could get. | On the other hand, i've also changed the definitions you | mentioned. But i didn't like to modify the header files, and | actually, modifying the values is as easy as: | | options "DFLDSIZ='(16 * 1024 * 1024)'" | options "MAXDSIZ='(64 * 1024 * 1024)'" | | Include the above lines into your kernel's config file, reconfig | and rebuild it. | This is just a hint for those people poking around with compiling large source files. Especially, due to some gcc problems with large static arrays, compiling X applications with huge bitmaps would cause virtual memory trouble. Increasing the limits (o'course, as long as the h/w resources suffice) could help there. The default definitions for the above parameters are found in /usr/include/machine/vmparam.h. 3.2.9 Where can I learn more about all this? We've skipped over a lot of details here; the straight dope comes from "Building Berkeley UNIX Kernels with Config", by Samuel J. Leffler and Michael J. Karels. 3.2.10 Does anyone have a system building script that takes things like building a new config and multiple config files into account? This is the program that I use to rebuild my kernel. See the note in the file about my 'test' program. You may elect to build a new config every time, or not, depending on your requirements. #! /bin/sh # # Script to rebuild the kernel. # if [ `whoami` != 'root' ] ; then echo 'You must be root to successfully proceed from this point' exit 1 fi # # Set up the environment # if [ X$MACHINE_ARCH = "X" ] ; then MACHINE_ARCH=i386 fi if [ -f /netbsd ] ; then ARCHDIR='/arch' fi # # Rebuild Config # # I am using a modified test(1) that allows for file date comparisons. # You can either get my patches (if they aren't already included), # modify test() yourself, or get the GNU ShellUtils test(1) program. # if [ /usr/src/usr.sbin/config -ot /usr/sbin/config ] ; then echo "Config Up To Date" else cd /usr/src/usr.sbin/config make clean make depend make make install fi cd /sys make make install # # Modify the local Configuration File # echo `tput clr` cd /sys$ARCHDIR/i386/conf if [ "X$CONFIG_NAME" = "X" ]; then CONFIG_NAME=GENERIC fi if [ "X$1" = "X" ]; then echo "Configuration Files available:" ls [A-Z]* echo " " echo -n "Enter the name of the config file to use: " read CONFIG_NAME echo else CONFIG_NAME=$1 fi if [ ! -f $CONFIG_NAME ]; then cp GENERIC $CONFIG_NAME fi echo "Modifying $CONFIG_NAME config file" echo -n "Press return to continue (q to quit) " read ans ans=`echo $ans | cut -c1 | tr 'QqYy' 'qqqq'` if [ "X$ans" = "Xq" ] ; then exit 0 fi vi $CONFIG_NAME #config.new $CONFIG_NAME config $CONFIG_NAME COMPILE_DIR=/sys$ARCHDIR/i386/compile/$CONFIG_NAME cd $COMPILE_DIR make depend make if [ $? -ge 1 ] ; then echo "Errors encountered" else if [ -f netbsd ] ; then PROGNAME=netbsd else if [ -f freebsd ] ; then PROGNAME=freebsd else PROGNAME=386bsd fi fi echo `tput clr` echo "" echo " Manual Installation is recommended. The following files should be" echo "copied/linked/moved to the root directory. The following steps are" echo "suggested:" echo "" echo " mv /$PROGNAME /$PROGNAME.old" echo " mv $COMPILE_DIR/$PROGNAME /$PROGNAME" echo " reboot" echo "" echo "Remember that the new kernel changes will not take place until you " echo "re-boot the system." fi 3.3 X11/XFree86/XS3 3.3.1 What options should I define to get the X extensions included? Once you have applied the patch kit, the only thing left to do is to modify the config file to include the following line: options XSERVER, UCONSOLE recompile the kernel and the kernel should support X. 3.3.2 Where can I get the FAQ for 'X'? Steve Kotsopoulos' general 'X on Intel-based Unix' FAQ available by anonymous ftp from export.lcs.mit.edu in /contrib/Intel-Unix-X-faq. 3.3.3 Why does X drop characters when using xdm? When I run xdm from the console, it keeps losing keystrokes and the shift keys don't always work. Why? You need to run xdm with the -nodaemon flag. The reason is xdm normally detaches from the keyboard. This allows other processes (like getty) to return to reading from the keyboard. A race condition results, where some keystrokes are sent to xdm and others are sent to other processes. Using the -nodaemon flag causes xdm to stay attached to the keyboard so no other process can use it. This answer comes from Michael C. Newell (root@wanderer.nsi.nasa.gov) This bit of trivia is also covered in detail in the X FAQ and the README that accompanies XFree86. 3.4 Compiler and Library routines There are several questions that could probably be included here. See also Section 4 for some of the more common 'missing modules' that also happen to be library routines. 3.4.1 Which C compiler is shipped with my 386BSD derived system? The standard compiler released with 386bsd 0.1 is GCC 1.38. This version is considered by many people to be the most stable of the GCC versions. All other Net/2 derived BSD systems have both 1.38 and 2.4+ available. NetBSD 0.9, for example, is completely compilable using GCC 2.4.5, which is included as the default compiler. FreeBSD also ships with the same compiler. 3.4.2 Where is libcompat.a? The library libcompat.a is (working from memory here) completely deprecated in 386bsd. The only exceptions might be the re_comp and re_exec routines, which are discussed in detail in section 4. In addition, things will be added to libcompat.a as they are deprecated in the newer versions of NetBSD and FreeBSD. The getreuid() and setreuid() stuff may be heading that way (if they aren't there already. The easiest way around not having a libcompat.a is to simply link it to a small library, since virtually every other function that is expected in libcompat.a is already include libc.a. 3.5 You promised to talk about timezones below. Are you going to? >I've seen lots of stuff about timezone's being a bit dodgy, >especially with most European timezones changing over to DST on >the 27th March. I must say that that was NOT the case for me - >pumpy (the author's system) is running off the >/usr/share/zoneinfo/GB-Eire timezone file, (symbolically) linked >to /etc/localtime, the CMOS clock is running off GMT, and the >kernel is compiled with "timezone 0". I use /usr/share/zoneinfo/MET as /etc/localtime and have the kernel configured as timezone -1 dst 4 (My wife is running DOS on this machine for doom sometimes ;-) I set this strange dst value after diging in some old ultrix(?) man pages. There were several dst-changing-method listed and 4 was the code for the central europe one. This gave me an idea... I use an Ultrix box every day, so why not... Now, I don't know how closely this applies to NetBSD since Ultrix is based on a much older version of BSD, and this isn't for the kernel config, but for an envar of timezone values, but it's at least somewhat enlightening on possible meanings for these things. Could someone in the know shed light on how accurately this models the timezone stuff in the kernel config? When I did "man timezone" this is what I got (portion of this quoted from the DEC MIPS Ultrix 4.3a timezone(3) manpage, slightly hacked by me (Michael L. VanLoon (michaelv@iastate.edu)) STD offset [DST [offset][,start[/time],end[/time]]] the components of the string have the following meaning: STD and DST Three or more characters that are the designation for the standard (STD) or summer (DST) time zone. Only STD is required; if DST is missing, then summer time does not apply in this locale. Upper- and lowercase letters are explicitly allowed. Any characters except a leading colon (:), digits, comma (,), minus (-), plus (+), and ASCII NUL are allowed. offset Indicates the value to be added to the local time to arrive at Coordinated Universal Time. The offset has the form: hh[:mm[:ss]] The minutes (mm) and seconds (ss) are optional. The hour (hh) is required and may be a single digit. The offset following STD is required. If no offset follows DST, summer time is assumed to be one hour ahead of standard time. One or more digits may be used; the value is always interpreted as a decimal number. The hour must be between 0 and 24, and the minutes (and seconds) - if present - between zero and 59. If preceded by a "-", the time zone is east of the Prime Meridian; otherwise it is west (which may be indicated by an optional preceding "+"). start and end Indicates when to change to and back from summer time. Start describes the date when the change from standard to summer time occurs and end describes the date when the change back happens. The format of start and end must be one of the following: Jn The Julian day n (1 < n < 365). Leap days are not counted. That is, in all years, including leap years, February 28 is day 59 and March 1 is day 60. It is impossible to explicitly refer to the occasional February 29. n The zero-based Julian day (0 < n < 365). Leap days are counted, and it is possible to refer to February 29. Mm.n.d The nth d day of month m (1 < n < 5, 0 < d < 6, 1 < m < 12). When n is 5 it refers to the last d day of month m. Day 0 is Sunday. time The time field describes the time when, in current time, the change to or from summer time occurs. Time has the same format as offset except that no leading sign (a minus (-) or a plus (+) sign) is allowed. The default, if time is not given, is 02:00:00. As an example of the previous format, if the TZ environment variable had the value EST5EDT4,M4.1.0,M10.5.0 it would describe the rule, which went into effect in 1987, for the Eastern time zone in the USA. Specifically, EST would be the designation for standard time, which is 5 hours behind GMT. EDT would be the designation for DST, which is 4 hours behind GMT. DST starts on the first Sunday in April and ends on the last Sunday in October. In both cases, since the time was not specified, the change to and from DST would occur at the default time of 2:00 AM. The timezone call remains for compatibility reasons only; it is impossible to reliably map timezone's arguments (zone, a `minutes west of GMT' value and DST, a `daylight saving time in effect' flag) to a time zone abbreviation. 3.5.1 How do you change the timezone on NetBSD (FreeBSD also?)? Relink /etc/localtime. This will correct the difference from GMT (or its trendy equivelant) to your local timezone. In addition, the kernel needs to be modified to take the clock time in your CMOS into account. Since most folks that run DOS prefer to have their clocks set to local time, the timezone hack was introduced to allow the kernel to adjust the CMOS clock time to GMT. Once GMT has been computed, the /etc/localtime file can be referenced to determine the corrected local time. All generic kernels are built using the offset from California (why is anyone's guess:-) so just about everyone's clock will be off by their timezone offset from Berkeley. Also, it may pay to actually copy the correct timezone file rather than link it. That way, you clock will be correct even in single users mode (when the /usr partition is not even mounted. The disadvantage of this is that anytime the timezone file gets updated, you will need to make certain that the file is copied into the /etc directory. 3.5.2 The translation between seconds-since-the-epoch and date differs by about 18 seconds between BSD and other Unixes when running ntp; why? See ntp FAQ. Apparently, the time correction takes leap seconds into account twice. The timezone files in our system take the leap seconds into account in the kernel, and nntp takes the same 18 leap seconds into account when syncing the time. Because of that, the time will appear to be off by eighteen seconds. (Henning Schulzrinne) 3.6 Optional Op-codes for NetBSD, FreeBSD, and other systems. MNEMONIC INSTRUCTION ---------------------------------- AAC Alter All Commands AAR Alter At Random AB Add Backwards AFVC Add Finagle's Variable Constant AIB Attack Innocent Bystander AWTT Assemble With Tinker Toys BAC Branch to Alpha Centauri BAF Blow All Fuses BAFL Branch And Flush BBIL Branch on Blown Indicator Light BBT Branch on Binary Tree BBW Branch Both Ways BCIL Branch Creating Infinite Loop BDC Break Down and Cry BDT Burn Data Tree BEW Branch Either Way BF Belch Fire BH Branch and Hang BOB Branch On Bug BOD Beat On the Disk BOI Bite Operator Immediately BPDI Be Polite, Don't Interrupt BPO Branch on Power Off BRSS Branch on Sunspot BST Backspace and Stretch Tape BW Branch on Whim CDC Close Disk Cover CDIOOAZ Calm Down, It's Only Ones and Zeros CEMU Close Eyes and Monkey with User space CH Create Havoc CLBR Clobber Register CM Circulate Memory CML Compute Meaning of Life COLB Crash for Operators Lunch Break CPPR Crumple Printer Paper and Rip CRASH Continue Running After Stop or Halt CRB Crash and Burn CRN Convert to Roman Numerals CS Crash System CSL Curse and Swear Loudly CU Convert to Unary CVG Convert to Garbage CWOM Complement Write-Only Memory CZZC Convert Zone to Zip Code DBZ Divide By Zero DC Divide and Conquer DMNS Do what I Mean, Not what I Say DMPK Destroy Memory Protect Key DPMI Declare Programmer Mentally Incompetent DPR Destroy Program DTC Destroy This Command DTE Decrement Telephone Extension DTVFL Destroy Third Variable From Left DW Destroy World ECO Electrocute Computer Operator EFD Emulate Frisbee Using Disk Pack EIAO Execute In Any Order EIOC Execute Invalid Opcode ENF Emit Noxious Fumes EROS Erase Read-Only Storage FLI Flash Lights Impressively FSM Fold, Spindle and Mutilate GCAR Get Correct Answer Regardless GDP Grin Defiantly at Programmer GFM Go Forth and Multiply IAE Ignore All Exceptions IBP Insert Bug and Proceed ISC Insert Sarcastic Comments JTZ Jump to Twilight Zone LCC Load and Clear Core MAZ Multiply Answer by Zero MLR Move and Lose Record MWAG Make Wild-Assed Guess MWT Malfunction Without Telling OML Obey Murphy's Laws PD Play Dead PDSK Punch Disk PEHC Punch Extra Holes on Cards POCL Punch Out Console Lights POPI Punch Operator Immediately RA Randomize Answer RASC Read And Shred Card RCB Read Command Backwards RD Reverse Directions RDA Refuse to Disclose Answer RDB Run Disk Backwards RIRG Read Inter-Record Gap RLI Rotate Left Indefinitely ROC Randomize Opcodes RPB Read, Print and Blush RPM Read Programmer's Mind RSD On Read Error Self-Destruct RWCR Rewind Card Reader SAI Skip All Instructions SAS Sit and Spin SCCA Short Circuit on Correct Answer SFH Set Flags to Half mast SLP Sharpen Light Pen SPS Set Panel Switches SPSW Scramble Program Status Word SQPC Sit Quietly and Play with your Crayons SRDR Shift Right Double Ridiculous STA Store Anywhere TARC Take Arithmetic Review Course TPF Turn Power Off TPN Turn Power On UCB Uncouple CPU and Branch ULDA Unload Accumulator UP Understand Program WBT Water Binary Tree WHFO Wait Until Hell Freezes Over WI Write Illegibly WSWW Work in Strange and Wondrous Ways XSP Execute Systems Programmer ZAR Zero Any Register If you have gotten this far, you deserve some humor. -- Dave Burgess (The man of a thousand E-Mail addresses) 386bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom "Just because something is stupid doesn't mean that there isn't someone that wants to do it...." From csus.edu!news.ucdavis.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail Thu Apr 13 15:16:29 1995 Path: csus.edu!news.ucdavis.edu!library.ucla.edu!agate!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail From: burgess@s069.netins.net (Dave Burgess) Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 5 of 10) Supersedes: <386bsd-faq-5-795078010@s069.netins.net> Followup-To: comp.unix.bsd.misc Date: 27 Mar 1995 01:00:30 -0600 Organization: Dave's House in Omaha Lines: 837 Sender: burgess@cynjut.infonet.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 04/14/95 02:00:10 CDT Message-ID: <386bsd-faq-5-796287611@s069.netins.net> References: <386bsd-faq-1-796287611@s069.netins.net> Reply-To: burgess@s069.netins.net (386bsd FAQ Maintainer) NNTP-Posting-Host: cynjut.infonet.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux X-Posting-Frequency: Posted on/about the 13th and the 27th of every month. Xref: csus.edu comp.unix.bsd.netbsd.announce:18 comp.unix.bsd.freebsd.announce:17 comp.answers:10854 news.answers:40664 Posted-By: auto-faq 3.1.1.2 Archive-name: 386bsd-faq/part5 Section 4. (System Additions) Thanks go to Marc Wandschneider (storm@cs.mcgill.ca) for putting this section of the FAQ together.. Important note: Most of these 'kernel patches' are to the original 386bsd 0.1. The really useful ones have been added to the kernel of both NetBSD and FreeBSD. 4.0 Introduction If you have written some addition to the kernel or some other part of the system, or know of one that feel should be mentioned, send mail to Dave Burgess (burgess@cynjut.infonet.net) with all the relevant information, and it will be added for the next release. 4.1 Common Kernel-related problems 4.1.1 Where are the commands "rpcinfo" and "rpcgen"? Chris Flatters (cflatter@nrao.edu) informs us in the following posting excerpt where we can find them: -------------------------------------------------------------------- The sources for the Sun OS 4.0 RPC are on titan.rice.edu (I don't have the inet number handy) in directory sun-sources. You will have to pick up all the shell archives and unpack them to get at rpcgen. -------------------------------------------------------------------- These sources are also included in NetBSD and FreeBSD as part of the normal installation. 4.1.2 Where can I get a working "netstat"? When netstat was released, it came out as a binary patch and source patch in the patchkit for 386bsd 0.1. The program has been included in both NetBSD and FreeBSD. 4.1.3 How can I fix NFS to work with my NE2000 board? Ken Raeburn (raeburn@cambridge.cygnus.com) has both identified the problem (in 386bsd 0.1) and provided us with a work around: -------------------------------------------------------------------- I reported previously that I was seeing problems reading files over NFS using the ne2000 driver; timeouts would eventually be reported, no data would be read. Listing files and directories (small ones anyways) were not a problem. After playing with etherfind and kernel printfs, I've come to this conclusion: Fragmented 8K UDP packets from the NFS server are not reaching the UDP layer in 386bsd. The Sun is sending them (according to another Sun spying on the network), but the UDP input routine is never called. I don't know if the bug here is on the 386bsd or Sun side, and won't have time to look into it in the next couple of days. In the meantime, mounting NFS file systems with "rsize=1024" does get rid of this problem. (It does nothing about TCP being slow, though.) Ken -------------------------------------------------------------------- Hopefully, the real solution (a UDP fix) will be forthcoming so that the slow TCP problem is fixed as well. See also: Section 2.6.3.3c "I am getting lousy performance out of my network card. What are some of the other possibilities?" Recent work in FreeBSD and NetBSD may have deprecated this problem. There is a new network card driver called the ed0 driver. This replaces the original NE1000/NE2000 drivers, as well as replacing the we0 driver. By combining the two, a more flexible driver has been developed and most of these types of problems have been fixed. Once again, upgrading to FreeBSD or NetBSD seems to be the answer. 4.1.4 How can I get "ps" and "w" to work? The patch-kit contains a fix for /src/lib/libutil/kvm.c, which, last we heard, was due to the work of Jim Paradis (paradis@sousa.ltn.dec.com). New versions of the kernel should have this problem fixed. In order for users to be able to use certain flags with ps and the w/uptime commands, the kernel must have permissions 755. Also, in order to save space on the distribution, the 386bsd 0.1 kernel is 'stripped' of all its labels. Programs that rely on those labels will not work. There are several in this category, including ps, w, and uptime. Either ftp an un-stripped kernel, or recompile. Also, when the internal structure of the kernel changes (as with the changes to NetBSD and FreeBSD that change fundamental parts of the kernel) a new ps, w, and uptime must usually be recompiled. If you are having trouble with your ps and have recently upgraded/rebuilt your kernel, you will probably have to rebuild ps etal. 4.1.5 Where are re_comp and re_exec? These two functions are currently not in libc.a. However, there are two related functions that seem to work exactly the same in all cases we've heard of---These are regcomp() and regexec(). Thus, a pretty ugly fix for the problem would be to always compile as follows: $(CC) -Dre_comp=regcomp -Dre_exec=regexec .... There is a slightly nicer fix available for this, listed in 4.2 4.1.6 What about the termio, termios, and termcap stuff? 4.1.6.1 Where are stty() and gtty()? These functions were missing from libc.a in the original 386bsd 0.1. To fix, add the following #defines to your program: #define stty(f, m) ioctl((f), TIOCSETP, (m)) #define gtty(f, m) ioctl((f), TIOCGETP, (m)) A more elegant solution is to apply the patchkit. These routines are included in there. 4.1.6.2 Sometimes I have trouble with my system resetting the terminal to seven bit mode. Isn't 386BSD eight bit clean? The answer is "sort of". The problem seems to come from the fact that the interface is not guaranteed to be eight bit clean. The interface is better, and should be eight bit clean in all cases. If you find an application that uses the interface, you should either contact the author and try and get them to use the termios interface or port the code yourself. 4.1.7 The system hangs with the HD light on after intense disk usage. The system hangs when trying to fsck -p both of my IDE hard drives at boot-up. Brett Lymn (blymn@mulga.awadi.com.AU) Provides us with a description of the problem and the steps that he had to take to fix it: It seems that, on some disk subsystems, the controller and the hard disk get out of synchronization when they are being used intensively. The result of this is that the disk completes a command but the controller still believes the disk not to have completed the command, so the controller status register indicates the disk is busy when it is not really. The standard wd drivers are too trusting of the hardware and expect it to do the right thing all the time. There are a few while loops in the wd drivers that loop on a status change from the disk controller, however; if the problem I have described takes place then the wd driver will be stuck looping waiting for the disk to not be busy - which never happens, so you lock the machine because this is a kernel level wait. To fix this problem I put a timeout into the while loops so that after a specified time the wd driver will give up waiting for the drive to become ready, reset the controller and retry the command. In my experience the retry always succeeds. Ed.Note: The retry doesn't ALWAYS work, but it IS better than just waiting for the drive to wake back up (which it never does). It has been recently noted that, from time to time, a SCSI disk subsystem will behave exactly the same way. It is usually because of bad/out-of-tolerance cables. It is not a common problem, but it is one that you, the reader, may need to take into account when you are trouble-shooting your drives. Dan Yergeau (yergeau@gloworm.Stanford.EDU) provides us with more insight into this problem. The README accompanying the original sources used as a base for the NetBSD driver indicates that > There's also another problem still bothering me: There's some sort of timing/reentrancy error still lurking in here, that was there in the original 0.1 wd driver as well. The symptom is that, on *some* controllers, doing the initial wdopen() (which will then call the readdisklabel() function) for two or more disks at the same time (so that wdopen() gets called again while it's already being executed), the controller gets hung. I'm still looking for this, meanwhile I specify in my config file that I have swap on all disks. This causes the kernel to wdopen() the drives nicely in order -- and once it's been done for each disk, the problem will, of course, not occur. Without the "swap on ... and ... and ..." stuff, my wd1, wd2 and wd3 would be opened simultaneously by "fsck -p" forks, which would nicely hang up everything... I note a "sleep(10)" in fsck, but it obviously doesn't do that. So, changing the appropriate config line to config "386bsd" root on wd0 swap on wd0 and wd1 ^^^^^^^ may get around the problem. I don't run NetBSD, but I do use a variation of the barsoom/NetBSD driver. This works for me. Please let the NetBSD people know if it works for you. #include [Ed. again] Other methods for fixing this problem include doing a dd if=/dev/wd1d of=/dev/null count=1 before the initial 'fsck -p'. This method is considered brute force. It works by making sure that the drive is properly initialized before the disklabel is read in the fsck. Another method involves using the '-l1' (little L) flag to make sure that the fsck doesn't try to open both unopened hard drives at the same time. This method is a little better (from a purely brute viewpoint) but does caused your startup to run longer, since the purpose of this option is to have each of your fsck passes run one after another. 4.1.8 How do you implement quotas on Net/2 derived BSD systems? From: tinguely@plains.NoDak.edu (Mark Tinguely) maybe you did not complete the setup, here is a step-by-step instructions to get them to work: 1) make a kernel with "options QUOTA" installed 2) edit /etc/fstab and include the kinds of quotas you want, below I used "userquota", you could also add "groupquota". /dev/wd0h /usr ufs rw,userquota 1 2 3) for each filesystem that is in /etc/fstab that uses quota, create the file "quota.user" (and "quota.group if appropriate). Above I have user quotas in the /usr filesystem, so I would: # touch /usr/quota.user 4) scan filesystem for files ownership (and/or group ownership). # quotacheck -a 5) now you can add individual quota limits, if you want to add the same quotas to the many people, then make a template and replicate the template. If they change for each user, then edit seperately. # edquota tinguely (an editor is kicked up and says something like: Quotas for user tinguely: /usr: blocks in use: 11876, limits (soft = 0, hard = 0) inodes in use: 891, limits (soft = 0, hard = 0) a limit of 0 means "unlimited". Change these to the appropriate number of blocks. A soft limit generates a warning, and can be exceed for period of time (7 days?), after which time a soft limit is treated like a hard limit. A hard limit denies new writes. to replicate a template (for this example let us assume "tinguely" is the template): # edquota -p tinguely user1 user2 user3 ... userN 6) turn quotas on (usually done in the /etc/rc file, but turn it on manually so you do not have to reboot right now: # quotaon that should take care of setting up quotas. You can look at the status of use of files with repquota, the -a option lists all filesystems with quotas. 4.2 Available kernel add-ons 4.2.1 The Patch-Kit Perhaps the most famous of all additions to the kernel, the Patch-Kit, coordinated by Rodney Grimes (rgrimes@agora.rain.com) contained numerous bug fixes, Julian's SCSI drivers, as well as fixes for other parts of the system. It is highly recommended that all users with space for the source code apply the patch-kits as many things that seem broken in 0.1 suddenly start working with the patch-kits. Of course, there is no such thing as a patch kit for NetBSD or FreeBSD. The update method for these systems is different, and covered in the section about the System Update Protocol (sup) updates. 4.2.2 Shared Libraries A basic and experimental implementation of shared libraries exists for 386bsd. According to the author (Dr. Joerg Lohse, lohse@tech7.informatik.uni-hamburg.de), features are as follows: -No kernel extension is necessary -Shared libraries use the approach used in SysV. Others are also working on different implementations of shared libraries. Bill and Lynne have adopted a shared-library implementation based on Dr. Lohse's original work. It will be included in Version 0.2 of 386bsd. For NetBSD and FreeBSD users, two seperate and different shared library systems have been developed. This feature is included in the '-current' tree of both systems, and will be included in the next major release of eiter or both. The shared libs have, in general, been very well behaved. The closest thing to a FAQ that has been introduced is the following: I installed FreeBSD-1.1-BETA a few weeks ago but can't get dynamically linked programs to run for some reason. Every time I try to run a dynamically linked program, I get a message that says "No ld.so"... The answer is: # chmod 755 /usr/* /usr/share/misc 4.2.3 Sound Blaster Drivers A driver for the Sound Blaster card has been written by Steve Haehnichen (steveh@ucsd.edu) for BSD. Steve Gerakines has provided us with the information necessary to get this driver working under 386bsd. Most features of the SB family of cards are supported save some stereo portions of the SBPro cards. NetBSD and FreeBSD have also adapted soundblaster drivers. They are included in either the -current tree or in the most recent release (depending on when you read this). For a fact, the following sound cards are supported in FreeBSD: 1 Yamaha FM Synth 2 Soundblaster/Soundblaster Pro DSP 3 PAS PCM and Midi 4 Gravis UltraSound 5 MPU-401 In the release notes I have, there is some doubt as to the operational status of the MPU-401 sound card driver. If you have one of these cards and want to try the driver out, you should contact Jordan Hubbard (jkh@freefall.cdrom.com) when you are finished installing it and let him know how it is working. The docs for the FreeBSD driver are in /usr/src/sys/i386/doc/sound.doc. 4.2.4 Bus Mouse Drivers Fred Cawthorne (fcawth@delphi.umd.edu) wrote a busmouse driver for 386bsd. He recently wrote a short letter with this update: This is taken from the INDEX in the Freebsd.cdrom.com mice directory: "We currently have four bus mouse drivers for 386bsd available by anonymous ftp on XFree-86.cdrom.com in pub/XFree86/mice: ms-busmouse.tar.z Sandi Donno's port of Erik Forsberg's Microsoft bus mouse driver to 386bsd. logitech-busmouse-0.2.shar.z Fred Cawthorne's second version of a logitech Bus Mouse driver. busmouse.tar.z: Eugene Stark's port of Rick Macklem's driver to the Microsoft bus mouse. Rick's driver supports the Logitech and ATI Inport Bus mice with 386bsd. It's also available by e-mail to stark@cs.sunysb.edu and by anon. ftp on cs.sunysb.edu in pub/386BSD/busmouse.tar.Z. psm.tar.z: Johan Solhed ported the Linux PS/2 mouse driver to 386BSD. It includes a PS/2 to Microsoft protocol converter in the driver so XFree86 understands the mouse events. In addition we have busmouse.v3.z which is Erik Forsberg's original post of his device driver for BSDI/386 and Microsoft (and compatible) bus mice using the Microsoft InPort chip as well as a device driver for Logitech bus mice. " Most of these busmouse drivers are now included in the current releases of NetBSD and FreeBSD. There is some question about how well they work (especially the psm driver), but they are all there. Additional information about configuring the psm device is included below to help make the psm driver work reliably. Add the following entries to your config file: options ALLOW_CONFLICT_IOADDR device psm0 at isa? port "IO_KBD" tty irq 12 vector psmintr Duplicate the options and device lines into your own kernel configuration file, making sure to obey the proviso given about following your pc0/sc0 devices, recompile it, install it, and you should be off. The the LINT configuration file for more information. 4.2.5 PPP Support PPP support is included in NetBSD and FreeBSD. With the demise of agate's support for 386BSD, there is no way to add ppp support to 386BSD. You must upgrade to wither FreeBSD or NetBSD. 4.2.6 re_comp and re_exec library functions As mentioned in section 4.1, re_comp and related functions, such as re_exec, are currently not in the library libc.a. Apart from using the rather crude fix listed above, there is another option. Kim Anderson (kim@dde.dk) has provided a patch that will add these to libc.a. You can probably obtain this patch from the author, or you can ftp it from binkley.cs.mcgill.ca in pub/386bsd. These functions are (I think) included in the libcompat.a that comes with both NetBSD and FreeBSD. 4.2.7 Intel i82586 Ethernet Controller driver Garrett A. Wollman has written a 386bsd 0.1 driver for the Intel i83586 Ethernet Controller. The author's e-mail address is listed as wollman@emba.uvm.edu. 4.2.8 PC Speaker driver for Nethack Andrew A. Chernov has ported the Nethack PC Speaker driver to 386bsd. It allows the speaker to be controlled by applications. Unfortunately, we are not aware of a site that distributes this, but this patch has been posted a couple of times to the various comp.os.386bsd groups, and the author can be contacted at ache@astral.msk.su The patch that is included in the NetBSD and FreeBSD source trees is one written by Soerne Schmitt. It appears to use the Sun-style /dev/audio interface and is different in goals and implementation from Andrew Chernov's speaker driver. The source for this package is included in the source trees for both, but is not included in the distribution kernels. 4.3 Other program building type problems. 4.3.1 Greetings from Mars. I am building a program that requires access to the crypt library. Either I have it and it isn't getting copied into the executable, or I don't have it; why? This is actually two separate questions, but they are close enough to the same that I can answer them here. The first problem that anyone building a 'crypt' aware program needs to remember is that the crypt library is a separate library and requires a '-lcrypt' to be added at the end of the link line. The other half of the problem is the 'US Non Export' policy for DES encryption. There are several good sources (about one per country) for non-US crypt libraries. IF you are outside the US and need one, look around on some of the NetBSD/FreeBSD/386BSD FTP sites in the 'local area'. 4.3.2 I am having trouble with long file names in my libraries. It seems like there is a 16 character limit in the library somewhere. There is a 16 character limit, sort of. The most likely symptom for this is that the header for the file _after_ the long file name will be mangled. It turns out that there is a "T" option that may not be documented very well that provides the correct functionality for long filename support in ar. 4.4 Where is the 'adduser' program? Here. #!/bin/sh # This is a shell archive. # remove everything above the "#!/bin/sh" line # and feed to /bin/sh # Use -c option to overwrite existing files # # Contents: # adduser.sh # # packed by: on Sun Aug 21 10:25:30 EST 1994 # PATH=/bin:/usr/bin:/usr/ucb ; export PATH if test -f adduser.sh -a x$1 != x-c ; then echo shar: Will not over-write existing file \"adduser.sh\" else echo shar: Extracting \"adduser.sh\" \(6443 characters\) sed 's/^X//' >adduser.sh << '!EOF' X: X# X# NAME: X# adduser.sh - portable add user script X# X# SYNOPSIS: X# X# adduser.sh [-G "Group"] [-H "Homes"] [-S "Shell"] [-u "uid"] \\ X# [-p "encrypted"] [-P "cleartext"] [-l] X# X# DESCRIPTION: X# Simply adds users and their home directory. It prompts for a X# "username" and "fullname" which become part of the passwd file X# entry for the new user. It adds "username" to "Group" X# (creating it if necessary) and uses "uid" or the 'gid' of X# "Group" as a starting point for its search for an unused X# 'uid'. By default it will prompt for a passwd after adding X# each user, but '-p' can be used to set a pre-encrypted password X# or '-P' can be used to give a clear text password which the X# script will encrypt and then use for each new "username". X# X# Most of the variables used are obvious. "Homes" is the parent X# directory of new users home directories. X# X# The '-l' option causes the script to show the default values X# for the variables that it uses. Most if not all can be set on X# a per machine basis by creating a file '.adduserrc' in the X# super users home directory or in the directory where X# 'adduser.sh' is found. If "Homes"/.adduserrc exists it will X# be processed after any others, so can be used to set defaults X# on a per project basis. X# X# NOTES: X# The script handles shadow password files on Solaris 2.3, other X# machines may break. It has been tested on NetBSD, SunOS, X# Solaris and HP-UX. X# X# AUTHOR: X# Simon J. Gerraty X# X X# RCSid: X# $Id: adduser.sh,v 1.2 1994/05/08 22:54:04 sjg Exp sjg $ X# X# @(#) Copyright (c) 1993 Simon J. Gerraty X# X# This file is provided in the hope that it will X# be of use. There is absolutely NO WARRANTY. X# Permission to copy, redistribute or otherwise X# use this file is hereby granted provided that X# the above copyright notice and this notice are X# left intact. X# X# Please send copies of changes and bug-fixes to: X# sjg@zen.void.oz.au X# X XMyname=`basename $0 .sh` XMydir=`dirname $0` Xcase $Mydir in X.) Mydir=`pwd`;; Xesac X XETC=/etc X# for testing only X#ETC=/tmp X#VIPW="ed $ETC/passwd" X X# thinks that the rc file may override. Xhost=`hostname 2>/dev/null` XHomes=/home/${host:-`uname -n`} XShell=/bin/csh X[ -x /bin/ksh ] && Shell=/bin/ksh XGroup=users XPasswd='**' X X# look for an rc file Xfor d in $HOME $Mydir Xdo X [ -s $d/.${Myname}rc ] && { . $d/.${Myname}rc; break; } Xdone X XEXF=/tmp/e$$ XTF=/tmp/u$$ XTF2=/tmp/uu$$ X Xcase `echo -n .` in X-n*) N=;C="\c";; X*) N=-n;C=;; Xesac X XOS=`uname -s` X Xadd_path () { [ -d