diff --git a/handbook/Makefile b/handbook/Makefile index ef951720a0..6dfc9829b4 100644 --- a/handbook/Makefile +++ b/handbook/Makefile @@ -1,12 +1,12 @@ -# $Id: Makefile,v 1.1 1995-09-08 19:34:26 jfieber Exp $ +# $Id: Makefile,v 1.2 1995-09-25 04:53:26 jfieber Exp $ SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml -SRCS+= booting.sgml contrib.sgml ctm.sgml current.sgml dialup.sgml -SRCS+= diskless.sgml eresources.sgml glossary.sgml handbook.sgml -SRCS+= history.sgml hw.sgml install.sgml kerberos.sgml kerneldebug.sgml -SRCS+= memoryuse.sgml mirrors.sgml nfs.sgml nutshell.sgml porting.sgml -SRCS+= ports.sgml ppp.sgml relnotes.sgml scsi.sgml sections.sgml +SRCS+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml dialup.sgml +SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml glossary.sgml +SRCS+= handbook.sgml history.sgml hw.sgml install.sgml kerberos.sgml +SRCS+= kerneldebug.sgml memoryuse.sgml mirrors.sgml nfs.sgml nutshell.sgml +SRCS+= porting.sgml ports.sgml ppp.sgml relnotes.sgml scsi.sgml sections.sgml SRCS+= slipc.sgml slips.sgml submitters.sgml sup.sgml SRCS+= troubleshooting.sgml userppp.sgml .include diff --git a/handbook/authors.sgml b/handbook/authors.sgml index a13fe9c14f..93fa26190a 100644 --- a/handbook/authors.sgml +++ b/handbook/authors.sgml @@ -1,29 +1,100 @@ - + -<asami@FreeBSD.org>"> -<awebster@dataradio.com>"> -<davidg@Root.COM>"> -<dufault@hda.com>"> -<gclarkii@FreeBSD.org>"> -<gena@NetVision.net.il>"> -<ghelmer@alpha.dsu.edu>"> -<gpalmer@FreeBSD.org>"> -<jfieber@FreeBSD.org>"> -<jkh@FreeBSD.org>"> -<joerg_wunsch@uriah.heep.sax.de>"> -<john@starfire.MN.ORG>"> -<mark@grondar.za>"> -<martin@innovus.com>"> -<md@bsc.no>"> -<nik@blueberry.co.uk>"> -<phk@FreeBSD.org>"> -<paul@FreeBSD.org>"> -<rgrimes@FreeBSD.org>"> -<whiteside@acm.org>"> -<wilko@yedi.iaf.nl>"> +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> + +"> diff --git a/handbook/booting.sgml b/handbook/booting.sgml index 3c887d564e..74a168ba9c 100644 --- a/handbook/booting.sgml +++ b/handbook/booting.sgml @@ -1,170 +1,170 @@ - The FreeBSD Booting Process + The FreeBSD Booting Process

Contributed by &a.phk;. v1.1, April 26th. Booting FreeBSD is essentially a three step: Load the kernel, determine the root filesystem and initialize user-land things. This leads to some interesting possibilities shown below. - Loading a kernel + Loading a kernel

We presently have three basic mechanisms for loading the kernel as described below: They all pass some information to the kernel to help the kernel decide what to do next. Biosboot Biosboot is our ``bootblocks'', it consists of two files, which will be installed in the first 8Kbytes of the floppy or hard-disk slice to be booted from. Biosboot can load a kernel from a FreeBSD filesystem. Dosboot Dosboot was written by DI. Christian Gusenbauer, and is unfortunately at this time one of the few pieces of code that isn't compilable under FreeBSD itself because it is written for MicroSoft compilers. Dosboot will boot the kernel from a MS-DOS file or from a FreeBSD filesystem partition on the disk. It attempts to negotiate with the various and strange kinds of memory manglers that lurk in high memory on MS/DOS systems and usually wins them for it's case. Netboot Netboot will try to find a supported ethernet card, and use BOOTP, TFTP and NFS to find a kernel file to boot. - Determine the root filesystem + Determine the root filesystem

Once the kernel is loaded and the boot-code jumps to it, the kernel will initialize itself, trying to determine what hardware is present and so on, and then it needs to find a root filesystem. Presently we support the following types of rootfilesystems: UFS This is the most normal type of root filesystem. It can reside on a floppy or on harddisk. MSDOS While this is technically possible, it isn't particular useful, because of ``FAT'' filesystems inability to make links, device nodes and such ``UNIXisms''. MFS This is actually a UFS filesystem which has been compiled into the kernel. That means that the kernel does not really need any disks/floppies or other HW to function. CD9660 This is for using a CD-ROM as root filesystem. NFS This is for using a fileserver as root filesystem, basically making it a diskless machine. - Initialize user-land things + Initialize user-land things

To get the user-land going, when the kernel has finished initialization, it will create a with ``/sbin/init''. You can substitute any program for /sbin/init, as long as you keep in mind that: there is no stdin/out/err unless you open it yourself, if you exit, the machine panics signal handling is special for ``Interesting combinations + Interesting combinations

Boot a kernel with a MFS in it with a special /sbin/init which... mounts your /C: Attaches C:/freebsd.fs on /dev/vn0 mounts /dev/vn0 as /rootfs makes symlinks /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin ... Now you run FreeBSD without repartitioning your hard disk... server:˜you/FreeBSD as /nfs, chroots to /nfs and executes /sbin/init there Now you run FreeBSD diskless, even though you don't control the NFS server... /dev/rwd0 and writes it to a remote tape station or fileserver. Now you finally got that backup you should have made a year ago... E -- Acts as a firewall/web-server/what do I know... This is particular interesting since you can boot from a write- protected floppy, but still write to your root filesystem... diff --git a/handbook/crypt.sgml b/handbook/crypt.sgml new file mode 100644 index 0000000000..5fba49f7a0 --- /dev/null +++ b/handbook/crypt.sgml @@ -0,0 +1,80 @@ + + + +DES, MD5, and Crypt + +

Contributed by &a.wollman;24 September 1995. + +

History + +

In order to protect the security of passwords on UN*X systems from +being easily exposed, passwords have traditionally been scrambled in +some way. Starting with Bell Labs' Seventh Edition Unix, passwords +were encrypted using what the security people call a ``one-way hash +function''. That is to say, the password is transformed in such a way +that the original password cannot be regained except by brute-force +searching the space of possible passwords. Unfortunately, the only +secure method that was available to the AT&T researchers at the +time was based on DES, the Data Encryption Standard. This causes only +minimal difficulty for commercial vendors, but is a serious problem +for an operating system like FreeBSD where all the source code is +freely available, because national governments in many places like to +place restrictions on cross-border transport of DES and other +encryption software. + +

So, the FreeBSD team was faced with a dilemma: how could we provide +compatibility with all those UNIX systems out there while still not +running afoul of the law? We decided to take a dual-track approach: +we would make distributions which contained only a non-regulated +password scrambler, and then provide as a separate add-on library the +DES-based password hash. The password-scrambling function was moved +out of the C library to a separate library, called `libcrypt' +because the name of the C function to implement it is +`crypt'. In FreeBSD 1.x and some pre-release 2.0 snapshots, +the non-regulated scrambler uses an insecure function written by Nate +Williams; in subsequent releases this was replaced by a mechanism +using the RSA Data Security, Inc., MD5 one-way hash function. Because +neither of these functions involve encryption, they are believed to be +exportable from the US and importable into many other countries. + +

Meanwhile, work was also underway on the DES-based password hash +function. First, a version of the `crypt' function which was +written outside the US was imported, thus synchronizing the US and +non-US code. Then, the library was modified and split into two; the +DES `libcrypt' contains only the code involved in performing +the one-way password hash, and a separate `libcipher' was +created with the entry points to actually perform encryption. The +code was partitioned in this way to make it easier to get an export +license for the compiled library. + +

Recognizing your `crypt' mechanism + +

It is fairly easy to recognize whether a particular password +string was created using the DES- or MD5-based hash function. +MD5 password strings always begin with the characters +`$1$'. DES password strings do not have +any particular identifying characteristics, but they are shorter +than MD5 passwords, and are coded in a 64-character alphabet +which does not include the `$' character, so a +relatively short string which doesn't begin with a dollar sign is +very likely a DES password. + +

Determining which library is being used on your system is fairly +easy for most programs, except for those like `init' which +are statically linked. (For those programs, the only way is to try +them on a known password and see if it works.) Programs which use +`crypt' are linked against `libcrypt', which for +each type of library is a symbolic link to the appropriate +implementation. For example, on a system using the DES versions: + + +$ cd /usr/lib +$ ls -l /usr/lib/libcrypt* +lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a +lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0 +lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a + + +On a system using the MD5-based libraries, the same links will be +present, but the target will be `libscrypt' rather than +`libdescrypt'. diff --git a/handbook/dma.sgml b/handbook/dma.sgml new file mode 100644 index 0000000000..db63b82b8b --- /dev/null +++ b/handbook/dma.sgml @@ -0,0 +1,105 @@ + + + +PC DMA + +

Contributed by &a.uhclem;. + 31 August 1995. + +Posted to : + +

Yes, as long as `single mode' is appropriate for you, there's no need +to worry about TC. TC is intented for continuous mode. Well, i've +just noticed that the PC DMAC cannot even generate an interrupt when +ready... hmm, go figure, the Z80 DMAC did it. +

And yes, for `single mode', the masking trick will do it. The +peripheral device will issue a DRQ signal for each transfered +byte/word, and masking would prevent the DMAC from accepting new DRQs +for this channel. Aborting a continuous mode transfer would not be so +easy (or even impossible at all). + + +Actually, masking is the correct procedure for all transfer modes on the +8237, even autoinit mode, which is frequently used for audio operations +since it allows seamless DMA transfers with no under/overruns. + +You are generally correct about TC. All the TC signal does is +when the counter on any channel in the DMA controller goes from +one to zero, TC is asserted. What the peripherals are supposed +to if they want to generate an interrupt when the transfer is +through, is that peripheral device is supposed to look at +(-DACK%d && TC && DEVICE_DMA_ACTIVE) and then +latch an IRQ%d for the 8259 interrupt controller. Since there is +only one TC signal, it is important that only the peripheral who +is transferring data at that moment honor the TC signal. + +The host CPU will eventually investigate the interrupt by having some driver +poll the hardware associated with the peripheral, NOT the DMA controller. +If a peripheral doesn't want an interrupt associated with the DMA counter +reaching zero, it doesn't implement the circuitry to monitor TC. + +Some sound cards realize that when the TC hits zero it means the DMA +is now idle and that is really too late, so they don't use TC and +instead allow the driver to program in a local counter value, which +is usually set lower than the value programmed into the DMA. This means +the peripheral can interrupt the CPU in advance of the DMA "running dry", +allowing the CPU to be ready to reprogram the DMA the instant it finishes +what it is doing, rather than incurring the latency later. + +This also means that two or more different devices could share a +DMA channel, by tristating DRQ%d when idle and only +honoring -DACK%d when the device knows it is expecting +the DMA to go active. (Iomega PC2B boards forgot this minor +point and will transfer data even if they are not supposed to.) + + +So, if you want to abort a 8237 DMA transfer of any kind, simply mask the +bit for that DMA channel in the 8237. Note: You can't interrupt an individual +transfer (byte or burst) in progress. Think about it... if the DMA is +running, how is your OUT instruction going to be performed? +The CPU has to be bus master for the OUT to be performed. + +Since the 8237 DMA re-evaluates DMA channel priorities constantly, even if +the DMA had already asserted HOLD (to request the bus from the CPU) when +the OUT actually took place, the processor would still grant the bus to the +DMA controller. The DMA controller would look for the highest-priority +DMA source remaining (your interrupt is masked now) at that instant, +and if none remained, the DMA will release HOLD and the processor will +get the bus back after a few clocks. + +There is a deadly race condition in this area, but if I remember right, +you can't get into it via mis-programming the DMA, UNLESS you cause the DMA +controller to be RESET. You should not do this. Effectively the CPU +can give up the bus and the DMA doesn't do anything, including giving the +bus back. Very annoying and after 16msec or so, all is over since +refresh on main memory has started failing. + +So, mask the DMA controller, then go do what you have to do to get the +transfer aborted in the peripheral hardware. In some extremely stupid +hardware (I could mention a few), you may have to program the DMA to +transfer one more byte to a garbage target to get the peripheral hardware +to go back to an idle state. Most hardware these days isn't that +stupid. + +Technically, you are supposed to mask the DMA channel, program the other +settings (direction, address, length, etc), issue commands to the +peripheral and then unmask the DMA channel once the peripheral commands have +been accepted. The last two steps can be done out of order without +harm, but you must always program the DMA channel while it is masked to +avoid spraying data all over the place in the event the peripheral +unexpected asserts DRQ%d. + +If you need to pad-out an aborted buffer, once you have masked the +DMA, you can ask it how many bytes it still had to go and what +address it was to write to next. Your driver can then fill in the +remaining area or do what needs to be done. + + +Don't forget that the 8237 was designed for use with the 8085 and +really isn't suited to the job that IBM gave it in the original PC. +That's why the upper eight bits of DMA addressing appear to be lashed-on. +They are. Look at the schematics of the original PC and you will +the upper bits are kept in external latches that are enabled whenever +the DMA is too. Very kludgy. + diff --git a/handbook/esdi.sgml b/handbook/esdi.sgml new file mode 100644 index 0000000000..e75a19d9f7 --- /dev/null +++ b/handbook/esdi.sgml @@ -0,0 +1,421 @@ + + + + + + ESDI hard disks and FreeBSD + +

© 1995, &a.wilko;.24 September 1995. + + ESDI is an acronym that means Enhanced Small Device Interface. + It is loosely based on the good old ST506/412 interface originally + devised by Seagate Technology, the makers of the first affordable + 5.25" winchester disk. + + The acronym says Enhanced, and rightly so. In the first place + the speed of the interface is higher, 10 or 15 Mbits/second + instead of the 5 Mbits/second of ST412 interfaced drives. + Secondly some higher level commands are added, making the ESDI + interface somewhat 'smarter' to the operating system driver + writers. It is by no means as smart as SCSI by the way. ESDI + is standardised by ANSI. + + Capacities of the drives are boosted by putting more sectors + on each track. Typical is 35 sectors per track, high capacity + drives I've seen were up to 54 sectors/track. + + Although ESDI has been largely obsoleted by IDE and SCSI interfaces, + the availability of free or cheap surplus drives makes them + ideal for low (or now) budget systems. + + Concepts of ESDI +

+ Physical connections +

+ The ESDI interface uses two cables connected to each drive. + One cable is a 34 pin flatcable edge connector that carries + the command and status signals from the controller to the + drive and viceversa. The command cable is daisy chained + between all the drives. So, it forms a bus onto which all + drives are connected. + + The second cable is a a 20 pin flatcable edge connector that + carries the data to and from the drive. This cable is radially + connected, so each drive has it's own direct connection to the + controller. + + To the best of my knowledge PC ESDI controllers are limited + to using a maximum of 2 drives per controller. This is + compatibility feature(?) left over from the WD1003 standard + that reserves only a single bit for device addressing. + + Device addressing +

+ On each command cable a maximum of 7 devices and 1 controller + can be present. To enable the controller to uniquely + identify which drive it addresses, each ESDI device is equipped + with jumpers or switches to select the devices address. + + On PC type controllers the first drive is set to address 0, + the second disk to address 1. Always make sure you + set each disk to an unique address! So, on a PC with it's + two drives/controller maximum the first drive is drive 0, the + second is drive 1. + + Termination +

+ The daisy chained command cable (the 34 pin cable remember?) + needs to be terminated at the last drive on the chain. + For this purpose ESDI drives come with a termination resistor + network that can be removed or disabled by a jumper when it + is not used. + + So, one and only one drive, the one at + the fartest end of the command + cable has it's terminator installed/enabled. The controller + automatically terminates the other end of the cable. + Please note that this implies that the controller must be + at one end of the cable and not in the middle. + + Using ESDI disks with FreeBSD +

+ Why is ESDI such a pain to get working in the first place? + + People who tried ESDI disks with FreeBSD are known to have + developed a profound sense of frustration. A combination of + factors works against you to produce effects that are + hard to understand when you have never seen them before. + + This has also led to the popular legend ESDI and FreeBSD + is a plain NO-GO. + The following sections try to list all the pitfalls and + solutions. + + ESDI speed variants +

+ As briefly mentioned before, ESDI comes in two speed flavours. + The older drives and controllers use a 10 Mbits/second + data transfer rate. Newer stuff uses 15 Mbits/second. + + It is not hard to imagine that 15 Mbits/second drive cause + problems on controllers laid out for 10 Mbits/second. + As always, consult your controller and drive + documentation to see if things match. + + Stay on track +

+ Mainstream ESDI drives use 34 to 36 sectors per track. + Most (older) controllers cannot handle more than this + number of sectors. + Newer, higher capacity, drives use higher numbers of sectors + per track. For instance, I own a 670 Mb drive that has + 54 sectors per track. + + In my case, the controller could not handle this number + of sectors. It proved to work well except that it only + used 35 sectors on each track. This meant losing a + lot of diskspace. + + Once again, check the documentation of your hardware for + more info. Going out-of-spec like in the example might + or might not work. Give it a try or get another more + capable controller. + + Hard or soft sectoring +

+ Most ESDI drives allow hard or soft sectoring to be + selected using a jumper. Hard sectoring means that the + drive will produce a sector pulse on the start of each + new sector. The controller uses this pulse to tell when + it should start to write or read. + + Hard sectoring allows a selection of sector size (normally + 256, 512 or 1024 bytes per formatted sector). FreeBSD uses + 512 byte sectors. The number of sectors per track also varies + while still using the same number of bytes per formatted sector. + The number of unformatted bytes per sector varies, + dependent on your controller it needs more or less overhead + bytes to work correctly. Pushing more sectors on a track + of course gives you more usable space, but might give + problems if your controller needs more bytes than the + drive offers. + + In case of soft sectoring, the controller itself determines + where to start/stop reading or writing. For ESDI + hard sectoring is the default (at least on everything + I came across). I never felt the urge to try soft sectoring. + + In general, experiment with sector settings before you install + FreeBSD because you need to re-run the low-level format + after each change. + + Low level formatting +

+ ESDI drives need to be low level formatted before they + are usable. A reformat is needed whenever you figgle + with the number of sectors/track jumpers or the + physical orientation of the drive (horizontal, vertical). + So, first think, then format. + The format time must not be underestimated, for big + disks it can take hours. + + After a low level format, a surface scan is done to + find and flag bad sectors. Most disks have a + manufacturer bad block list listed on a piece of paper + or adhesive sticker. In addition, on most disks the + list is also written onto the disk. + Please use the manufacturer's list. It is much easier + to remap a defect now than after FreeBSD is installed. + + Stay away from low-level formatters that mark all + sectors of a track as bad as soon as they find one + bad sector. Not only does this waste space, it also + and more importantly causes you grief with bad144 + (see the section on bad144). + + Translations +

+ Translations, although not exclusively a ESDI-only problem, + might give you real trouble. + Translations come in multiple flavours. Most of them + have in common that they attempt to work around the + limitations posed upon disk geometries by the original + IBM PC/AT design (thanks IBM!). + + First of all there is the (in)famous 1024 cylinder limit. + For a system to be able to boot, the stuff (whatever + operating system) must be in the first 1024 cylinders + of a disk. Only 10 bits are available to encode the + cylinder number. For the number of sectors the limit + is 64 (0-63). + When you combine the 1024 cylinder limit with the 16 head + limit (also a design feature) you max out at fairly limited + disk sizes. + + To work around this problem, the manufacturers of ESDI + PC controllers added a BIOS prom extension on their boards. + This BIOS extension handles disk I/O for booting (and for + some operating systems all disk I/O) by using + translation. For instance, a big drive might be presented + to the system as having 32 heads and 64 sectors/track. + The result is that the number of cylinders is reduced to + something below 1024 and is therefore usable by the system + without problems. + It is noteworthy to know that FreeBSD after it's kernel has + started no longer uses the BIOS. More on this later. + + A second reason for translations is the fact that most + older system BIOSes could only handle drives with 17 sectors + per track (the old ST412 standard). Newer system BIOSes + usually have a user-defined drive type (in most cases this is + drive type 47). + + Whatever you do to translations after reading this document, + keep in mind that if you have multiple operating systems on the + same disk, all must use the same translation + + While on the subject of translations, I've seen one controller + type (but there are probably more like this) offer the option + to logically split a drive in multiple partitions as a BIOS + option. I had select 1 drive == 1 partition because this + controller wrote this info onto the disk. On powerup it + read the info and presented itself to the system based on + the info from the disk. + + Spare sectoring +

+ Most ESDI controllers offer the possibility to remap bad sectors. + During/after the low-level format of the disk bad sectors are + marked as such, and a replacement sector is put in place + (logically of course) of the bad one. + + In most cases the remapping is done by using N-1 sectors on + each track for actual datastorage, and sector N itself is + the spare sector. N is the total number of sectors physically + available on the track. + The idea behind this is that the operating system sees + a 'perfect' disk without bad sectors. In the case of + FreeBSD this concept is not usable. + + The problem is that the translation from bad to good + is performed by the BIOS of the ESDI controller. FreeBSD, + being a true 32 bit operating system, does not use the BIOS + after it has been booted. Instead, it has device drivers that + talk directly to the hardware. + + So: don't use spare sectoring, bad block remapping or + whatever it may be called by the controller manufacturer when you + want to use the disk for FreeBSD. + + Bad block handling +

+ The preceding section leaves us with a problem. The controller's + bad block handling is not usable and still FreeBSD's filesystems + assume perfect media without any flaws. + To solve this problem, FreeBSD use the bad144 tool. + Bad144 (named after a Digital Equipment standard for bad block + handling) scans a FreeBSD slice for bad blocks. Having found + these bad blocks, it writes a table with the offending block + numbers to the end of the FreeBSD slice. + + When the disk is in operation, the diskaccesses are checked + against the table read from the disk. Whenever a blocknumber + is requested that is in the bad144 list, a replacement block + (also from the end of the FreeBSD slice) is used. + In this way, the bad144 replacement scheme presents 'perfect' + media to the FreeBSD filesystems. + + There are a number of potential pitfalls associated with + the use of bad144. + First of all, the slice cannot have more than 126 bad sectors. + If your drive has a high number of bad sectors, you might need + to divide it into multiple FreeBSD slices each containing less + than 126 bad sectors. Stay away from low-level format programs + that mark every sector of a track as bad when + they find a flaw on the track. As you can imagine, the + 126 limit is quickly reached when the low-level format is done + this way. + + Second, if the slice contains the root filesystem, the slice + should be within the 1024 cylinder BIOS limit. During the + boot process the bad144 list is read using the BIOS and this + only succeeds when the list is within the 1024 cylinder limit. + Note that the restriction is not that only the root + filesystem must be within the 1024 cylinder limit, but + rather the entire slice that contains the root filesystem. + + + Kernel configuration +

+ ESDI disks are handled by the same wddriver as + IDE and ST412 MFM disks. The wd driver should work + for all WD1003 compatible interfaces. + + Most hardware is jumperable for one of two different I/O + address ranges and IRQ lines. This allows you to have + two wd type controllers in one system. + + When your hardware allows non-standard strappings, you + can use these with FreeBSD as long as you enter the + correct info into the kernel config file. + An example from the kernel config file (they live in + /sys/i386/conf BTW). + + +# First WD compatible controller +controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr +disk wd0 at wdc0 drive 0 +disk wd1 at wdc0 drive 1 + +# Second WD compatible controller +controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr +disk wd2 at wdc1 drive 0 +disk wd3 at wdc1 drive 1 + + + + + Particulars on ESDI hardware +

+ Adaptec 2320 controllers +

+ I succesfully installed FreeBSD onto a ESDI disk controlled by a + ACB-2320. No other operating system was present on the disk. + + To do so I low level formatted the disk using NEFMT.EXE + (ftpable from www.adaptec.com) and answered NO + to the question whether the disk should be formatted with a + spare sector on each track. The BIOS on the ACD-2320 was + disabled. I used the 'free configurable' option in the system + BIOS to allow the BIOS to boot it. + + Before using NEFMT.EXE I tried to format the disk using the + ACB-2320 BIOS builtin formatter. This proved to be a showstopper, + because it didn't give me an option to disable spare sectoring. + With spare sectoring enabled the FreeBSD installation + process broke down on the bad144 run. + + Please check carefully which ACB-232xy variant you have. The + x is either 0 or 2, indicating a controller without or with + a floppy controller on board. + + The y is more interesting. It can either be a blank, + a "A-8" or a "D". A blank indicates a plain 10 Mbits/second + controller. An "A-8" indicates a 15 Mbits/second controller + capable of handling 52 sectors/track. + A "D" means a 15 Mbits/second controller that can also + handle drives with > 36 sectors/track (also 52 ?). + + All variations should be capable of using 1:1 interleaving. Use 1:1, + FreeBSD is fast enough to handle it. + + Western Digital WD1007 controllers +

+ I succesfully installed FreeBSD onto a ESDI disk controlled by a + WD1007 controller. To be precise, it was a WD1007-WA2. Other + variations of the WD1007 do exist. + + To get it to work, I had to disable the sector translation and + the WD1007's onboard BIOS. This implied I could not use + the low-level formatter built into this BIOS. Instead, I grabbed + WDFMT.EXE from www.wdc.com Running this formatted my drive + just fine. + + Ultrastor U14F controllers +

+ According to multiple reports from the net, Ultrastor ESDI + boards work OK with FreeBSD. I lack any further info on + particular settings. + + + + Further reading

+ If you intend to do some serious ESDI hacking, you might want to + have the official standard at hand: + + The latest ANSI X3T10 committee document is: + +Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] + [X3T10/792D Rev 11] + + On Usenet the newsgroup is a noteworthy place to look + for more info. + + The World Wide Web (WWW) also proves to be a very handy info source: + For info on Adaptec ESDI controllers see . + For info on Western Digital controllers see . + + Thanks to... +

+ Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk + for testing. + diff --git a/handbook/handbook.sgml b/handbook/handbook.sgml index e6d76e862b..3295dbd3a5 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,161 +1,168 @@ - + %authors; %sections; ]> FreeBSD Handbook <author> <name>The FreeBSD Documentation Project</name> </author> - <date>August 31, 1995</date> + <date>September 24, 1995</date> <abstract>Welcome to FreeBSD! This handbook covers the installation and day to day use of <bf>FreeBSD Release 2.0.5</bf>. This manual is a <bf>work in progress</bf> and is the work of many individials. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to &a.jfieber; or to the FreeBSD Documentation Project mailing list <tt><htmlurl url="mailto:doc@freebsd.org" name="<doc@freebsd.org>"></tt>. +The latest version of this document is always available from +the <url url="http://www.freebsd.org/" name="FreeBSD World Wide +Web server">. </abstract> <toc> <!-- ************************************************************ --> <part><heading>Basics</heading> <chapt><heading>Introduction</heading> &nutshell; &history; &relnotes; &install; &basics; <chapt><heading>Installing applications</heading> <sect><heading>* Installing packages</heading> &ports; &porting; <!-- ************************************************************ --> <part><heading>System Administration</heading> <chapt><heading>Reconfiguring the Kernel<label id="kernelconfig"></heading> <p>This section is in progress. Please contact Deborah Bennett <htmlurl url="mailto:deborah@gallifrey.microunity.com" name="<deborah@gallifrey.microunity.com>"> for more information. In the meantime, please refer to Kernel Configuration section of the <url url="../FAQ/freebsd-faq.html" name="FreeBSD FAQ">. <!-- &kernelconfig; --> <chapt><heading>Users, groups and security</heading> - <sect><heading>* DES, MD5 and Crypt</heading> + &crypt; <sect><heading>* S/Key</heading> &kerberos; <sect><heading>* Firewalls</heading> <chapt><heading>Printing</heading> <p>This section is in progress. Please contact Sean Kelly <url url="mailto:kelly@fsl.noaa.gov" name="kelley@fsl.noaa.gov"> for more information. <chapt><heading>The X-Window System</heading> <p>Pending the completion of this section, please refer to documentation supplied by the <url url="http://www.xfree86.org/" name="The XFree86 Project, Inc">. <chapt><heading>Managing hardware</heading> - &scsi; <sect><heading>* Adding and reconfiguring disks</heading> + &scsi; + &esdi; <sect><heading>* Tapes and backups</heading> <sect><heading>* Serial ports</heading> <sect><heading>* Sound cards</heading> <!-- ************************************************************ --> <part><heading>Network Communications</heading> <chapt><heading>Basic Networking</heading> <sect><heading>* Ethernet basics</heading> <sect><heading>* Serial basics</heading> <sect><heading>* Hardwired Terminals</heading> &dialup; <chapt><heading>PPP and SLIP</heading> <p>If your connection to the internet is through a modem, or you wish to provide other people with dialup connections to the internet using FreeBSD, you have the option of using PPP or SLIP. Furthermore, two varieties of PPP are provided: <em>user</em> (sometimes referred to as iijppp) and <em>kernel</em>. The procedures for configuring both types of PPP, and for setting up SLIP are described in this chapter. &userppp; &ppp; &slipc; &slips; <chapt><heading>Advanced networking</heading> <sect><heading>Gateways and routing</heading> <p>This section is in progress. Please contact Coranth Gryphon <htmlurl url="mailto:gryphon@healer.com" name="<gryphon@healer.com>"> for more information. &nfs; - <sect><heading>* Yellow Pages/NIS</heading> &diskless; + <sect><heading>* Yellow Pages/NIS</heading> <sect><heading>* ISDN</heading> <chapt><heading>* Mail</heading> <!-- ************************************************************ --> <part><heading>Advanced topics</heading> ¤t; &ctm; ⊃ &kerneldebug; &submitters; - &booting; - &memoryuse; &troubleshooting; + <!-- ************************************************************ --> <part><heading>Appendices</heading> &mirrors; &bibliography; &eresources; &hw; + <chapt><heading>Assorted technical topics</heading> + &booting; + &memoryuse; + &dma; &contrib; &glossary; </book> </linuxdoc> diff --git a/handbook/install.sgml b/handbook/install.sgml index ba63835ca2..d0b7a15270 100644 --- a/handbook/install.sgml +++ b/handbook/install.sgml @@ -1,652 +1,798 @@ -<!-- $Id: install.sgml,v 1.9 1995-08-29 01:42:39 jfieber Exp $ --> +<!-- $Id: install.sgml,v 1.10 1995-09-25 04:53:32 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> --> <chapt><heading>Installing FreeBSD<label id="install"></heading> + <p>So, you would like to try out FreeBSD on your system? + This section is a quick-start guide for what you need to + do. FreeBSD can be installed from a variety of media + including CD-ROM, floppy disk, magnetic tape, an MS-DOS + partition, and if you have a network connection, via + anonymous ftp or NFS. + + Regardless of the installation media you choose, you can + get started by downleading the <bf>installation disk</bf> + as described below. Booting your computer with disk will + provide important information about compatibility between + FreeBSD and your hardware which could dictate which + installation options are possible. It can also provide + early clues to compatibilty problems that could prevent + FreeBSD running on your system at all. If you plan on + installing via anonymous FTP, then this installation disk + is all you need to download. + + For more information on obtaining the FreeBSD distribution + itself, please see <ref id="mirrors" name="Obtaining + FreeBSD"> in the Appendix. + + So, to get the show on the road, follow these steps: + <enum> + + <item>Review the <ref id="install:hw" name="supported + configurations"> section of this installation guide to + be sure that your hardware is supported by FreeBSD. It + may be helpful to make a list of any special cards you + have installed, such as SCSI controllers, etherernet + adapters or sound cards. This list should include + relevant configuration parameters such as interrupts + (IRQ) and IO port addresses. </item> + + <item>Download the <url + url="ftp://ftp.freebsd.org/pub/FreeBSD/2.0.5-RELEASE/UPDATES/boot.flp" + name="installation boot disk image"> file to your hard + drive, and be sure to tell your browser to + <em>save</em> rather than <em>display</em>. + <bf>Note:</bf> This disk image can be used for + <em>both</em> 1.44 megabyte 3.5 inch floppy disks and + 1.2 megabyte 5.25 inch floppy disks.</item> + + <item>Make the installation boot disk from the image file: + <itemize> + <item>If you are using MS-DOS download + <url +url="ftp://ftp.freebsd.org/pub/FreeBSD/tools/dos-tools/rawrite.exe" + name="rawrite.exe"> (tell your browser to <em>save</em> rather than + <em>display</em>!), then run it: +<tscreen><verb> +C:\> rawrite +</verb></tscreen> The + program will prompt you for the floppy drive + containing the disk you want to write to (A: or + B:) and the name of the file to put on disk (boot.flp). + </item> + + <item>If you are using a UNIX system: +<tscreen> +% dd if=boot.flp of=<em>disk_device</em> bs=18k +</tscreen> + where <em>disk_device</em> is the <tt>/dev</tt> + entry for the floppy drive. On FreeBSD systems, this + is <tt>/dev/rfd0</tt> for the A: drive and + <tt>/dev/rfd1</tt> for the B: drive. + </item> + </itemize> + + </item> + + <item>With the installation disk in the A: drive, reboot your + computer. You should get a boot prompt something like this: + <tscreen> +>> FreeBSD BOOT ...<newline> +Use hd(1,a)/kernel to boot sd0 when wd0 is also installed.<newline> +Usage: [[hd(1,a)]/kernel][-abcCdhrsv]<newline> +Use ? for file list or press Enter for defaults<newline> +Boot: + </tscreen> + If you do <em>not</em> type anything, FreeBSD will automatically boot + with its default configuration after a delay of about + five seconds. As FreeBSD boots, it probes your computer + to determine what hardware is installed. The results of + this probing is displayed on the screen. + </item> + + <item>When the booting process is finished, The main FreeBSD + installation menu will be displayed.</item> + + </enum> + + <p><bf>If something goes wrong...</bf> + + <p>Due to limitations of the PC architecture, it is + impossible for probing to be 100 percent reliable. In the event + that your hardware is incorrectly identified, or that the + probing causes your computer to lock up, first check the + <ref id="install:hw" name="supported + configurations"> section of this installation guide to be + sure that your hardware is indeed supported by FreeBSD. + + <p>If your hardware is supported, reset the computer and when + the <tt>Boot:</tt> prompt comes up, type <bf>-c</bf>. This puts + FreeBSD into a configuration mode where you can supply + hints about your hardware. The FreeBSD kernel on the + installation disk is configured assuming that most hardware + devices are in their factory default configuration in terms + of IRQs, IO addresses and DMA channels. If your hardware + has been reconfigured, you will most likely need to use the + <bf>-c</bf> option at boot to tell FreeBSD where things are. + + <p>It is also possible that a probe for a device not present + will cause a later probe for another device that is present + to fail. In that case, the probes for the conflicting + driver(s) should be disabled. + + <p>In the configuration mode, you can: + + <itemize> + <item>List the device drivers installed in the kernel.</item> + <item>Disable device drivers for hardware not present in your + system.</item> + <item>Change the IRQ, DRQ, and IO port addresses used by a + device driver.</item> + </itemize> + + <p>While at the <tt>config></tt> prompt, type + <tt>help</tt> for more information on the available + commands. After adjusting the kernel to match how you have + your hardware configured, type <tt>quit</tt> at the + <tt>config></tt> prompt to continue booting with the new + settings. + + After FreeBSD has been installed, changes made in the + configuration mode will be permanent so you do not have + to reconfigure every time you boot. Even so, it is likely + that you will want to build a custom kernel to optimize the + performance of your system. See <ref id="kernelconfig" + name="Kernel configuration"> for more information on + creating custom kernels. + <sect><heading>MS-DOS user's Questions and Answers</heading> + <p>Many FreeBSD users wish to install FreeBSD on PCs inhabited + by MS-DOS. Here are some commonly asked questions about + installing FreeBSD on such systems. + <p><bf>Help! I have no space! Do I need to delete everything first?</bf> If your machine is already running MS-DOS and has little or no free space available for FreeBSD's installation, all is not lost! You may find the FIPS utility, provided in the <tt>tools</tt> directory on the FreeBSD CDROM or on the various FreeBSD ftp sites, to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition, using the DOS 6.xx DEFRAG utility or the Norton Disk tools, then run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the <em>Distributions</em> menu for an estimation of how much free space you'll need for the kind of installation you want. <bf>Can I use compressed MS-DOS filesystems from FreeBSD?</bf> No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/dblspaced file!). <bf>Do not remove that file!</bf> You will probably regret it greatly! It is probably better to create another uncompressed MS-DOS primary partition and use this for communications between MS-DOS and FreeBSD. <bf>Can I mount my MS-DOS extended partitions?</bf> This feature isn't in FreeBSD 2.0.5 but should be in 2.1. We've laid all the groundwork for making this happen, now we just need to do the last 1 percent of the work involved. <bf>Can I run MS-DOS binaries under FreeBSD?</bf> Not yet! We'd like to add support for this someday, but are still lacking anyone to actually do the work. Ongoing work with Linux's PCEMU utility may bring this much closer to being a reality sometime soon. Send mail to hackers@freebsd.org if you're interested in joining this effort! <sect><heading>Supported Configurations<label id="install:hw"></heading> <p>FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus based PC's, ranging from 386sx to Pentium class machines (though the 386sx is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controller, network and serial cards is also provided. A minimum of four megabytes of RAM is required to run FreeBSD. To run the X-window system, eight megabytes of RAM is the recommended minimum. Following is a list of all disk controllers and ethernet cards currently known to work with FreeBSD. Other configurations may very well work, and we have simply not received any indication of this. <sect1><heading>Disk Controllers</heading> <p> <itemize> <item>WD1003 (any generic MFM/RLL) <item>WD1007 (any generic IDE/ESDI) <item>WD7000 <item>IDE <item>ATA <item>Adaptec 152x series ISA SCSI controllers <item>Adaptec 154x series ISA SCSI controllers <item>Adaptec 174x series EISA SCSI controller in standard and enhanced mode. <item>Adaptec 274X/284X/2940 <!-- 3940 (in 2.1) --> (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers <item>Adaptec AIC-6260 and AIC-6360 based boards, which includes the AHA-152x and SoundBlaster SCSI cards. <bf>Note:</bf> You cannot boot from the SoundBlaster cards as they have no on-board BIOS, which is necessary for mapping the boot device into the system BIOS I/O vectors. They are perfectly usable for external tapes, CDROMs, etc, however. The same goes for any other AIC-6x60 based card without a boot ROM. Some systems DO have a boot ROM, which is generally indicated by some sort of message when the system is first powered up or reset. Check your system/board documentation for more details. <item>Buslogic 545S & 545c <bf>Note:</bf> that Buslogic was formerly known as "Bustec". <item>Buslogic 445S/445c VLB SCSI controller <item>Buslogic 742A, 747S, 747c EISA SCSI controller. <item>Buslogic 946c PCI SCSI controller <item>Buslogic 956c PCI SCSI controller <item>NCR 53C810 and 53C825 PCI SCSI controller. <item>NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller. <item>DTC 3290 EISA SCSI controller in 1542 emulation mode. <item>UltraStor 14F, 24F and 34F SCSI controllers. <item>Seagate ST01/02 SCSI controllers. <item>Future Domain 8xx/950 series SCSI controllers. </itemize> With all supported SCSI controllers, full support is provided for SCSI-I & SCSI-II peripherals, including Disks, tape drives (including DAT) and CD ROM drives. The following CD-ROM type systems are supported at this time: <itemize> <item>SCSI (also includes ProAudio Spectrum and SoundBlaster SCSI) (cd) <item>Mitsumi proprietary interface (mcd) <item>Matsushita/Panasonic (Creative) proprietary interface (matcd) <item>Sony proprietary interface (scd) </itemize> <bf>Note:</bf> CD-Drives with IDE interfaces are not supported at this time. Some controllers have limitations with the way they deal with >16MB of memory, due to the fact that the ISA bus only has a DMA address space of 24 bits. If you do your arithmetic, you'll see that this makes it impossible to do direct DMA to any address >16MB. This limitation is even true of some EISA controllers (which are normally 32 bit) when they're configured to emulate an ISA card, which they then do in *all* respects. This problem is avoided entirely by IDE controllers (which do not use DMA), true EISA controllers (like the UltraStor, Adaptec 1742A or Adaptec 2742) and most VLB (local bus) controllers. In the cases where it's necessary, the system will use "bounce buffers" to talk to the controller so that you can still use more than 16Mb of memory without difficulty. <sect1><heading>Ethernet cards</heading> <p> <itemize> <item>SMC Elite 16 WD8013 ethernet interface, and most other WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT based clones. SMC Elite Ultra is also supported. <item>DEC EtherWORKS III NICs (DE203, DE204, and DE205) <item>DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) <item>DEC DC21140 based NICs (SMC???? DE???) <item>DEC FDDI (DEFPA/DEFEA) NICs <item>Fujitsu MB86960A family of NICs <item>Intel EtherExpress <item>Isolan AT 4141-0 (16 bit) <item>Isolink 4110 (8 bit) <item>Novell NE1000, NE2000, and NE2100 ethernet interface. <item>3Com 3C501 cards <item>3Com 3C503 Etherlink II <item>3Com 3c505 Etherlink/+ <item>3Com 3C507 Etherlink 16/TP <item>3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III <item>Toshiba ethernet cards <item>PCMCIA ethernet cards from IBM and National Semiconductor are also supported. </itemize> <sect1><heading>Miscellaneous devices</heading> <p> <itemize> <item>AST 4 port serial card using shared IRQ. <item>ARNET 8 port serial card using shared IRQ. <item>BOCA ATIO66 6 port serial card using shared IRQ. <item>Cyclades Cyclom-y Serial Board. <item>STB 4 port card using shared IRQ. <item>Mitsumi (all models) CDROM interface and drive. <item>SDL Communications Riscom/8 Serial Board. <item>Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive. <item>Matsushita/Panasonic (Creative SoundBlaster) CDROM interface and drive. <item>Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound and Roland MPU-401 sound cards. </itemize> FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but support is apparently close to materializing. Details will be posted as the situation develops. <sect><heading>Preparing for the installation</heading> <p>There are a number of different methods by which FreeBSD can be installed. The following describes what preparation needs to be done for each type. <sect1><heading>Before installing from CDROM</heading> <p>If your CDROM is of an unsupported type, such as an IDE CDROM, then please skip to section 2.3: MS-DOS Preparation. There is not a lot of preparatory work that needs to be done to successfully install from one of Walnut Creek's FreeBSD CDROMs (other CDROM distributions may work as well, but I can't say for sure as I have no hand or say in their creation). You can either boot into the CD installation directly from MS-DOS using Walnut Creek's supplied "install" batch file or you can make a boot floppy by writing the supplied image (floppies/boot.flp) onto a floppy with the "go" command, which invokes the rawrite.exe command found in the tools/ subdirectory. If you're creating the boot floppy from a UNIX machine, you may find that ``dd if=floppies/boot.flp of=/dev/rfd0'' or ``dd if=floppies/boot.flp of=/dev/floppy'' works well, depending on your hardware and operating system environment. Once you've booted from MS-DOS or floppy, you should be able to select CDROM as the media type in the Media menu and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted from the hard disk, you should find the CD mounted on the directory /cdrom. A utility called `lndir' comes with the XFree86 distribution which you may also find useful: It allows you to create "link tree" directories to things on Read-Only media like CDROM. One example might be something like this: <tscreen>mkdir /usr/ports<newline>lndir /cdrom/ports /usr/ports</tscreen> Which would allow you to then "cd /usr/ports; make" and get all the sources from the CD, but yet create all the intermediate files in /usr/ports, which is presumably on a more writable media! <sect1><heading>Before installing from Floppy</heading> <p>If you must install from floppy disks, either due to unsupported hardware or just because you enjoy doing things the hard way, you must first prepare some floppies for the install. The first floppy you'll need is ``floppies/root.flp'', which is somewhat special in that it's not a MS-DOS filesystem floppy at all, but rather an "image" floppy (it's actually a gzip'd cpio file). You can use the rawrite.exe program to do this under DOS, or ``dd'' to do it on a UNIX Workstation (see notes in section 2.1 concerning the ``floppies/boot.flp'' image). Once this floppy is made, put it aside. You'll be asked for it later. You will also need, at minimum, as many 1.44MB or 1.2MB floppies as it takes to hold all files in the bin (binary distribution) directory. THESE floppies *must* be formatted using MS-DOS, using with the FORMAT command in MS-DOS or the File Manager format command in Microsoft Windows(tm). Factory preformatted floppies will also work well, provided that they haven't been previously used for something else. Many problems reported by our users in the past have resulted from the use of improperly formatted media, so we simply take special care to mention it here! After you've MS-DOS formatted the floppies, you'll need to copy the files onto them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you've got all the distributions you want packed up in this fashion. Select ``Floppy'' from the Media menu at installation time and you will be prompted for everything after that. <sect1><heading>Before installing from a MS-DOS partition</heading> <p>To prepare for installation from an MS-DOS partition, copy the files from the distribution into a directory called <tt>C:\FREEBSD</tt>. The directory tree structure of the CDROM must be partially reproduced within this directory so we suggest using the DOS <tt>xcopy</tt> command. For example, to prepare for a minimal installation of FreeBSD: <tscreen><verb> C> MD C:\FREEBSD C> XCOPY /S E:\FLOPPIES C:\FREEBSD\FLOPPIES\ C> XCOPY /S E:\DISTS\BIN C:\FREEBSD\BIN\ </verb></tscreen> asssuming that <tt>C:</tt> is where you have free space and <tt>E:</tt> is where your CDROM is mounted. Note that you need the <tt>FLOPPIES</tt> directory because the <tt>root.flp</tt> image is needed during an MS-DOS installation. For as many `DISTS' you wish to install from MS-DOS (and you have free space for), install each one under <tt>C:\FREEBSD</tt> - the <tt>BIN</tt> dist is only the minimal requirement. If you have room on your MS-DOS partition for all the distributions, you could replace the last line above with: <tscreen><verb> C> XCOPY /S E:\DISTS C:\FREEBSD\ </verb></tscreen> which would copy all the subdirectories of <tt>E:\DISTS</tt> to <tt>C:\FREEBSD</tt>. <sect1><heading>Before installing from QIC/SCSI Tape</heading> <p>Installing from tape is probably the easiest method, short of an on-line install using FTP or a CDROM instal. The installation program expects the files to be simply tar'ed onto the tape, so after getting all of the files for distribution you're interested in, simply tar them onto the tape with a command like: <tscreen> cd /freebsd/distdir<newline> tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2 </tscreen> Make sure that the `floppies/' directory is one of the "dists" given above, since the installation will look for `floppies/root.flp' on the tape. When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you'll be allowed to choose) to accommodate the FULL contents of the tape you've created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage! You should expect to require as much temporary storage as you have stuff written on tape. <sect1><heading>Before installing over a network</heading> <p>You can do network installations over 3 types of communications links: <descrip> <tag>Serial port</tag> SLIP or PPP <tag>Parallel port</tag> PLIP (laplink cable) <tag>Ethernet</tag> A standard ethernet controller (includes some PCMCIA). </descrip> SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation doesn't currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you're using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you'll need to know it fairly soon in the installation process. You will need to know, at the minimum, your service provider's IP address and possibly your own (though you can also leave it blank and allow PPP to negotiate it with your ISP). You also need to know how to use the various "AT commands" to dial the ISP with your particular modem as the PPP dialer provides only a very simple terminal emulator. If a hard-wired connection to another FreeBSD (2.0R or later) machine is available, you might also consider installing over a "laplink" parallel port cable. The data rate over the parallel port is much higher than is what's typically possible over a serial line (up to 50k/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adaptor is always a good choice! FreeBSD supports most common PC ethernet cards, a table of supported cards (and their required settings) provided as part of the FreeBSD Hardware Guide - see the Documentation menu on the boot floppy. If you are using one of the supported PCMCIA ethernet cards, also be sure that it's plugged in _before_ the laptop is powered on! FreeBSD does not, unfortunately, currently support "hot insertion" of PCMCIA cards. You will also need to know your IP address on the network, the "netmask" value for your address class and the name of your machine. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you'll also need a name server and possibly the address of a gateway (if you're using PPP, it's your provider's IP address) to use in talking to it. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator _first_ before trying this type of installation! Once you have a network link of some sort working, the installation can continue over NFS or FTP. <sect2><heading>Preparing for NFS installation</heading> <p>NFS installation is fairly straight-forward: Simply copy the FreeBSD distribution files you're interested onto a server somewhere and then point the NFS media selection at it. If this server supports only "privileged port" access (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support "subdir mounts", e.g. if your FreeBSD 2.0.5 distribution directory lives on: ziggy:/usr/archive/stuff/FreeBSD Then ziggy will have to allow the direct mounting of /usr/archive/stuff/FreeBSD, not just /usr or /usr/archive/stuff. In FreeBSD's /etc/exports file, this is controlled by the ``-alldirs'' option. Other NFS servers may have different conventions. If you are getting `Permission Denied' messages from the server then it's likely that you don't have this enabled properly! <sect2><heading>Preparing for FTP Installation</heading> <p>FTP installation may be done from any mirror site containing a reasonably up-to-date version of FreeBSD 2.0.5, a full menu of reasonable choices from almost anywhere in the world being provided by the FTP site menu. If you are installing from some other FTP site not listed in this menu, or you are having troubles getting your name server configured properly, you can also specify your own URL by selecting the ``Other'' choice in that menu. A URL can also be a direct IP address, so the following would work in the absence of a name server: <tscreen> ftp://192.216.222.4/pub/FreeBSD/2.0.5-RELEASE</tscreen> <em><bf>NOTE:</bf> Substitute "ALPHA" for "RELEASE" during the ALPHA test period!</em> If you are installing through a firewall then you should probably select ``Passive mode'' ftp, which is the default. If you are talking to a server which does not support passive mode for some reason, see the Options menu to select Active mode transfers. <sect><heading>Installing FreeBSD</heading> <p>Once you've taken note of the appropriate preinstallation steps, you should be able to install FreeBSD without any further trouble. Should this not be true, then you may wish to go back and re-read the relevant preparation section (section 2.x) for the installation media type you're trying to use - perhaps there's a helpful hint there that you missed the first time? If you're having hardware trouble, or FreeBSD refuses to boot at all, read the Hardware Guide provided on the boot floppy for a list of possible solutions. The FreeBSD boot floppy contains all the on-line documentation you should need to be able to navigate through an installation and if it doesn't then I'd like to know what you found most confusing! It is the objective of the FreeBSD installation program (sysinstall) to be self-documenting enough that painful "step-by-step" guides are no longer necessary. It may take us a little while to reach that objective, but that's the objective! Meanwhile, you may also find the following "typical installation sequence" to be helpful: <enum> <item>Boot the boot floppy. After a boot sequence which can take anywhere from from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the floppy doesn't boot at all, or the boot hangs at some stage, go read the Q&A section of the Hardware Guide for possible causes. <item>Press F1. You should see some basic usage instructions on the menu system and general navigation. If you haven't used this menu system before then PLEASE read this thoroughly! <item>If English is not your native language, you may wish to proceed directly to the Language option and set your preferred language. This will bring up some of the documentation in that language instead of english. <item>Select the Options item and set any special preferences you may have. <item>Select Proceed, bringing you to the Installation Menu. </enum> <sect1><heading>The installation menu</heading> <p>You can do anything you like in this menu without altering your system <em>except</em> for "Commit", which will perform any requests to alter your system you may have made. If you're confused at any point, the F1 key usually pulls up the right information for the screen you're in. <enum> <item>The first step is generally `Partition', which allows you to chose how your drives will be used for FreeBSD. <item>Next, with the `Label' editor, you can specify how the space in any allocated FreeBSD partitions should be used by FreeBSD, or where to mount a non-FreeBSD partition (such as DOS). <item>Next, the `Distributions' menu allows you to specify which parts of FreeBSD you wish to load. A good choice is "User" for a small system or "Developer" for someone wanting a bit more out of FreeBSD. If none of the existing collections sound applicable, select Custom. <item>Next, the `Media' menu allows you to specify what kind of media you wish to install from. If a desired media choice is found and configured automatically then this menu will simply return, otherwise you'll be asked for additional details on the media device type. <item>Finally, the Commit command will actually perform all the actions at once (nothing has been written to your disk so far, nor will it until you give the final confirmation). All new or changed partition information will be written out, file systems will be created and/or non-destructively labelled (depending on how you set their newfs flags in the Label editor) and all selected distributions will be extracted. <item>The Configure menu choice allows you to furthur configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM/Tape/Floppy installation and have not yet configured your network interfaces (assuming you have some). Properly configuring your network here will allow FreeBSD to come up on the network when you first reboot from the hard disk. <item>Exit returns you to the top menu. </enum> At this point, you're generally done with the sysinstall utility and can select the final `Quit'. If you're running it as an installer (e.g. before the system is all the way up) then the system will now reboot. If you selected the boot manager option, you will see a small boot menu with an `F?' prompt. Press the function key for BSD (it will be shown) and you should boot up into FreeBSD off the hard disk. If this fails to happen for some reason, see the Q&A section of the Hardware Guide for possible clues! diff --git a/handbook/memoryuse.sgml b/handbook/memoryuse.sgml index 6f38acf1ce..42aa2f7679 100644 --- a/handbook/memoryuse.sgml +++ b/handbook/memoryuse.sgml @@ -1,55 +1,55 @@ -<!-- $Id: memoryuse.sgml,v 1.2 1995-06-30 17:37:42 jfieber Exp $ --> +<!-- $Id: memoryuse.sgml,v 1.3 1995-09-25 04:53:33 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> -<chapt><heading>PC memory utilization<label id="memoryuse"></heading> +<sect><heading>PC memory utilization<label id="memoryuse"></heading> <p><em>Contributed by &a.joerg;.<newline> 16 Apr 1995.</em> <bf>Question:</bf> <em>By the way, I have seen no description of how FreeBSD uses PC memory, ie what 0-640K gets used for, does the kernel load there or higher, is the kernel relocated, etc. Is there a paper on this?</em> The boot sector will be loaded at 0:0x7c00, and relocates itself immediately to 0x7c0:0. (This is nothing magic, just an adjustment for the %cs selector, done by an ljmp.) It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the biosboot Makefile), and sets up the stack to work below 0x1fff0. After this, it jumps to the entry of boot2 within that code. I.e., it jumps over itself and the (dummy) partition table, and it's going to adjust the %cs selector---we are still in 16-bit mode there. boot2 asks for the boot file, and examines the a.out header. It masks the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the file there. Hence the usual load point is 1 MB (0x00100000). During load, the boot code toggles back and forth between real and protected mode, to use the BIOS in real mode. The boot code itself uses segment selectors 0x18 and 0x20 for %cs and %ds/%es in protected mode, and 0x28 to jump back into real mode. The kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which refer to dummy descriptors covering the whole address space. The kernel will be started at its load point. Since it's been linked for another (high) address, it will have to execute PIC until the page table and page directory stuff is setup properly, at which point paging will be enabled and the kernel will finally run at the address for which it was linked. The kernel still skips over the first 0x500 bytes of code, in the assumption this were valuable BIOS data space (back from old days where it has been loaded low). <em>Contributed by &a.davidg;.<newline> 16 Apr 1995.</em> The physical pages immediately following the kernel BSS contain proc0's page directory, page tables, and upages. Some time later when the VM system is initialized, the physical memory between 0x1000-0x9ffff and the physical memory after the kernel (text+data+bss+proc0 stuff+other misc) is made available in the form of general VM pages and added to the global free page list. diff --git a/handbook/sections.sgml b/handbook/sections.sgml index a5f50d4078..60e0580349 100644 --- a/handbook/sections.sgml +++ b/handbook/sections.sgml @@ -1,38 +1,41 @@ -<!-- $Id: sections.sgml,v 1.1 1995-09-03 21:12:29 jfieber Exp $ --> +<!-- $Id: sections.sgml,v 1.2 1995-09-25 04:53:33 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- Entities containing all the pieces of the handbook are --> <!-- defined here --> <!ENTITY bibliography SYSTEM "bibliography.sgml"> <!ENTITY basics SYSTEM "basics.sgml"> <!ENTITY booting SYSTEM "booting.sgml"> <!ENTITY contrib SYSTEM "contrib.sgml"> <!ENTITY ctm SYSTEM "ctm.sgml"> <!ENTITY current SYSTEM "current.sgml"> +<!ENTITY crypt SYSTEM "crypt.sgml"> <!ENTITY dialup SYSTEM "dialup.sgml"> <!ENTITY diskless SYSTEM "diskless.sgml"> +<!ENTITY dma SYSTEM "dma.sgml"> <!ENTITY eresources SYSTEM "eresources.sgml"> +<!ENTITY esdi SYSTEM "esdi.sgml"> <!ENTITY glossary SYSTEM "glossary.sgml"> <!ENTITY history SYSTEM "history.sgml"> <!ENTITY hw SYSTEM "hw.sgml"> <!ENTITY install SYSTEM "install.sgml"> <!ENTITY kerberos SYSTEM "kerberos.sgml"> <!ENTITY kernelconfig SYSTEM "kernelconfig.sgml"> <!ENTITY kerneldebug SYSTEM "kerneldebug.sgml"> <!ENTITY memoryuse SYSTEM "memoryuse.sgml"> <!ENTITY mirrors SYSTEM "mirrors.sgml"> <!ENTITY nfs SYSTEM "nfs.sgml"> <!ENTITY nutshell SYSTEM "nutshell.sgml"> <!ENTITY porting SYSTEM "porting.sgml"> <!ENTITY ports SYSTEM "ports.sgml"> <!ENTITY ppp SYSTEM "ppp.sgml"> <!ENTITY relnotes SYSTEM "relnotes.sgml"> <!ENTITY scsi SYSTEM "scsi.sgml"> <!ENTITY slipc SYSTEM "slipc.sgml"> <!ENTITY slips SYSTEM "slips.sgml"> <!ENTITY submitters SYSTEM "submitters.sgml"> <!ENTITY sup SYSTEM "sup.sgml"> <!ENTITY troubleshooting SYSTEM "troubleshooting.sgml"> <!ENTITY userppp SYSTEM "userppp.sgml">