OpenBSD Documentation and Frequently Asked Questions --------------------------------------------------------------------------- This FAQ is supplemental documentation to the man pages, available both in the installed system and online. The FAQ covers the active release of OpenBSD, currently v3.2. Note that the development version (-current) of OpenBSD is not covered by this FAQ. The FAQ is available in PDF and plain text form in the pub/OpenBSD/doc directory from the FTP mirrors. --------------------------------------------------------------------------- 1 - Introduction to OpenBSD * 1.1 - What is OpenBSD? * 1.2 - On what systems does OpenBSD run? * 1.3 - Is OpenBSD really free? * 1.4 - Why might I want to use OpenBSD? * 1.5 - How can I help support OpenBSD? * 1.6 - Who maintains OpenBSD? * 1.7 - When will be the next release of OpenBSD? 2 - Other OpenBSD Information Resources * 2.1 - Web Pages * 2.2 - Mailing Lists * 2.3 - Manual Pages * 2.4 - Reporting Bugs 3 - Obtaining OpenBSD * 3.1 - Buying an OpenBSD CD * 3.2 - Buying OpenBSD T-Shirts * 3.3 - Does OpenBSD provide an ISO image for download? * 3.4 - Downloading via FTP or AFS * 3.5 - Obtaining Current Source Code 4 - OpenBSD 3.2 Installation Guide * 4.1 - Overview of the OpenBSD Installation Procedure. * 4.2 - Preinstallation Checklist * 4.3 - Doing an Install * 4.4 - What files are needed for Installation? * 4.5 - How much space do I need for an OpenBSD installation? * 4.6 - Multibooting OpenBSD * 4.7 - Sending your dmesg to dmesg@openbsd.org after the install * 4.8 - Adding a file set after install * 4.9 - What is 'bsd.rd'? * 4.10 - Common Installation Problems * 4.11 - Customizing the Install Process * 4.12 - How can I load a number of similar systems? * 4.13 - How can I get a dmesg(8) to report an install problem? 5 - Building the System from Source * 5.1 - OpenBSD Flavors * 5.2 - Why do I need a custom kernel? * 5.3 - Kernel configuration Options * 5.4 - Building your own kernel * 5.5 - Boot-time configuration * 5.6 - Getting more verbose output during boot * 5.7 - Using config(8) to change your kernel binary 6 - Networking * 6.0.1 - Before we go any further * 6.1 - Initial network setup * 6.2 - Packet Filter (PF) * 6.3 - Network Address Translation * 6.4 - Dynamic Host Configuration Protocol * 6.5 - Point to Point Protocol * 6.6 - Tuning networking parameters * 6.7 - Using NFS * 6.8 - Domain Name Service - DNS, BIND, and named * 6.9 - Setting up a PPTP connection in OpenBSD * 6.10 - Setting up a bridge with OpenBSD 7 - Keyboard and Display Controls * 7.1 - How do I remap the keyboard? (wscons) * 7.2 - Is there gpm or the like in OpenBSD? * 7.3 - How do I clear the console each time a user logs out? * 7.4 - Accessing the console scrollback buffer. (alpha/macppc/i386) * 7.5 - How do I switch consoles? (i386) * 7.6 - How can I use a console resolution of 80x50? (i386) * 7.7 - How do I use a serial console? * 7.8 - How do I blank my console? (wscons) 8 - General Questions * 8.2 - How do I change virtual terminals? (i386 ONLY) * 8.3 - I forgot my root password... What do I do! * 8.4 - X won't start, I get lots of error messages * 8.5 - What is CVS, and how do I use it? * 8.6 - What is the ports tree? * 8.7 - What are packages? * 8.8 - Is there any way to use my floppy drive if it's not attached during boot? * 8.9 - OpenBSD Bootloader (i386 specific) * 8.10 - Using S/Key on your OpenBSD system * 8.11 - Why is my Macintosh losing so much time? * 8.12 - Does OpenBSD support SMP? * 8.13 - I sometimes get Input/output error when trying to use my tty devices * 8.14 - What web browsers are available for OpenBSD? * 8.15 - How do I use the mg editor? * 8.16 - Ksh does not appear to read my .profile! * 8.17 - Why does my /etc/motd file get written over when I modified it? * 8.18 - Why does www.openbsd.org run on Solaris? * 8.19 - I'm having problems with PCI devices being detected * 8.20 - Antialiased and TrueType fonts in OpenBSD 2.9/XFree86 * 8.21 - Does OpenBSD support any journaling filesystems? * 8.22 - Reverse DNS or Why is it taking so long for me to log in? * 8.23 - Why do the OpenBSD web pages not conform to HTML4/XHTML? * 8.24 - Why is my clock off by twenty-some seconds? 9 - Migrating from Linux * 9.1 - Tips for Linux (and other free Unix-like OS) users * 9.2 - Dual boot of Linux and OpenBSD * 9.3 - Converting your Linux (or other System-7 style) password file to BSD-style. * 9.4 - Getting OpenBSD and Linux to interact 10 - System Management * 10.1 - When I try to su to root it says that I'm in the wrong group * 10.2 - How do I duplicate a filesystem? * 10.3 - How do I start daemons with the system? (Overview of rc(8)) * 10.4 - Why do users get relaying access denied when they are remotely sending mail through my OpenBSD system? * 10.5 - I've set up POP, but I get errors when accessing my mail through POP. What can i do? * 10.6 - Why does Sendmail ignore /etc/hosts file? * 10.7 - Setting up a Secure HTTP Server using SSL(8) * 10.8 - I made changes to /etc/passwd with vi(1), but the changes didn't seem to take place. Why? * 10.9 - How do I add a user? or delete a user? * 10.10 - How do I create a ftp-only account? * 10.11 - Setting up user disk quotas * 10.12 - Setting up Kerberos Client/Server * 10.13 - Setting up an Anonymous FTP Server * 10.14 - Confining users to their home dir's in ftpd(8). * 10.15 - Applying patches in OpenBSD. * 10.16 - Tell me about chroot() Apache? * 10.17 - I don't like the standard root shell! * 10.18 - What else can I do with ksh? 11 - Performance Tuning * 11.1 - Networking * 11.2 - Disk I/O * 11.4 - Hardware Choices * 11.5 - Why aren't we using async mounts? * 11.6 - Tuning your monitor resolution under XFree86 12 - For Advanced Users * 12.1 - Forcing DMA access for IDE disks * 12.2 - Upgrading from various versions of OpenBSD via CVS. 13 - Using IPsec (IP Security Protocol) * 13.1 - What is IPsec? * 13.2 - That's nice, but why do I want to use IPsec? * 13.3 - What are the protocols behind IPsec? * 13.4 - On the wire format * 13.5 - Configuring IPsec * 13.6 - How do I set up IPsec with manual keying? * 13.7 - How do I set up isakmpd? * 13.8 - How do I use isakmpd with X.509 certificates? * 13.9 - What IKE clients are compatible with isakmpd? * 13.10 - Troubleshooting IPsec/VPN * 13.11 - Related Documentation 14 - Disk Setup * 14.1 - Using OpenBSD's disklabel * 14.2 - Using OpenBSD's fdisk * 14.3 - Adding extra disks in OpenBSD * 14.4 - How to swap to a file * 14.5 - Soft Updates * 14.6 - When I boot after installation of OpenBSD/i386, it stops at "Using Drive: 0 Partition 3". * 14.7 - What are the issues regarding large drives with OpenBSD? -i386 specific * 14.8 - Installing Bootblocks - i386 specific * 14.9 - Preparing for disaster: Backing up and Restoring from tape. * 14.10 - Mounting disk images in OpenBSD * 14.11 - Help! I'm getting errors with PCIIDE! * 14.12 - Forcing DMA access for IDE disks * 14.13 - RAID options with OpenBSD --------------------------------------------------------------------------- Commonly Encountered Issues * Tell me about chroot() Apache? * How do I upgrade my system? * How do I update my system? and here * RAID Options. * Packet Filter and NAT. * How do I set up a multi-boot system? * Issues with Large Drives and OpenBSD * How do I blank my console? --------------------------------------------------------------------------- Recent Updates * FAQ 4, How can I get a dmesg(8) to report an install problem? * FAQ 4 Customizing the Install Process * FAQ 4, How can I load a number of similar systems? * FAQ 10, I don't like the standard root shell! * FAQ 10, What else can I do with ksh? * FAQ 4, Common Installation Problems * FAQ 7, How do I blank my console? --------------------------------------------------------------------------- The FAQ maintainers are: Nick Holland, Eric Jackson, Wim Vandeputte and Chris Cappuccio. For information about and assisting in the translation of this FAQ and the rest of the OpenBSD website, see the translation page. Questions and comments regarding the FAQ may be directed to faq@openbsd.org. General questions about OpenBSD should be directed to the appropriate mail list. OpenBSD FAQ Copyright © 1998-2003 OpenBSD $OpenBSD: index.html,v 1.166 2003/03/17 19:22:51 nick Exp $ "If you don't find it in the index, look very carefully through the entire catalogue." Sears, Roebuck, and Co., Consumer's Guide, 1897 ============================================================================== 1 - Introduction to OpenBSD ------------------------------------------------------------------------------ Table of Contents * 1.1 - What is OpenBSD? * 1.2 - On what systems does OpenBSD run? * 1.3 - Is OpenBSD really free? * 1.4 - Why might I want to use OpenBSD? * 1.5 - How can I help support OpenBSD? * 1.6 - Who maintains OpenBSD? * 1.7 - When will be the next release of OpenBSD? ------------------------------------------------------------------------------ 1.1 - What is OpenBSD? The OpenBSD project produces a freely available, multi-platform 4.4BSD-based UNIX-like operating system. Our goals place emphasis on correctness, security, standardization, and portability. OpenBSD supports binary emulation of most binaries from SVR4 (Solaris), FreeBSD, Linux, BSDI, SunOS, and HPUX. 1.2 - On what systems does OpenBSD run? OpenBSD 3.2 runs on the following platforms: * i386 - CD bootable * sparc - CD bootable * sparc64 - CD bootable * hp300 - CD bootable * amiga * mac68k * macppc - CD bootable * mvme68k * alpha - CD bootable * vax bootable means that OpenBSD will boot directly from the CD. The CD set will boot on several hardware platforms. See chapter 3 of this FAQ for details of obtaining OpenBSD on CD. Previous releases of OpenBSD also had a port for: * sun3 - This port was removed after the 2.9 release * arc - This port was removed after the 2.3 release * mvme88k * pmax If you are interested in multiprocessor support, see FAQ 8, Multiprocessor for more info. 1.3 - Is OpenBSD really free? OpenBSD is all free. The binaries are free. The source is free. All parts of OpenBSD have reasonable copyright terms permitting free redistribution. This includes the ability to REUSE most parts of the OpenBSD source tree, either for personal or commercial purposes. OpenBSD includes NO further restrictions other than those implied by the original BSD license. Software which is written under stricter licenses cannot be included in the regular distribution of OpenBSD. This is intended to safeguard the free use of OpenBSD. For example, OpenBSD can be freely used for personal use, for academic use, by government institutions, by non-profit making organizations and by commercial organizations. For further reading on other popular licenses read: http://www.openbsd.org/ policy.html. The maintainers of OpenBSD support the project largely from their own pockets. This includes the time spent programming for the project, equipment used to support the many ports, the network resources used to distribute OpenBSD to you, and the time spent answering questions and investigating users' bug reports. The OpenBSD developers are not independently wealthy and even small contributions of time, equipment, and resources make a big difference. 1.4 - Why might I want to use OpenBSD? New users frequently want to know whether OpenBSD is superior to some other free UNIX-like operating system. That question is largely un-answerable and is the subject of countless (and useless) religious debates. Do not, under any circumstances, ask such a question on an OpenBSD mailing list. Below are some reasons why we think OpenBSD is a useful operating system. Whether OpenBSD is right for you is a question that only you can answer. * OpenBSD runs on many different hardware platforms. * OpenBSD is thought of by many security professionals to be the most secure UNIX-like operating system as the result of a 10-member 1.5-year long comprehensive source code security audit. * OpenBSD is a full-featured UNIX-like operating system available in source form at no charge. * OpenBSD integrates cutting-edge security technology suitable for building firewalls and private network services in a distributed environment. * OpenBSD benefits from strong ongoing development in many areas, offering opportunities to work with emerging technologies with an international community of programmers and end-users. * OpenBSD offers opportunities for ordinary people to participate in the development and testing of the product. 1.5 - How can I help support OpenBSD? We are greatly indebted to the people and organizations that have contributed to the OpenBSD project. They are acknowledged by name on the donations page. OpenBSD has a constant need for several types of support from the user community. If you find OpenBSD useful, you are strongly encouraged to find a way to contribute. If none of the suggestions below are right for you, feel free to propose an alternative by sending e-mail to donations@openbsd.org. * Buy an OpenBSD CD set. It includes the current full release of OpenBSD, and is bootable on many platforms. It also generates revenue to support the OpenBSD project, and reduces the strain on network resources used to deliver the distribution via the Internet. This inexpensive three-CD set includes full source. Remember, your friends need their own copy! * Donate money. The project has a constant need for cash to pay for equipment, network connectivity, and expenses relating to CD publishing. Manufacturing CDs requires an up-front out-of-pocket investment for the OpenBSD developers, without guaranteed return. Send e-mail to donations@openbsd.org to find out how to contribute. Even small donations make a profound difference. * Donate equipment and parts. The project has a constant need for general and specific hardware. Items such as IDE and SCSI disks, and various types of RAM are always welcome. For other types of hardware such as computer systems and motherboards, you should inquire as to current need. Write to donations@openbsd.org to arrange for shipment. * Donate your time and skills. Programmers who enjoy writing operating systems are naturally always welcome, but there are literally dozens of other ways that people can be useful. Follow mailing lists and help answer new-user questions. * Help maintain documentation by submitting new FAQ material (to faq@openbsd.org). Form a local user group and get your friends hooked on OpenBSD. Make a case to your employer for using OpenBSD at work. If you're a student, talk to your professors about using OpenBSD as a learning tool for Computer Science or Engineering courses. It's also worth mentioning one of the most important ways you should not try to "help" the OpenBSD project: do not waste your time engaging in operating system flame wars. It does not help the project to find new users and can cause substantial harm to important relationships that developers have with other developers. 1.6 - Who maintains OpenBSD? OpenBSD is maintained by a development team spread across many different countries. The project is coordinated by Theo de Raadt, located in Canada. 1.7 - When will be the next release of OpenBSD? The OpenBSD team makes a new release every six months, with target release dates of May 1 and November 1. More information on the development cycle can be found here. ------------------------------------------------------------------------------ $OpenBSD: faq1.html,v 1.45 2003/03/18 03:41:04 nick Exp $ ============================================================================== 2 - Other OpenBSD Information Resources ------------------------------------------------------------------------------ Table of Contents * 2.1 - Web Pages * 2.2 - Mailing Lists * 2.3 - Manual Pages * 2.4 - Reporting Bugs ------------------------------------------------------------------------------ 2.1 - Web Pages of Interest The official website for the OpenBSD project is located at: http:// www.OpenBSD.org. A lot of valuable information can be found here regarding all aspects of the OpenBSD project. Additional information for laptop users can be found at: http://www.monkey.org/openbsd-mobile/. 2.2 - Mailing Lists The OpenBSD project maintains several popular mailing lists which users should subscribe to and follow. To subscribe to a mailing list, send an e-mail message to majordomo@openbsd.org. That address is an automated subscription service. In the body of your message, on a single line, you should include a subscribe command for the list you wish to join. For example: subscribe announce The list processor will reply to you, asking for confirmation of your intent to join the list. The confirmation you send back to the list processor will be included in its reply to you. You get an option of a hypertext link or sending a reply to the message to confirm your intent. An email reply should contain something like this: accept A56D-70D4-52C3 Once you have confirmed your intent to join, you will be immediately added to the list, and the list processor will notify you that you were successfully added. To unsubscribe from a list, you will again send an e-mail message to majordomo@openbsd.org. It might look like this: unsubscribe announce If you have any difficulties with the mailing list system, please first read the instructions. They can be obtained by sending an e-mail message to majordomo@openbsd.org with a message body of "help". Some of the most popular OpenBSD mailing lists are: * announce - Important announcements. This is a low-volume list. * security-announce - Announcements of security issues. * misc - General user questions and answers. This is the most active list, and should be the "default" for most questions. * tech - Technical topics for OpenBSD developers and advanced users. Please direct 'new user' and installation-related questions to misc, not tech. Please do not cross-post to misc and tech. * bugs - Bugs received via sendbug(1) and discussions about them. * source-changes - Automated mailing of CVS source tree changes. * ports - Discussion of the OpenBSD Ports Tree. * ports-changes - Automated mailing of ports-specific CVS source tree changes. * advocacy - Discussion on advocating OpenBSD. Before posting a question on misc or any other mail list, please check the archives, for most common questions have been asked repeatedly. While it might be the first time you have encountered the problem or question, others on the mail lists may have seen the same question several times in the last week, and may not appreciate seeing it again. You can find several archives and other mail list guidelines on the mailing lists web page: http://www.openbsd.org/ mail.html. Another mailing list that may be of interest is openbsd-mobile@monkey.org. This mailing list is a discussion of the use of OpenBSD in mobile computing. To subscribe to this list use: 'echo subscribe | mail "openbsd-mobile-request@monkey.org"' The archives for that can be found at: http://www.monkey.org/openbsd-mobile/ archive/. 2.3 - Manual Pages OpenBSD comes with extensive documentation in the form of manual pages, as well as longer documents relating to specific applications. To access the manual pages and other documentation, be sure that you installed the man and misc sets. Here is a list of some of the most useful manual pages for new users: * help(1) - help for new users and administrators. * afterboot(8) - things to check after the first complete boot. * boot(8) - system bootstrapping procedures. * login.conf(5) - format of the login class configuration file. * adduser(8) - command for adding new users. * vipw(8) - edit the master password file. * man(1) - display the on-line manual pages. * sendbug(1) - send a problem report (PR) about OpenBSD to a central support site. * disklabel(8) - Read and write disk pack label. * ifconfig(8) - configure network interface parameters. * route(8) - manually manipulate the routing tables. * netstat(1) - show network status. * reboot, halt(8) - Stop and restart the system. * shutdown(8) - close down the system at a given time. * boot_config(8) - how to change kernel configuration at boot. You can find all the OpenBSD man pages on the web at http://www.openbsd.org/ cgi-bin/man.cgi as well as on your computer if you install the man32.tgz file set. In general, if you know the name of a command or a manual page, you can read it by executing `man command'. For example: `man vi' to read about the vi editor. If you don't know the name of the command, or if `man command' doesn't find the manual page, you can search the manual page database by executing `apropos something' or `man -k something' where something is a likely word that might appear in the title of the manual page you're looking for. For example: # apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler The parenthetical numbers indicate the section of the manual in which that page can be found. In some cases, you may find manual pages with identical names living in separate sections of the manual. For example, assume that you want to know the format of the configuration files for the cron daemon. Once you know the section of the manual for the page you want, you would execute `man n command' where n is the manual section number. # man -k cron cron (8) - daemon to execute scheduled commands (Vixie Cron) crontab (1) - maintain crontab files for individual users (V3) crontab (5) - tables for driving cron # man 5 crontab In addition to the UNIX manual pages, there is a typesettable document set (included in the misc distribution). It lives in the /usr/share/doc directory. If you also installed the text distribution, then you can format each document set with a `make' in the appropriate subdirectory. The psd subdirectory is the Programmer's Supplementary Documents distribution. The smm subdirectory is the System Manager's Manual. The usd subdirectory is the UNIX User's Supplementary Documents distribution. You can perform your `make' in the three distribution subdirectories, or you can select a specific section of a distribution and do a `make' in its subdirectory. Some of the subdirectories are empty. By default, formatting the documents will result in Postscript output, suitable for printing. The Postscript output can be quite large -- you should assume 250-300% increase in volume. If you do not have access to a Postscript printer or display, you may also format the documents for reading on a terminal display. In each Makefile you'll need to add the flag -Tascii to each instance of the groff(1) commands (or execute it by hand). Some of the documents use the ms formatting macros, and some use the me macros. The Makefile in each document subdirectory (eg, /usr/share/doc/usd/04.csh/Makefile) will tell you which one to use. For example: # cd /usr/share/doc/usd/04.csh # groff -Tascii -ms tabs csh.1 csh.2 csh.3 csh.4 csh.a csh.g > csh.txt # more csh.txt The UNIX manual pages are generally more current and trustworthy than the typesettable documents. The typesettable documents sometimes explain complicated applications in more detail than the manual pages do. For many, having a hardcopy of the man page can be useful. Here are the guidelines to making a printable copy of a man page. How do I display a man page source file? (i.e. one whose filename ends in a number, like tcpdump.8). This is found throughout the src tree. The man pages are found in the tree unformatted, and many times through the use of CVS, they will be updated. To view these pages simply : # nroff -mdoc | more How do I get a plain man page with no formatting or control characters? This is helpful to get the man page straight, with no non-printable characters. Example: # man | col -b How can I get a PostScript copy of a man page that's print-ready? Note that [man_src_file] must be the man page source file (probably a file that ends in a number; e.g., tcpdump.8). The PostScript versions of the man pages look very nice. They can be printed or viewed on-screen with a program like gv (GhostView). GhostView can be found in our Ports Tree. Use the following groff(1) command options for getting a PostScript version from an OpenBSD system man page: # groff -mdoc -Tps [man_src_file] > outfile.ps The above command line will only work for man pages formatted with the mdoc(7) macro package, used to format the BSD man pages. For getting a PostScript version from a third party software man page (either self-compiled or installed from the ports(7) or the packages(7)), do instead: # groff -Tps -mandoc [man_src_file] > outfile.ps 2.4 - Reporting Bugs Before submitting any bug report, please read http://www.openbsd.org/ report.html. Proper bug reporting is one of the most important responsibilities of end users. Very detailed information is required to diagnose most serious bugs. Developers frequently get bugs reports via e-mail such as this: From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!! Hopefully most people understand why such reports get summarily deleted. All bug reports should contain detailed information. If Joe User had really expected someone to help find this bug, he or she would have supplied more information... something like this: (Note: See report.html for more information on creating and submitting bug reports. Basically, detailed information about your hardware is necessary if you think the bug is in any way related to your hardware or hardware configuration. Usually, dmesg(8) output is sufficient in this respect. Next, a detailed description of your problem is necessary.) From: smartuser@example.com To: bugs@openbsd.org Subject: 2.7 panics on an i386 After installing OpenBSD 2.7 from the CD which I purchased via your outstanding on-line ordering system, I find that the system halts when using any network utilities. After booting with a bootdisk and escaping to a shell. This is the dmesg output: OpenBSD 2.7 (GENERIC) #690: Fri Oct 29 16:32:17 MDT 1999 deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: F00F bug workaround installed cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 120 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8 BIOS mem = 654336 conventional, 15728640 extended real mem = 16384000 avail mem = 11112448 using 225 buffers containing 921600 bytes of memory mainbus0 (root) bios0 at mainbus0: AT/286+(63) BIOS, date 08/20/96 bios0: diskinfo 0xe055800c cksumlen 1 memmap 0xe0558088 apminfo 0xe0558134 apm0 at bios0: Power Management spec V1.1 apm0: battery life expectancy 95% apm0: AC on, battery charge high, charging, estimated 1:27 minutes pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 "Toshiba (2nd ID) Host-PCI" rev 0x11 "Chips and Technologies 65550" rev 0x04 at pci0 dev 4 function 0 not configured isa0 at mainbus0 isadma0 at isa0 wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: wd0: can use 16-bit, PIO mode 4 wd0: 16-sector PIO, LBA, 1296MB, 2633 cyl, 16 head, 63 sec, 2654280 sectors sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v3.02 midi0 at sb0: audio0 at sb0 opl0 at sb0: model OPL3 midi1 at opl0: wss0 at isa0 port 0x530/8 irq 10 drq 0: CS4232 (vers 63) audio1 at wss0 pcppi0 at isa0 port 0x61 midi2 at pcppi0: sysbeep0 at pcppi0 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pccom2: irq 5 already in use vt0 at isa0 port 0x60/16 irq 1: generic VGA, 80 col, color, 8 scr, mf2-kbd pms0 at vt0 irq 12 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec pcic0 at isa0 port 0x3e0/2 iomem 0xd0000/16384 pcic0 controller 0: has sockets A and B pcmcia0 at pcic0 controller 0 socket 0 pcmcia1 at pcic0 controller 0 socket 1 ne3 at pcmcia1 function 0 "Linksys, EtherFast 10/100 PC Card (PCMPC100), " port 0x340/16 irq 9 ne3: address 00:e0:98:04:95:ba pcic0: irq 11 biomask 4040 netmask 4240 ttymask 5a42 pctr: 586-class performance counters and user-level cycle counter enabled dkcsum: wd0 matched BIOS disk 80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 Thank you! If Smart User had a working OpenBSD system from which he wanted to submit a bug report, he would have used the sendbug(1) utility to submit his bug report to the GNATS problem tracking system. Obviously you can't use sendbug(1) when your system won't boot, but you should use it whenever possible. You will still need to include detailed information about what happened, the exact configuration of your system, and how to reproduce the problem. The sendbug(1) command requires that your system be able to send electronic mail successfully on the Internet. After submitting a bug report, you will be notified by E-mail about the status of the report. You may be contacted by developers for additional information or with patches that need testing. You can also monitor the archives of the bugs@openbsd.org mail list, details on the mail list page, or query the bug report database status at the on-line Bug Tracking System. ------------------------------------------------------------------------------ $OpenBSD: faq2.html,v 1.58 2003/03/18 03:41:04 nick Exp $ ============================================================================== 3 - Obtaining OpenBSD ------------------------------------------------------------------------------ Table of Contents * 3.1 - Buying an OpenBSD CD * 3.2 - Buying OpenBSD T-Shirts * 3.3 - Does OpenBSD provide an ISO image for download? * 3.4 - Downloading via FTP or AFS * 3.5 - Obtaining Current Source Code ------------------------------------------------------------------------------ 3.1 - Buying an OpenBSD CD Purchasing an OpenBSD CD is generally the best way to get started. Visit the ordering page to purchase your copy: http://www.openbsd.org/orders.html. There are many good reasons to own an OpenBSD CD: * CD sales support ongoing development of OpenBSD. * Development of a multi-platform operating system requires constant investment in equipment. * Your support in the form of a CD purchase has a real impact on future development. * The CD contains binaries (and source) for all supported platforms. * The CD is bootable on several platforms, and can be used to bootstrap a machine without a pre-existing installed operating system. * The CD is useful for bootstrapping even if you choose to install a snapshot. * Installing from CD is faster! Installing from CD preserves network connectivity resources. * OpenBSD CDs always come with very nice stickers. Your system isn't fully complete without these. You can only get these stickers by buying a CD set or donating hardware. If you're installing a release version of OpenBSD, you should use a CD. 3.2 - Buying OpenBSD T-Shirts Yes, OpenBSD has t-shirts for your wearing enjoyment. You can view these at http://www.OpenBSD.org/tshirts.html. Enjoy :) 3.3 - Does OpenBSD provide an ISO image for download? The OpenBSD project does not make the ISO images used to master the official CDs available for download. The reason is simply that we would like you to buy the CD sets, helping fund ongoing OpenBSD development. The official OpenBSD CD-ROM layout is copyright Theo de Raadt. Theo does not permit people to redistribute images of the official OpenBSD CDs. As an incentive for people to buy the CD set, some extras are included in the package as well (artwork, stickers etc). Note that only the CD layout is copyrighted, OpenBSD itself is free. Nothing precludes someone else from downloading OpenBSD and making their own CD. If for some reason you want to download a CD image, try searching the mailing list archives for possible sources. Of course, any OpenBSD ISO images available on the Internet either violate Theo de Raadt's copyright or are not official images. The source of an unofficial image may or may not be trustworthy; it is up to you to determine this for yourself. We suggest that people who want to download OpenBSD for free use the FTP install option. 3.4 - Downloading via FTP or AFS There are numerous international mirror sites offering FTP access to OpenBSD releases and snapshots. AFS access is also available. You should always use the site closest to you. Before you begin fetching a release or snapshot, you may wish to use ping(8) and traceroute(8) to determine which mirror site is nearest to you and whether that nearest mirror is performing adequately. Of course, your OpenBSD release CD is always closer than any mirror. Access information is here: http://www.openbsd.org/ftp.html. 3.5 - Obtaining Current Source Code Source to OpenBSD is freely redistributable and available at no charge. Generally the best way to get started with a current source tree is to install the source from the most recent CD and then configure AnonCVS to update it regularly. Information about AnonCVS, including how to set it up, is available here: http://www.openbsd.org/anoncvs.html. or see FAQ 8, CVS If you don't have sufficient network bandwidth to support AnonCVS, or if your Internet access is via UUCP, you can still keep your source current by using CTM instead of AnonCVS. If that's your situation, then starting with a recent release CD is even more important. Information about CTM, including how to set it up, is available here: http://www.openbsd.org/ctm.html. Yet another alternative is to get the source code from the web. You can do that through cvsweb at: http://www.openbsd.org/cgi-bin/cvsweb/. ------------------------------------------------------------------------------ $OpenBSD: faq3.html,v 1.37 2003/03/18 03:41:04 nick Exp $ ============================================================================== 4 - OpenBSD 3.2 Installation Guide ------------------------------------------------------------------------------ Table of Contents * 4.1 - Overview of the OpenBSD Installation Procedure. + 4.1.1 - Supported OpenBSD Architectures + 4.1.2 - Supported Installation Media + 4.1.3 - Creating bootable OpenBSD install floppies o 4.1.3.1 - Creating Floppies on Unix o 4.1.3.2 - Creating Floppies on DOS/Windows + 4.1.4 - Booting OpenBSD Installation Images * 4.2 - Preinstallation Checklist * 4.3 - Doing an install + 4.3.1 - Setting up Disks + 4.3.2 - Setting the System Hostname + 4.3.3 - Configuring the Network + 4.3.4 - Choosing Installation Media + 4.3.5 - Choosing Filesets + 4.3.6 - Small RAM procedure + 4.3.7 - Finishing up + 4.3.8 - Other Information Resources * 4.4 - What files are needed for Installation? * 4.5 - How much space do I need for an OpenBSD installation? * 4.6 - Multibooting OpenBSD * 4.7 - Sending your dmesg to dmesg@openbsd.org after the install * 4.8 - Adding a file set after install * 4.9 - What is 'bsd.rd'? * 4.10 - Common Installation Problems + 4.10.1 - Install hangs during MAKEDEV + 4.10.2 - My Compaq only recognizes 16M RAM + 4.10.3 - My i386 won't boot after install + 4.10.4 - My machine booted, but hung at the ssh-keygen process + 4.10.5 - I got the message "ftplist: No such file" when doing an install * 4.11 - Customizing the Install Process * 4.12 - How can I load a number of similar systems? * 4.13 - How can I get a dmesg(8) to report an install problem? ------------------------------------------------------------------------------ 4.1 - Overview of the OpenBSD installation procedure OpenBSD has a very robust and adaptable text-based install procedure. In addition to its robustness, the install procedure can be done using 1 floppy disk. Most architectures have a similar installation procedure, however there are some differences in details. In all cases, you are urged to read the platform-specific INSTALL document in the platform directory on the CDROM or FTP sites (for example, INSTALL.i386, INSTALL.mac68k or INSTALL.sparc). On most architectures, you have several installation options, including FTP, CDROM, and local disk files. One option not supported is downloading an ISO image to make your own official CDROM. CDROMs are available for purchase, however. 4.1.1 - Supported OpenBSD Architectures OpenBSD 3.2 supports a number of architectures listed below in alphabetical order. Please refer to each architecture's page for specific information on what each architecture supports. * alpha - DEC Alpha-based machines. * amiga - Amiga m68k-based models (MMU required). * hp300 - Hewlett-Packard HP300/HP400 machines. * i386 - Intel i386 compatibles. * mac68k - Most MC680x0-based Apple Macintosh models. * mvme68k - Motorola MVME147/16x/17x 68K VME cards. * macppc - Support for Apple based PowerPC systems. * sparc - SPARC Platform by Sun Microsystems. * sparc64 - Sun's UltraSPARC systems. * vax - DEC's VAX computers. 4.1.2 - Supported Installation Media OpenBSD can be installed from multiple media types. The most common and architecture independent options are laid out below. These options can be used after booting from an OpenBSD CD-ROM, floppy disk or ramdisk kernel. +-------------------------------------------------------------------------+ | |To do a CD-ROM install, you must have either purchased an | | |Official OpenBSD CD-ROM or created your own OpenBSD CD. This | |CD-ROM |is usually the easiest way to install an OpenBSD system. | | |NOTE: Official OpenBSD CDs are bootable if your BIOS supports | | |it. | |----------+--------------------------------------------------------------| | |This installation option allows you to install OpenBSD by | |FTP |downloading the installation packages in realtime over the | | |network. | |----------+--------------------------------------------------------------| |Local |This option allows you to install from files on a pre-existing| |Filesystem|filesystem. Support for DOS, EXT2FS and FFS are included on | | |the i386 install disk. | +-------------------------------------------------------------------------+ 4.1.3 - Creating bootable OpenBSD install floppies. To create an installation floppy image you must either download the correct boot floppy image from one of the OpenBSD distribution sites or copy the image from an Official OpenBSD CD-ROM. You can find a list of FTP servers at the OpenBSD FTP Distribution page. Most architectures have one or more boot floppy images to choose from, different images are for different hardware variations. The differences between the i386 platform installation floppies will be outlined below. For the other architectures with multiple boot floppies, see the INSTALL document in the respective FTP directory. For those with only one, just download the respective floppy32.fs image. NOTE: The cdrom32.fs image can be used to make a bootable OpenBSD installation CD-ROM. The i386 platform has four separate installation disk images to choose from: * floppy32.fs (Desktop PC) supports many PCI and ISA NICs, IDE and simple SCSI adapters and some PCMCIA support. * floppyB32.fs (Servers) supports many RAID controllers, and some of the less common SCSI adapters. However, support for many standard SCSI adapters and many EISA and ISA NICS has been removed. * floppyC32.fs (Laptops) supports the Cardbus and PCMCIA devices found in many laptops. * cdrom32.fs it is, in effect a combination of all three boot disks. It can be used to make a bootable 2.88M floppy, or more commonly, as a boot image for a recordable CD. Most i386 users will just use the floppy32.fs installation floppy. Yes, there may be situations where one install disk is required to support your SCSI adapter and another disk is required to support your network adapter. Fortunately, this is a rare event, and can usually be worked around. Once you have the correct floppy image, you need to get a clean floppy disk. If there are ANY bad sectors on the floppy disk, the installation will most likely fail. 4.1.3.1 - Creating floppies on Unix. To create a formatted floppy, use the fdformat(1) command to both format and check for bad sectors. # fdformat /dev/fd0a Format 1440K floppy `/dev/fd0a'? (y/n): y processing VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV done. If your output is like the above example, then your disk is OK. However, if you do not see ALL "V"'s then your disk is most likely bad, and you should try a new one. Once you have a clean, formatted floppy it is time to write the installation image to floppy. For this, you can use the dd(1) utility. An example usage of dd(1) is below: # dd if=floppy32.fs of=/dev/rfd0c bs=32k Once the image is written, check to make sure that the copied image is the same as the original with the cmp(1) command. If the diskette is identical to the image, you will just see another prompt. # cmp /dev/rfd0c floppy32.fs 4.1.3.2 - Creating floppies on DOS/Windows. If you are creating this image on the Windows/DOS platform you can get tools mentioned below from the tools directory on any of the ftp mirrors, or in 3.2/ tools directory on CD1 of the OpenBSD CD set. For users of DOS/Windows 9x, rawrite can be used to write your boot floppy. To prepare a floppy in MS-DOS or Windows, simply use the native formatting tools. To write the installation image to the prepared floppy you can use rawrite, fdimage, or ntrw. rawrite will not work on Windows NT, 2000 or XP. Note that FDIMAGE.EXE and RAWRITE.EXE are both MS-DOS applications, and thus, are limited to DOS's "8.3" file naming convention. As floppy32B.fs and floppy32C.fs have longer file name, you will have to find out how your system stored the file in "8.3 format" before using FDIMAGE.EXE or RAWRITE.EXE to make your boot floppies. Example usage of rawrite: C:\> rawrite RaWrite 1.2 - Write disk file to raw floppy diskette Enter source file name: floppy32.fs Enter destination drive: a Please insert a formatted diskette into drive A: and press -ENTER- : Enter Example Usage of fdimage: C:\> fdimage -q floppy32.fs a: Example Usage of ntrw: C:\> ntrw floppy32.fs a: 3.5", 1.44MB, 512 bytes/sector bufsize is 9216 1474560 bytes written 4.1.4 - Booting OpenBSD Installation Images. This section is initially broken down into architecture dependent sections for popular architectures that OpenBSD supports. This is so we can properly instruct each user on what to do on their respective platform. Booting i386 Booting an install image on the i386 architecture is nothing new to most people. If you are using the floppy disk, simply stick the floppy into your floppy drive and boot your system. Your install image will automatically load (assuming floppy boot is enabled in your BIOS). If you are planning on booting from CD, you must go into your systems BIOS and set the boot options to allow booting from CD. Some older BIOSs do not have this option, and you must use a floppy for booting your installation image. Don't worry though, even if you boot from floppy you can still install from the CD. Booting sparc NOTE: On the sparc64, only the sbus machines (Ultra 1, Ultra 2) are bootable from floppy. To boot from floppy, place your floppy disk with the OpenBSD installation image on it into your floppy drive. Then use the following command to boot from your floppy: ok boot floppy To boot from CD-ROM, place your OpenBSD CD-ROM disk into your drive. If your Sun only has one CD-ROM drive, then just go to the boot prompt, where you can 'boot cdrom': ok boot cdrom Of course, this will only work in new command mode. If you are at the old command mode prompt (a right arrow), type 'n' for the new command mode. (If you are using an old sparc that is pre-sun4c, you probably don't have a new command mode. In this case, you need to experiment.) If you have multiple CD-ROM devices, you need to boot from the correct one. Try probe-scsi from the new command mode. ok probe-scsi Target 0 Unit 0 Disk QUANTUM LIGHTNING 365S Target 1 Unit 0 Removable Disk QUANTUM EMPIRE_1080S Target 3 Unit 0 Removable Disk Joe's CD ROMs Figure out which disk is the CD ROM you want to boot from. Note the target number. ok boot /sbus/esp/sd@X,0 4.2 - Preinstallation Checklist Before you start your install, you should have some idea what you want to end up with. You will want to know the following items, at least: * Machine Name * Hardware installed and available + Verify compatibility with your platform's hardware compatibility page + If ISA, you also need to know hardware settings, and confirm they are as OpenBSD requires. * Install method to be used (CDROM, FTP, etc.) * Desired disk layout + Does existing data need to be saved elsewhere? + Will OpenBSD co-exist on this system with another OS? If so, how both will be booted? Will you need to install a "boot manager"? + Will the entire disk be used for OpenBSD, or will an existing (or future) partition have to be worked around? + How do you wish to sub-partition the OpenBSD part of your disk? * Network settings, if not using DHCP: + Domain Name + Domain Name Server(s) (DNS servers) + IP addresses and subnet masks for each NIC + Gateway address * Will you be running X on this system? 4.3 - Starting the Install Whatever your means of booting is, it is now time to use it. During the boot process, the kernel and all of the programs used to install OpenBSD are loaded into memory. The most common problem when booting is a bad floppy disk or a drive alignment problem. The boot floppy is quite tightly packed -- any bad spot will cause problems. When your boot is successful, you will see a lot of text messages scroll by. This text, on many architectures in white on blue, is the dmesg, the kernel telling you what devices have been found, and where. Don't worry about remembering this text, as a copy is saved as /var/run/dmesg.boot. On most architectures, SHIFT+PGUP will let you examine text that has scrolled off the screen. Then, you will see the following: rootdev=0x1100 rrootdev=0x2f00 rawdev=0x2f02 erase ^?, werase ^W, kill ^U, intr ^C, status ^T (I)nstall, (U)pgrade or (S)hell? i And with that, we reach our first question. Most of the time, you have the three options shown: * Install: load OpenBSD onto the system, overwriting whatever may have been there. Note that it is possible to leave some partitions untouched in this process, such as a /home, but otherwise, assume everything else is overwritten. * Upgrade: Install a new set of install files on this machine, but do not overwrite any configuration information, user data, or additional programs. No disk formatting is done, nor are the /etc or /var directories overwritten. You will not be given the option of installing the etc32.tgz file. After the install, you will have to manually merge the changes of etc32.tgz into your system before you can expect it to be fully functional. This is an important step which must be done, as otherwise certain key services (such as pf(4)) may not start. NOTE: The Upgrade process is not designed to skip releases! While this will often work, it is not supported. For OpenBSD 3.2, upgrading 3.1 to 3.2 is the only supported upgrade. If you have to upgrade from an older version, a complete reinstall is recommended. * Shell: Sometimes, you need to perform repairs or maintenance to a system which will not (or should not) boot to a normal kernel. This option will allow you to do maintenance to the system. On occasion, you will not see the "Upgrade" option listed. After a flag day event, it is not possible to directly upgrade, one must rebuild the system from scratch. An example of this in OpenBSD 3.2 is the Sparc platform, which switched executable formats from a.out to ELF, and so a user upgrading to 3.2 on their Sparc must completely reload their system. In this example, we will do an install, but the upgrade process is similar. Welcome to the OpenBSD/i386 3.2 install program. This program will help you install OpenBSD in a simple and rational way. At any prompt except password prompts you can run a shell command by typing '!foo', or escape to a shell by typing '!'. Default answers are shown in []'s and are selected by pressing RETURN. At any time you can exit this program by pressing Control-C and then RETURN, but quitting during an install can leave your system in an inconsistent state. Specify terminal type: [vt220] Do you wish to select a keyboard encoding table? [n] y In most cases, the default terminal type is appropriate, however if you are using a serial console for install, don't just take the default, respond appropriately. If you do not select a keyboard encoding table, a US keyboard layout will be assumed. IS YOUR DATA BACKED UP? As with anything that modifies disk contents, this program can cause SIGNIFICANT data loss. It is often helpful to have the installation notes handy. For complex disk configurations, relevant disk hardware manuals and a calculator are useful. Proceed with install? [n] y If you take the default here, the install process will terminate and drop you to a shell prompt. 4.3.1 - Setting up disks during installation. Setting up disks in OpenBSD varies a bit between platforms. For i386 and macppc, disk setup is done in two stages. First, the OpenBSD slice of the hard disk is defined using fdisk(8), then that slice is subdivided into OpenBSD partitions using disklabel(8). Some users may be a little confused by the terminology used here. It will appear we are using the word "partition" in two different ways. This observation is correct. There are two layers of partitioning in several OpenBSD platforms, the first, one could consider the Operating System partitioning, which is how multiple OSs on one computer mark out their own space on the disk, and the second one is how the OpenBSD partition is sub-partitioned into individual filesystems. The first layer is visible as a disk partition to DOS, Windows, and any other OS that can coexist with other Operating Systems on the IBM AT descended machines. The second layer of partitioning is visible only to OpenBSD and those OSs which can directly read an OpenBSD filesystem. Cool! Let's get to it... You will now initialize the disk(s) that OpenBSD will use. To enable all available security features you should configure the disk(s) to allow the creation of separate filesystems for /, /tmp, /var, /usr, and /home. Available disks are: wd0. Which one is the root disk? (or done) [wd0] Enter The root disk is the disk the system will boot from, and normally where swap space resides. Usually, this will be the default -- if it isn't, you will need to know how to force your computer to boot from a non-standard disk. IDE disks will show up as wd0, wd1, etc., SCSI disks and RAID devices will show up as sd0, sd1, and so on. All the disks OpenBSD can find are listed here -- if you have drives which are not showing up, you have unsupported or improperly configured hardware. Do you want to use *all* of wd0 for OpenBSD? [no] Enter If you say "yes" to this question, the entire disk will be allocated to OpenBSD. This will result in a simple Master Boot Record and partition table being written out to disk -- one partition, the size of the entire hard disk, set to the OpenBSD partition type, and flagged as the bootable partition. This will be a common option for most production uses of OpenBSD, however, there are some systems this should not be done on. Many Compaq systems, some Dell and other systems use a "maintenance" partition, which should be kept intact. If your system has any other partitions of any type you do not wish to erase, do not select "yes" to the above question. For the sake of this example, we will assume the disk is to be split between OpenBSD and a pre-existing Windows 2000 partition, so we take the default of "no", which will take us into the fdisk(8) program. You can also get more information on fdisk(8) here. Important Note: Users with a large hard disk (larger than 8G on a newer i386, though on older machines and different platforms, often much smaller) will want to see this section before going any further. You will now create a single MBR partition to contain your OpenBSD data. This partition must have an id of 'A6'; must *NOT* overlap other partitions; and must be marked as the only active partition. The 'manual' command describes all the fdisk commands in detail. Disk: wd0 geometry: 2586/240/63 [39100320 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ *0: 06 0 1 1 - 202 239 63 [ 63: 3069297 ] DOS > 32MB 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused Enter 'help' for information fdisk: 1> help help Command help list manual Show entire OpenBSD man page for fdisk reinit Re-initialize loaded MBR (to defaults) setpid Set the identifier of a given table entry disk Edit current drive stats edit Edit given table entry flag Flag given table entry as bootable update Update machine code in loaded MBR select Select extended partition table entry MBR print Print loaded MBR partition table write Write loaded MBR to disk exit Exit edit of current MBR, without saving changes quit Quit edit of current MBR, saving current changes abort Abort program without saving current changes fdisk: 1> A few commands are worthy of elaboration: * r or reinit: Clears existing partition table, makes one big OpenBSD partition, flags it active. Equivalent to saying "yes" to the "use *all* of ..." question. * p or print: Displays the current partition table in sectors. "p m" will show the partition table in megabytes, "p g" will show it in gigabytes. * e or edit: edit or alter a table entry. * f or flag: Marks a partition as the active partition, the one that will be booted from * exit and quit: Careful on these, as some users are used to "exit" and "quit" having opposite meanings. It is worth pointing out once again, a screwup here will result in significant data loss. If you are going to do this on a drive with important data, it might be worth practicing on a "disposable" drive, in addition to having a good backup. Our drive here has a 1.5G partition for Windows 2000 (using the FAT filesystem). Looking at the info from the above display, we can see that the Windows partition occupies through cylinder 202 on the drive. So, we are going to allocate the rest of the disk to OpenBSD, starting at cylinder 203. You could also calculate OpenBSD's starting sector of 3069360 by adding the existing partition's starting sector (63) and its size (3069297). You can edit the drive layout in either by Cylinder/Heads/Sectors form or just raw sectors. Which is easier depends upon what you are doing, in this case, working around an existing partition, using CHS format will probably be easier. fdisk: 1> e 1 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused Partition id ('0' to disable) [0 - FF]: [0] (? for help) a6 Do you wish to edit in CHS mode? [n] y BIOS Starting cylinder [0 - 2585]: [0] 203 BIOS Starting head [0 - 239]: [0] Enter BIOS Starting sector [1 - 63]: [0] 1 BIOS Ending cylinder [0 - 2585]: [0] 2585 BIOS Ending head [0 - 239]: [0] 239 BIOS Ending sector [1 - 63]: [0] 63 fdisk:*1> p Disk: wd0 geometry: 2586/240/63 [39100320 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ *0: 06 0 1 1 - 202 239 63 [ 63: 3069297 ] DOS > 32MB 1: A6 203 0 1 - 2585 239 63 [ 3069360: 36030960 ] OpenBSD 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused fdisk:*1> p m Disk: wd0 geometry: 2586/240/63 [19092 Megabytes] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ *0: 06 0 1 1 - 202 239 63 [ 63: 1499M] DOS > 32MB 1: A6 203 0 1 - 2585 239 63 [ 3069360: 17593M] OpenBSD 2: 00 0 0 0 - 0 0 0 [ 0: 0M] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0M] unused fdisk:*1> Note that prompt changed to include an asterisk ('*') to indicate you have unsaved changes. As we can see from the output of p m we have not altered our Windows partition, we have successfully allocated the rest of the drive for OpenBSD, and the partitions do not overlap. We are in business. Almost. What we haven't done is flagged the partition as active so the machine will boot OpenBSD on the next reboot: fdisk:*1> f 1 Partition 1 marked active. fdisk:*1> p Disk: wd0 geometry: 2586/240/63 [39100320 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ 0: 06 0 1 1 - 202 239 63 [ 63: 3069297 ] DOS > 32MB *1: A6 203 0 1 - 2585 239 63 [ 3069360: 36030960 ] OpenBSD 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused fdisk:*1> And now, we are ready to save our changes: fdisk:*1> w Writing MBR at offset 0. wd0: no disk label fdisk: 1> q Creating a disklabel The next step is to use disklabel(8) to slice up the OpenBSD partition. More details on using disklabel(8) can be found in FAQ 14, disklabel. Here is the partition information you chose: Disk: wd0 geometry: 2586/240/63 [39100320 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ *0: 06 0 1 1 - 202 239 63 [ 63: 3069297 ] DOS > 32MB 1: A6 203 0 1 - 2585 239 63 [ 3069360: 36030960 ] OpenBSD 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused You will now create an OpenBSD disklabel inside the OpenBSD MBR partition. The disklabel defines how OpenBSD splits up the MBR partition into OpenBSD partitions in which filesystems and swap space are created. The offsets used in the disklabel are ABSOLUTE, i.e. relative to the start of the disk, NOT the start of the OpenBSD MBR partition. disklabel: no disk label WARNING: Disk wd0 has no label. You will be creating a new one. # using MBR partition 1: type A6 off 3069360 (0x2ed5b0) size 36030960 (0x225c9f0) Treating sectors 3069360-39100320 as the OpenBSD portion of the disk. You can use the 'b' command to change this. Initial label editor (enter '?' for help at any prompt) > ? Available commands: p [unit] - print label. M - show entire OpenBSD man page for disklabel. e - edit drive parameters. a [part] - add new partition. b - set OpenBSD disk boundaries. c [part] - change partition size. d [part] - delete partition. D - set label to default. g [d|b] - Use [d]isk or [b]ios geometry. m [part] - modify existing partition. n [part] - set the mount point for a partition. r - recalculate free space. u - undo last change. s [path] - save label to file. w - write label to disk. q - quit and save changes. x - exit without saving changes. X - toggle expert mode. z - zero out partition table. ? [cmnd] - this message or command specific help. Numeric parameters may use suffixes to indicate units: 'b' for bytes, 'c' for cylinders, 'k' for kilobytes, 'm' for megabytes, 'g' for gigabytes or no suffix for sectors (usually 512 bytes). Non-sector units will be rounded to the nearest cylinder. Entering '?' at most prompts will give you (simple) context sensitive help. > Again, a few of these commands could use a little elaboration: * p - displays (prints) the current disklabel to the screen, and you can use the modifiers k, m or g for kilobytes, megabytes or gigabytes. * D - Clears any existing disklabel, creates a new default disklabel which covers just the current OpenBSD partition. This can be useful if the disk previously had a disklabel on it, and the OpenBSD partition was recreated to a different size -- the old disk label may not get deleted, and may cause confusion. * m - Modifies an existing entry in a disklabel. Do not over estimate what this will do for you. While it may alter the size of a disklabel partition, it will NOT alter the filesystem on the drive. Using this option and expecting it to resize existing partitions is a good way of losing large amounts of data. Slicing up your disk properly is important. The answer to the question, "How should I partition my system?" is "Exactly how you need it". This will vary from application to application. There is no universal answer. If you are unsure of how you want to partition your system, see this discussion. In this system, we have over 17G available for OpenBSD. That's a lot of space, and it isn't likely we will need most of it. So, we will deliberately not use absolute minimum sizes. We would rather have a few hundred megabytes of unused space than a kilobyte too little. On the root disk, the two partitions 'a' and 'b' must be created. The installation process will not proceed until these two partitions are available. 'a' will be used for the root filesystem (/) and 'b' will be used as swap space. After a little thought, we decide to create just enough partitions to allow the creation of the recommended separate filesystems (/, /tmp, /var, /usr, / home) along with a swap partition: * wd0a: / (root) - 150M. Should be more than enough. * wd0b: (swap) - 300M. * wd0d: /tmp - 120M. /tmp is used for building some software, 120M will probably be enough for most things. * wd0e: /var - 80M. If this were to be a web or mail server, we'd have made this partition much larger, but, that's not what we are doing. * wd0g: /usr - 2G. We want this partition to be large enough to load quite a few user applications, plus be able to update and rebuild the system if desired or needed. The Ports tree will be here as well, which will take almost 100M of this space before ports are built. * wd0h: /home - 4G. This will allow plenty of user file space. Now, if you add those up, you will see over 10G of space is unused! Unused space won't hurt anything, and it gives us flexibility to enlarge things in the future if need be. Need more /tmp? No problem, create a new one in the unused space, change /etc/fstab and problem solved. > p m device: /dev/rwd0c type: ESDI disk: ESDI/IDE disk label: ST320011A bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 39102336 free sectors: 36030960 rpm: 3600 16 partitions: # size offset fstype [fsize bsize cpg] a: 17593.2M 1498.7M unused 0 0 c: 19092.9M 0.0M unused 0 0 i: 1498.7M 0.0M MSDOS > d a > a a offset: [3069360] Enter size: [36030960] 150M Rounding to nearest cylinder: 307440 FS type: [4.2BSD] Enter mount point: [none] / > a b offset: [3376800] Enter size: [35723520] 300M Rounding to nearest cylinder: 614880 FS type: [swap] Enter > a d offset: [3991680] Enter size: [35108640] 120m Rounding to nearest cylinder: 245952 FS type: [4.2BSD] Enter mount point: [none] /tmp > a e offset: [4237632] Enter size: [34862688] 80m Rounding to nearest cylinder: 164304 FS type: [4.2BSD] Enter mount point: [none] /var > a g offset: [4401936] Enter size: [34698384] 2g Rounding to nearest cylinder: 4194288 FS type: [4.2BSD] Enter mount point: [none] /usr > a h offset: [8596224] Enter size: [30504096] 4g Rounding to nearest cylinder: 8388576 FS type: [4.2BSD] Enter mount point: [none] /home > p m device: /dev/rwd0c type: ESDI disk: ESDI/IDE disk label: ST320011A bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 39102336 free sectors: 22115520 rpm: 3600 16 partitions: # size offset fstype [fsize bsize cpg] a: 150.1M 1498.7M 4.2BSD 1024 8192 16 # / b: 300.2M 1648.8M swap c: 19092.9M 0.0M unused 0 0 d: 120.1M 1949.1M 4.2BSD 1024 8192 16 # /tmp e: 80.2M 2069.2M 4.2BSD 1024 8192 16 # /var g: 2048.0M 2149.4M 4.2BSD 1024 8192 16 # /usr h: 4096.0M 4197.4M 4.2BSD 1024 8192 16 # /home i: 1498.7M 0.0M MSDOS > q Write new label?: [y] Enter You will note there is a c partition we seem to have ignored. This partition is your entire hard disk, don't attempt to alter it. You will also note the i partition wasn't defined by us, this is the pre-existing Windows 2000 partition. partitions are not assigned any particular letters -- with the exception of a (root), b (swap) and c (entire disk), the rest of the partitions (through letter p) are available for use as you desire. If you look closely at the output of the disklabel, you will note that your drive RPM rating is probably wrong. This is historical, the drive speed is not used in any way by the system, do not worry about it. Configuring your mount points and formatting your filesystems Now comes the final configuration of your mount points. If you configured the mount points through disklabel(8), this step consists of just verifying your selections, otherwise, you can specify them now. The root filesystem will be mounted on wd0a. wd0b will be used for swap space. Mount point for wd0d (size=122976k), none or done? [/tmp] Enter Mount point for wd0e (size=82152k), none or done? [/var] Enter Mount point for wd0g (size=2097144k), none or done? [/usr] Enter Mount point for wd0h (size=4194288k), none or done? [/home] Enter Mount point for wd0d (size=122976k), none or done? [/tmp] done Done - no available disks found. You have configured the following partitions and mount points: wd0a / wd0d /tmp wd0e /var wd0g /usr wd0h /home The next step creates a filesystem on each partition, ERASING existing data. Are you really sure that you're ready to proceed? [n] y /dev/rwd0a: 307440 sectors in 305 cylinders of 16 tracks, 63 sectors 150.1MB in 20 cyl groups (16 c/g, 7.88MB/g, 1920 i/g) /dev/rwd0d: 245952 sectors in 244 cylinders of 16 tracks, 63 sectors 120.1MB in 16 cyl groups (16 c/g, 7.88MB/g, 1920 i/g) /dev/rwd0e: 164304 sectors in 163 cylinders of 16 tracks, 63 sectors 80.2MB in 11 cyl groups (16 c/g, 7.88MB/g, 1920 i/g) /dev/rwd0g: 4194288 sectors in 4161 cylinders of 16 tracks, 63 sectors 2048.0MB in 261 cyl groups (16 c/g, 7.88MB/g, 1920 i/g) /dev/rwd0h: 8388576 sectors in 8322 cylinders of 16 tracks, 63 sectors 4096.0MB in 521 cyl groups (16 c/g, 7.88MB/g, 1920 i/g) /dev/wd0a on /mnt type ffs (rw, asynchronous, local, ctime=Thu Oct 10 21: 50:36 2 002) /dev/wd0h on /mnt/home type ffs (rw, asynchronous, local, nodev, nosuid, ctime=Thu Oct 10 21:50:36 2002) /dev/wd0d on /mnt/tmp type ffs (rw, asynchronous, local, nodev, nosuid, ctime=Thu Oct 10 21:50:36 2002) /dev/wd0g on /mnt/usr type ffs (rw, asynchronous, local, nodev, ctime=Th u Oct 10 21:50:36 2002) /dev/wd0e on /mnt/var type ffs (rw, asynchronous, local, nodev, nosuid, ctime=Th u Oct 10 21:50:36 2002) You may wonder why the installer again asks for mount points. This allows you to recover from any errors or omissions in the mount points specified during the creation of the disklabel. For instance, the installation process will automatically delete any duplicate mount points you enter during the configuration of the disklabel. The disklabel program will allow you to enter such duplicates, and thus they must be checked for after the disklabel program exits. The deleted duplicate mount points will result in partitions without mount points, that you must assign new mount points for if you wish to use the space. Notice the "Are you really sure that you are ready to proceed?" question defaults to no, so you will have to deliberately tell it to proceed and format your partitions. If you chose no, you would simply be dropped into a shell and could start the install again by typing install, or just by rebooting again with your boot disk. At this point all filesystems will formatted for you. This could take some time depending on the size of the partitions and the speed of the disk. 4.3.2 - Setting the System Hostname Now you must set the system hostname. This value will be saved in the file / etc/myname, which is used during normal boots to set the hostname of the system. As of OpenBSD 3.2 the name stored in /etc/myname includes the fully qualified domain name of the system (FQDN). If you do not set the FQDN of the system, the default value of 'my.domain' will be used. It is important to set this name now, because it will be used when the cryptographic keys for the system are generated during the first boot after installation. This generation takes place whether the network is configured or not. Enter system hostname (short form, e.g. 'foo'): puffy 4.3.3 - Configuring your Network Now it is time to configure your network. The network must be configured if you are planning on doing a ftp or nfs based install, considering it will be based upon the information you are about to enter. Here is a walk through of the network configuration section of the install process. Configure the network? [y] Enter If any interface will be configured by DHCP, you should not enter information that will be supplied via DHCP, e.g. the DNS domain name. Enter DNS domain name (e.g. 'bar.com'): [my.domain] example.com Available interfaces are: fxp0. Which one do you wish to initialize? (or done) [fxp0] Enter IP address for fxp0 (or 'dhcp')? 199.185.137.55 Symbolic (host) name? [puffy] Enter Netmask? [255.255.255.0] Enter The default media for fxp0 is media: Ethernet autoselect (100baseTX full-duplex) Do you want to change the default media? [n] Enter Done - no available interfaces found. Enter IP address of default route: [none] 199.185.137.128 Enter IP address of primary nameserver: [none] 199.185.137.1 Would you like to use the nameserver now? [y] Enter Do you want to do more, manual, network configuration? [n] Enter In the above example, we use a static IP address. You can choose to use dhcp as well if you wish. In the case of DHCP, most of this information will be grabbed from a remote dhcp server, though you will be given a chance to confirm it. NOTE: Only one interface can easily be configured using DHCP during an install. If you attempt to configure more than one interface using DHCP you will encounter errors. You have to manually configure the additional interfaces after the installation. 4.3.4 - Choosing Installation Media After your network is set up, the install script will give you a chance to make manual adjustments to the configuration. Then the filesystems you created will be mounted and a root password set. This will get your local disks ready for the OpenBSD packages to be installed upon them. Next, you will get a chance to choose your installation media. The options are listed below. You will now specify the location and names of the install sets you want to load. You will be able to repeat this step until all of your sets have been successfully loaded. If you are not sure what sets to install, refer to the installation notes for details on the contents of each. Sets can be located on a (m)ounted filesystem; a (c)drom, (d)isk or (t)ape device; or a (f)tp, (n)fs or (h)ttp server. Where are the install sets you want to use? (m, c, f, etc.) c Available CD-ROMs are: cd0. In this example we are installing from CD-ROM. This will bring up a list of devices on your computer identified as a CD-ROM. Most people will only have one. If you need to make sure you pick the device which you will use to install OpenBSD from. NOTE: All possible sources for install sets are listed, but not all may be available on your system. e.g. (n)fs is shown but not all architectures allow NFS installations. If you choose a source that is not available, you will get an error message and be given the chance to choose another source for your installation sets. Available CD-ROMs are: cd0. Which one contains the install media? (or done) [cd0] Enter Enter the pathname where the sets are stored (or '?') [3.2/i386] Enter Here, you are prompted for which directory the installation files are, which is 3.2/i386/ on the official CDROM. 4.3.5 - Choosing Filesets. Now it's time to choose which packages you will be installing. You can get a description of these files in the next section. The files that the install program finds will be shown to you on the screen. Your job is just to specify which files you want. By default all the non-X packages are selected, however, some people may wish to limit this to the bare minimum required to run OpenBSD, which would be base32.tar.gz, etc32.tar.gz and bsd. Others will wish to install all packages. The example below is that of a full install. The following sets are available. Enter a filename, 'all' to select all the sets, or 'done'. You may de-select a set by prepending a '-' to its name. [X] base32.tgz [X] etc32.tgz [X] misc32.tgz [X] comp32.tgz [X] man32.tgz [X] game32.tgz [ ] xbase32.tgz [ ] xshare32.tgz [ ] xfont32.tgz [ ] xserv32.tgz [X] bsd File Name? (or 'done') [xbase32.tgz] all The following sets are available. Enter a filename, 'all' to select all the sets, or 'done'. You may de-select a set by prepending a '-' to its name. [X] base32.tgz [X] etc32.tgz [X] misc32.tgz [X] comp32.tgz [X] man32.tgz [X] game32.tgz [X] xbase32.tgz [X] xshare32.tgz [X] xfont32.tgz [X] xserv32.tgz [X] bsd You can do all kinds of nifty things here -- -x* would remove all X components, if you changed your mind. In this case, we are going to load all the sets. While the system will run with fewer sets, the starting default is recommended. Once you have successfully picked which packages you want, you will be prompted to make sure you want to extract these packages and they will then be installed. A progress bar will be shown that will keep you informed on how much time it will take. The times range greatly depending on what system it is you are installing OpenBSD on, the packages installed, and the speed of the source media. This part may from a few minutes to several hours. File Name? (or 'done') [done] Enter Ready to install sets? [y] Enter Getting base32.tgz ... 100% |**************************************************| 23870 KB 00:15 Getting etc32.tgz ... 100% |**************************************************| 1447 KB 00:01 Getting misc32.tgz ... 100% |**************************************************| 1666 KB 00:00 Getting comp32.tgz ... 100% |**************************************************| 16801 KB 00:12 Getting man32.tgz ... 100% |**************************************************| 5428 KB 00:04 Getting game32.tgz ... 100% |**************************************************| 2702 KB 00:01 Getting bsd ... 100% |**************************************************| 4409 KB 00:01 Getting xbase32.tgz ... 100% |**************************************************| 8837 KB 00:04 Getting xshare32.tgz ... 100% |**************************************************| 1531 KB 00:02 Getting xfont32.tgz ... 100% |**************************************************| 30664 KB 00:14 Getting xserv32.tgz ... 100% |**************************************************| 14798 KB 00:05 Extract more sets? [n] If your system has a small amount of RAM (less than 20M on i386), do not hit return at that prompt quite yet! 4.3.6 - Special steps for machines with little RAM As OpenBSD has grown, the minimum RAM requirement has grown, and is likely to continue to increase. The next step in the install process will require more than 16M RAM, and will fail on older machines with less than 20M RAM (again, these are i386 numbers -- some other platforms will require far less RAM, though this trick can be used with them as well, if they are running near the lower-limits. During the install process, there is normally no swap, the real RAM is all you have. The 'MAKEDEV' step that follows will require more than the rest of the install required. As a system with small amounts of RAM can still be very usable for many applications, working around this limitation is a quite useful trick. The solution is to activate swap now. The swap partition has been created, the files are installed to the hard disk, the only trick here is to manually invoke it. So, do not just hit 'ENTER' at the above prompt, but rather, hit '! ', which will bring up a shell, and launch swapon(8) from the mounted hard drive: Extract more sets? [n] ! Type 'exit' to return to install. # /mnt/sbin/swapon /dev/wd0b total: 307440k bytes allocated = 0k used, 307440k available # exit Extract more sets? [n] Enter You can now resume the normal installation. 4.3.7 - Finishing up You will now be asked if you plan to run X on this system. If you answer 'Y', /etc/sysctl.conf will be modified to include the line machdep.allowaperture=1 or machdep.allowaperture=2, depending on your platform. Your last task is to enter the time zone. Depending on where your machine lives, there are may be several equally valid answers for the question. In the example that follows, we used US/Eastern, but could also have used EST5EDT or US/Michigan and had the same result. Hitting ? at the prompts will guide you through your choices. Extract more sets? [n] Enter Do you expect to run the X Window System? [y] y Saving configuration files......done. Generating initial host.random file ......done. What timezone are you in? ('?' for list) [US/Pacific] ? Africa/ Chile/ GB-Eire Israel NZ-CHAT Turkey America/ Cuba GMT Jamaica Navajo UCT Antarctica/ EET GMT+0 Japan PRC US/ Arctic/ EST GMT-0 Kwajalein PST8PDT UTC Asia/ EST5EDT GMT0 Libya Pacific/ Universal Atlantic/ Egypt Greenwich MET Poland W-SU Australia/ Eire HST MST Portugal WET Brazil/ Etc/ Hongkong MST7MDT ROC Zulu CET Europe/ Iceland Mexico/ ROK posix/ CST6CDT Factory Indian/ Mideast/ Singapore posixrules Canada/ GB Iran NZ SystemV/ right/ What timezone are you in? ('?' for list) [US/Pacific] US Select a sub-timezone of 'US' ('?' for list): ? Alaska Central Hawaii Mountain Samoa Aleutian East-Indiana Indiana-Starke Pacific Arizona Eastern Michigan Pacific-New Select a sub-timezone of 'US' ('?' for list): Eastern You have selected timezone 'US/Eastern'. The last steps are for the system to create the /dev directory (which may take a while on some systems, especially if you had to use the Small RAM trick above), and install the boot blocks. Making all device nodes...done. Installing boot block... boot: /mnt/boot proto: /usr/mdec/biosboot device: /dev/rwd0c /usr/mdec/biosboot: entry point 0 proto bootblock size 512 room for 12 filesystem blocks at 0x16f Will load 7 blocks of size 8192 each. Using disk geometry of 63 sectors and 240 heads. 0: 9 @(203 150 55) (3078864-3078872) 1: 63 @(203 151 1) (3078873-3078935) 2: 24 @(203 152 1) (3078936-3078959) 3: 16 @(203 8 47) (3069910-3069925) /mnt/boot: 4 entries total using MBR partition 1: type 166 (0xa6) offset 3069360 (0x2ed5b0) ...done. CONGRATULATIONS! Your OpenBSD install has been successfully completed! To boot the new system, enter halt at the command prompt. Once the system has halted, reset the machine and boot from the disk. # halt syncing disks... done The operating system has halted. Please press any key to reboot. OpenBSD is now installed on your system and ready for its first boot, but before you do... Before you reboot At this point, your system is installed and ready to be rebooted and configured for service. Before doing this, however, it would be wise to check out the Errata page to see if there are any bugs that would immediately impact you. After you reboot One of your first things to read after you install your system is afterboot (8). You may also find the following links useful: * Adding users in OpenBSD * Initial Network Setup * Man Pages of popular/useful commands * OpenBSD man pages on the Web * The OpenBSD Ports and Packages system for installing software, as well as here and here One last thing... The OpenBSD developers ask you to Send in a copy of your dmesg. This is really appreciated by the developers, and ultimately, all users. 4.3.8 - Other Information Resources Additional documents already exist for those of you who might have special needs or interests. You can retrieve these from any of the mirror ftp sites. * INSTALL.i386 - Comprehensive installation document. Similar documents exist for all platforms. * INSTALL.linux - Installing OpenBSD along with Linux. * INSTALL.mbr - Explaining the Master Boot Record. * INSTALL.pt - Explaining Partition Tables. * INSTALL.dbr - DOS Floppy Disk Boot Sector. * INSTALL.chs - Explaining CHS Translation. * INSTALL.ata - ATA/ATA-1/ATA-2/IDE/EIDE/etc FAQ * INSTALL.os2br - The os2 Boot Sector. 4.4 - What files are needed for Installation? The complete OpenBSD installation is broken up into a number of separate file sets. Not every application requires every file set. Here is an overview of each: * base32.tgz - Contains the base OpenBSD system Required * etc32.tgz - Contains all the files in /etc Required * comp32.tgz - Contains the compiler and its tools, libs. Recommended * man32.tgz - Contains man pages Recommended * misc32.tgz - Contains misc info, setup documentation * game32.tgz - Contains the games for OpenBSD * xbase32.tgz - Contains the base install for X11 * xfont32.tgz - Contains X11's font server and fonts * xserv32.tgz - Contains X11's X servers * xshare32.tgz - Contains manpages, locale settings, includes, etc for X * bsd - This is the Kernel. Required 4.5 - How much space do I need for an OpenBSD installation? The following are minimum suggested filesystem sizes for a full system install. The numbers include enough extra space to permit you to run a typical home system that is connected to the Internet. * These are minimum values. * If you plan to install a significant amount of third party software, make your /usr partition large! At least triple these values! * For a system that handles lots of email or web pages (stored, respectively, in /var/mail and /var/www) you will want to make your /var partition significantly larger. * For a multiuser system which may generate lots of logs, you will still want to make your /var partition significantly larger (/var/log). * If you plan to rebuild the kernel or system from source, you will want to make the /usr partition significantly larger, at least 800M-1G larger than indicated below. As you read this, keep in mind that /usr and /usr/X11R6 are usually both parts of the same filesystem, that is, /usr, as there is no big advantage to making them into separate filesystems. SYSTEM / /usr /var /usr/X11R6 alpha 50M 250M 25M 100M amiga 40M 200M 25M 180M hp300 40M 200M 25M 80M i386 40M 200M 25M 140M mac68k 40M 200M 25M 80M macppc 50M 200M 25M 100M mvme68k 40M 200M 25M 80M sparc 40M 259M 25M 49M sparc64 50M 200M 25M 100M vax 75M 125M 25M 180M In addition, it is recommended that a /tmp partition be used. The /tmp partition is used in the compiling of ports, among other things, so how big you make it depends on what you do with it. 50M may be plenty for most people, but some large applications may require 100M or more of /tmp space. When you are in the disklabel editor, you may choose to make your entire system have just an 'a' (main filesystem) and 'b' (swap) . The 'a' filesystem which you set up in disklabel will become your root partition, which should be the sum of all the 3 main values above (/, /usr, and /var) plus some space for /tmp. The 'b' partition you set up automatically becomes your system swap partition -- we recommend a minimum of 32MB but if you have disk to spare make it at least 64MB. If you have lots of disk space to spare, make this 256MB, or even 512MB. There are five main reasons for using separate filesystems, instead of shoving everything into one or two filesystems: * Security: You can mark some filesystems as 'nosuid', 'nodev', 'noexec', 'readonly', etc. This is now done by the install process, in fact, if you use the above described partitions. * Stability: A user, or a misbehaved program, can fill a filesystem with garbage if they have write permissions for it. Your critical programs, which of course run on a different filesystem, do not get interrupted. * Speed: A filesystem which gets written to frequently may get somewhat fragmented. (Luckily, the ffs filesystem, what OpenBSD uses, is not prone to heavy fragmentation.) * Integrity: If one filesystem is corrupted for some reason then your other filesystems are still OK. * Size: Many platforms have limits on the area of a disk where the boot ROM can load the kernel from. In some cases, this limit may be very small (504M for an older 486), in other cases, a much larger limit (8G on new i386 systems). As the kernel can end up anywhere in the root partition, the entire root partition should be within this area. For more details, see this section. A good guideline might be to keep your / partition completely below 2G, unless you know your platform (and particular machine!) can handle more (or less!) than that. Some additional thoughts on partitioning: * For your first attempt at an experimentation system, one big / partition and swap may be easiest until you know how much space you need. By doing this you will be sacrificing some of the default security features of OpenBSD that require separate filesystems for /, /tmp, /var, /usr, and / home. * A system exposed to the Internet or other hostile forces should have a separate /var (and maybe even a separate /var/log) for logging. * A /home partition can be nice. New version of the OS? Wipe and reload everything else, leave your /home partition untouched. * A separate partition for anything which may accumulate a large quantity of files that may need to be deleted can be faster to reformat and recreate than to delete. See the upgrade-minifaq for an example (/usr/obj). * If you wish to rebuild your system from source for any reason, the source will be in /usr/src. If you don't make a separate partition for /usr/src, make sure /usr has sufficient space. * A commonly forgotten fact: you do not have to allocate all space on a drive when you set the system up! Since you will now find it a challenge to buy a new drive smaller than 20G, it can make sense to leave a chunk of your drive unallocated. If you outgrow a partition, you can allocate a new partition from your unused space, duplicate your existing partition to the new partition, change /etc/fstab to point to the new partition, remount, you now have more space. * If you make your partitions too close to the minimum size required, you will probably regret it later, when it is time to upgrade your system. 4.6 - Multibooting OpenBSD (i386) Multibooting is having several operating systems on one computer, and some means of selecting the which OS is to boot. It is not a trivial task! If you don't understand what you are doing, you may end up deleting large amounts of data from your computer. New OpenBSD users are highly encouraged to start with a blank hard drive on a dedicated machine, and then practice your desired configuration on a non-production system before attempting a multiboot configuration on a production machine. FAQ 14 has more information about the OpenBSD boot process. When multibooting, the requirements of all operating systems must be met by your configuration. People often ask if there is a way around the 8G boot limit of OpenBSD. While there are some programs that claim to get around various limits of various operating systems, none of them are known to do this with current versions of OpenBSD. Here are several options to multibooting: Setting active partitions This is probably the most overlooked, and yet, sometimes the best solution for multibooting. Simply set the active partition in whatever OS you are currently using to be the one you want to boot by default when you next boot. Virtually every OS offers a program to do this, OpenBSD's is fdisk(8), similar named programs are in Windows 9x and DOS, and many other operating systems. This can be highly desirable for OSs or systems which take a long time to shut down and reboot -- you can set it and start the reboot process, then walk away, grab a cup of coffee, and come back to the system booted the way you want it -- no waiting for the Magic Moment to select the next OS. Boot floppy If you have a system that is used to boot OpenBSD infrequently (or don't wish other users of the computer to note anything has changed), consider using a boot floppy. Simply use one of the standard OpenBSD install floppies, and create a /etc/boot.conf file (yes, you will also have to create an /etc directory on the floppy) with the contents: boot hd0a:/bsd to cause the system to boot from hard drive 0, OpenBSD partition 'a', kernel file /bsd. Note you can also boot from other drives with a line like: "boot hd2a:/bsd" to boot off the third hard drive on your system. To boot from OpenBSD, slip your floppy in, reboot. To boot from the other OS, eject the floppy, reboot. In this case, the boot(8) program is loaded from the floppy, looks for and reads /etc/boot.conf. The "boot hd0a:/bsd" line instructs boot(8) where to load the kernel from -- in this case, the first HD the BIOS sees. Keep in mind, only a small file (/boot) is loaded from the floppy -- the system loads the entire kernel off the hard disk, so this only adds about five seconds to the boot process. Windows NT/2000/XP NTLDR To multiboot OpenBSD and Windows NT/2000/XP, you can use NTLDR, the boot loader that NT uses. To multi-boot with NT, you need a copy of your OpenBSD Partition Boot Record (PBR). After running installboot, you can copy it to a file using dd(1): # dd if=/dev/rsd0a of=openbsd.pbr bs=512 count=1 Now boot NT and put openbsd.pbr in C:. Add a line like this to the end of C:\ BOOT.INI: c:\openbsd.pbr="OpenBSD" When you reboot, you should be able to select OpenBSD from the NT loader menu. There is much more information available about NTLDR at the NTLDR Hacking Guide. On Windows XP you can also edit the boot information using the GUI, see the XP Boot.ini HOWTO. Note: The Windows NT boot loader is only capable of booting OSs from the primary hard drive. You can not use it to load OpenBSD from the second drive on a system. Other boot loaders Some other bootloaders OpenBSD users have used successfully include GAG, OSBS, The Ranish Partition Manager and GRUB. OpenBSD and Linux (i386) Please refer to INSTALL.linux, which gives in depth instructions on getting OpenBSD working with Linux. 4.7 - Sending your dmesg to dmesg@openbsd.org after the install Just to remind people, it's important for the OpenBSD developers to keep track of what hardware works, and what hardware doesn't work perfectly. A quote from /usr/src/etc/root/root.mail If you wish to ensure that OpenBSD runs better on your machines, please do us a favor (after you have your mail system configured!) and type dmesg | mail dmesg@openbsd.org so that we can see what kinds of configurations people are running. We will use this information to improve device driver support in future releases. (We would be much happier if this information was for the supplied GENERIC kernel; not for a custom compiled kernel). The device driver information we get from this helps us fix existing drivers. Make sure you send email from an account that is able to also receive email so developers can contact you back if they have something they want you to test or change in order to get your setup working. It's not important at all to send the email from the same machine that is running OpenBSD, so if that machine is unable to receive email, just $ dmesg | mail your-account@yourmail.dom and then forward that message to dmesg@openbsd.org where your-account@yourmail.dom is your regular email account. (or transfer the dmesg output using ftp/scp/floppydisk/carrier-pigeon/...) NOTE - Please send only GENERIC kernel dmesgs. Custom kernels that have device drivers removed are not helpful. 4.8 - Adding a file set after install "Oh no! I forgot to add a file set when I did the install!" Sometimes, you realize you really DID need comp32.tgz (or any other system component) after all, but you didn't realize this at the time you installed your system. Good news: There are two easy ways to add file sets after the initial install: Using the Upgrade process Simply boot your install media (CD-ROM or Floppy), and choose Upgrade (rather than Install). When you get to the lists of file sets to install, choose the sets you neglected to install first time around, select your source, and let it install them for you. Using tar(1) The install file sets are simply compressed tar files, and you can expand them manually from the root of the filesystem: # cd / # tar xzvpf comp32.tgz Do NOT forget the 'p' option in the above command in order to restore the file permissions properly! One common mistake is to think you can use pkg_add(1) to add a missing file sets. This does not work. pgk_add(1) is for package files, not generic tar files like the install sets. 4.9 - What is 'bsd.rd'? bsd.rd is a "RAM Disk" kernel. This file can be very useful, many developers are careful to keep it on the root of their system at all times. Calling it a "RAM Disk kernel" describes the root filesystem of the kernel -- rather than being a physical drive, the utilities available after the boot of bsd.rd are stored in the kernel, and are run from a RAM-based filesystem. bsd.rd also includes a healthy set of utilities to allow you to do system maintenance and installation. On some platforms, bsd.rd is actually the preferred installation technique -- you place this kernel on an existing filesystem, boot it, and run the install from it. On most platforms, if you have a running older version of OpenBSD, you can FTP a new version of bsd.rd, reboot from it, and install a new version of OpenBSD without using any removable media at all. Here is an example of booting bsd.rd on an i386 system: Using Drive: 0 Partition: 3 reading boot..... probing pc0 com0 com1 apm mem[639k 255M a20=on] disk fd0 hd0 >> OpenBSD/i386 BOOT 1.29 boot> boot hd0a:/bsd.rd . . . normal boot to install . . . As indicated, you will be brought to the install program, but you can also drop to the shell to do maintenance on your system. The general rule on booting bsd.rd is to change your boot kernel from /bsd to bsd.rd through whatever means used on your platform. 4.10 - Common Installation Problems 4.10.1 - Install hangs during MAKEDEV Usually, this is caused by a lack of physical RAM in the system. See here. 4.10.2 - My Compaq only recognizes 16M RAM Some Compaq systems have an issue where the full system RAM is not detected by the OpenBSD second stage boot loader properly, and only 16M may be detected and used by OpenBSD. This can be corrected either by creating/editing /etc/ boot.conf file, or by entering commands at the "boot>" prompt before OpenBSD loads. If you had a machine with 64M RAM, but OpenBSD was only detecting the first 16M, the command you would use would be: machine mem +0x3000000@0x1000000 to add 48M (0x3000000) after the first 16M (0x1000000). Typically, if you had a machine with this problem, you would enter the above command first at the install floppy/CDROM's boot> prompt, load the system, reboot, and create a / etc/boot.conf file with the above line in it so all future bootings will recognize all available RAM. It has also been reported that a ROM update will fix this on some systems. 4.10.3 - My i386 won't boot after install Your install seemed to go fine, but on first boot, you see no sign of OpenBSD attempting to boot. There are a few common reasons for this problem: * No partition was flagged active in fdisk(8). To fix this, reboot the machine using the boot floppy or media, and "flag" a partition as "active" (bootable). See here and here * No valid boot loader was ever put on the disk. If you answer "Y" to the "Use entire disk for OpenBSD?" question during the install, or use the "reinit" option of fdisk(8), the OpenBSD boot record is installed on the Master Boot Record of the disk, otherwise, the existing master boot code is untouched. This will be a problem if no other boot record existed. The solution is to boot the install media again, drop to the shell and invoke fdisk(8) and use the "update" option. * In some rare occasions, something may go wrong with the second stage boot loader install. Reinstalling the second stage boot loader is discussed here. 4.10.4 - My (older, slower) machine booted, but hung at the ssh-keygen steps It is very likely your machine is running fine, just taking a while to do the ssh key generation process. A SparcStation2 or a Macintosh Quadra may take 45 minutes or more to complete the three ssh-keygen(1) steps, some machines will take even longer. Just let it finish, it is only done once per install. 4.10.5 - I got the message "ftplist: No such file" when doing an install When doing an FTP install of a snapshot during the -beta stage of the OpenBSD development cycle, you may see this: Do you want to see a list of potential FTP servers? [y] ENTER grep: /tmp/ftplist: No such file or directory Server IP address or hostname? This is normal and expected behavior during this pre-release part of the cycle. The install program looks for the FTP list on the primary FTP server in a directory that won't be available until the release date, so you get the above message. Simply use the FTP mirror list to find your favorite FTP mirror, and manually enter its name when prompted. Note: You should not see this if you are installing -release or from CDROM. 4.11 - Customizing the Install Process siteXX.tgz file The OpenBSD install/upgrade scripts allow the selection of a user-created set called "siteXX.tgz", where XX is the release version (e.g. 32). The siteXX.tgz file set is, like the other file sets, a gzip(1) compressed tar(1) archive rooted in '/' and is un-tarred like the other sets with the options xzpf. This set is intended to be installed last, after all other file sets (-current install/upgrade scripts guarantee this, though 3.2-release does not. Manually select this file set after the primary installation has been completed). This file set allows the user to add to and/or override the files installed in the 'normal' sets and thus customize the installation or upgrade. Some example uses of a siteXX.tgz file: * Create a siteXX.tgz file that contains all the file changes you made since first installing OpenBSD. Then, if you have to re-create the system you simply select siteXX.tgz during the re-install and all of your changes are replicated on the new system. * Create a series of machine specific directories that each contain a siteXX.tgz file that contains files specific to those machine types. Installation of machines (e.g. boxes with different graphics cards) of a particular category can be completed by selecting the appropriate siteXX.tgz file. * Put the files you routinely customize in a same or similar way in a siteXX.tgz file -- /etc/skel files, /etc/pf.conf, /var/www/conf/ httpd.conf, /etc/rc.conf, etc. install.site/upgrade.site scripts As the last step in the install/upgrade process, the scripts look in the root directory of the newly installed/upgraded system for install.site or upgrade.site, as appropriate to the current process, and runs this script in an environment chrooted to the installed/upgraded system's root. Remember, the upgrade is done from a booted file system, so your target file system is actually mounted on /mnt. However, your script can be written as if it it is running in the "normal" root of your file system. Since this script is run after all the files are installed, you have almost full functionality of your system (though, in single user mode) when your script runs. Note that the install.site script would have to be in a siteXX.tgz file, while the upgrade.site script could be put in the root directory before the upgrade, or could be put in a siteXX.tgz file. The scripts can be used to do anything possible in a script. * Remove files that are installed/upgraded that you don't want present on the system. * Remove/upgrade/install the packages you want on the installed system. * Do an immediate backup/archive of the new system before you expose it to the rest of the world. The combination of siteXX.tgz and install.site/upgrade.site files is intended to give the user broad customization capabilities without having to build their own custom install sets. 4.12 - How can I load a number of similar systems? Here are some tools you can use when you have to deploy a number of similar OpenBSD systems. siteXX.tgz and install/upgrade.site files See the above article. Restore from Dump On most platforms, the boot media includes the restore(8) program, which can be used to restore a backup made by dump(8). Thus, you could boot from a floppy, CD, or bsd.rd file, then fdisk, disklabel, and restore the desired configuration from tape or other media, and install the boot blocks. More details here. Disk Imaging Unfortunately, there are no known disk imaging packages which are FFS-aware and can make an image containing only the active file space. Most of the major disk imaging solutions will treat an OpenBSD partition as a "generic" partition, and can make an image of the whole disk. This often accomplishes your goal, but usually with huge amounts of wasted space -- an empty, 10G / home partition will require 10G of space in the image, even if there isn't a single file in it. While you can typically install a drive image to a larger drive, you would not be able to directly use the extra space, and you would not be able to install an image to a smaller drive. If this is an acceptable situation, you may find the dd command will do what you need, allowing you to copy one disk to another, sector-for-sector. This would provide the same functionality as commercial programs without the cost. 4.13 - How can I get a dmesg(8) to report an install problem? When reporting a problem, it is critical to include the complete system dmesg (8). However, often when you need to do this, it is because the system is working improperly or won't install so you may not have disk, network, or other resources you need to get the dmesg to the appropriate mail list. There are other ways, however: * Floppy disk: The boot disks and CDROM has enough tools to let you record your dmesg to an MSDOS floppy disk for reading on another machine. Place an MSDOS formatted floppy in your disk drive and execute the following commands: mount -t msdos /dev/fd0a /mnt dmesg >/mnt/dmesg.txt umount /mnt If you have another OpenBSD system, you can also write it to an OpenBSD compatible floppy -- often, the boot floppy has enough room on it to hold the dmesg. In that case, leave off the "-t msdos" above. * Serial Console: See this article on setting up the serial console, then capture the output to a file. * FTP: Under some circumstances, you may be able to use the ftp(1) client on the boot disk or CDROM to send the dmesg to a local FTP server, where you can retrieve it later. ------------------------------------------------------------------------------ $OpenBSD: faq4.html,v 1.133 2003/03/18 03:41:04 nick Exp $ ============================================================================== 5 - Building the System from Source ------------------------------------------------------------------------------ Table of Contents * 5.1 - OpenBSD's Flavors * 5.2 - Why do I need a custom kernel? * 5.3 - Kernel configuration Options * 5.4 - Building your own kernel * 5.5 - Boot-time configuration * 5.6 - Getting more verbose output during boot * 5.7 - Using config(8) to change your kernel binary ------------------------------------------------------------------------------ 5.1 - OpenBSD's Flavors There are three "flavors" of OpenBSD: * -release: The version of OpenBSD shipped every six months on CD. * -stable: Release, plus patches considered critical to security and reliability. * -current: The to-the-moment version of OpenBSD, which will turn into the next release. Graphically, the development of these flavors looks something like this: ,------o-----------o----X 2.9 Stable | . . | . ,------o---------o----X 3.0 Stable | . | . . | . | . ,----o----------o--> 3.1 Stable | . | . | . . | . | . | . ,-----o--> 3.2 Stable | . | . | . | . | . | . | . | . -->2.9Rel----->3.0Rel----->3.1Rel----->3.2Rel----> Current Time ---> The code tree is branched between -current, -release and -stable every six months -- -release becomes a frozen point (a "Tag") in the history of the source tree - it is never changed, and is what is on the CDs and FTP servers. -Current is where active work is done, and turns into the next -release of OpenBSD. The -stable (also known as the "Patch branch") is based on -release, and as one can see, it is a "branch" from the development path of OpenBSD. As important fixes are made to -current, they are "back ported" into the -stable branches. In the above illustration, the vertical dotted lines are bug fixes being incorporated into the -stable branches. You will also note that in the above example, the 2.9-stable branch came to an end with 3.1-release, and the 3.0-stable branch came to an end with 3.2-release -- old releases are typically supported up to two releases back. It takes resources and time to support older versions, while we might like to provide ongoing support for old releases, we would rather focus on new features. The -stable branch is, by design, very easy to build from -release of the same version (i.e., going from 3.2-release to 3.2-stable). The -stable branch is -release plus patches found on the errata page, and some simple fixes that do not merit an errata entry. Usually, the operation of -stable is the same as the -release it is based on. If the man pages have to change, it probably won't go into -stable. In other words, new device support will NOT be added to -stable, and new feature support will rarely be added unless it is considered very important. Warning: -current is a moving target. It changes almost minute by minute, and may well change several times in the time it takes to retrieve the source code. As indicated earlier, there is no promise that the system compiles or that it works (of course, the hope is it does). It is entirely possible and not uncommon to get the -current source and have it fail to compile, whereas five minutes later, it may work just fine. If you are not prepared to deal with this, stay away from -current. Most users should be running either -stable or -release. That being said, many people do run -current on production systems, and it is important that some people do so to identify bugs and test new features. However, if you don't know how to properly describe, diagnose and deal with a problem, don't tell yourself (or anyone else) that you are "helping the project" by running -current. "It didn't work!" is not a useful bug report.. "The recent changes to the pciide driver broke compatibility with my Slugchip-based IDE interface, dmesg of working and broken systems follow..." might be a useful report. There are times where "normal" users may wish to live on the cutting edge and run -current. The most common reason is when the user has a device which is not supported by -release (and thus, not -stable), or wishes to use a new feature of the -current. In this case, the choice may be either -current or not using the device, and -current may be the lesser evil. However, one should not expect hand-holding from the developers. Snapshots Between formal releases of OpenBSD, snapshots are made available through the FTP sites. As the name implies, these are builds of whatever code is in the tree at the instant the builder grabbed a copy of the code for that particular platform. Remember, on some platforms, this may be DAYS before the snapshot build is completed and put out for distribution. There is no promise that the snapshots are completely functional, or even install. Often, a change that needs to be tested may trigger snapshot creation. Some platforms have snapshots built on an almost daily basis, others will be much less frequent. If you desire to run -current, a recent snapshot is often all you need, and upgrading to a snapshot is usually a good starting point before attempting to build -current. It is sometimes asked if there is any way to get a copy of exactly the code used to build a snapshot. The answer is no. First, there is no significant benefit to this. Second, the snapshots are built as desired, as time permits, and as resources become available. On fast platforms, one might be able to build several snapshots in a day. On slower platforms, it may take a week or more to build a snapshot. Providing tags or markers in the source tree for each snapshot would be quite impractical. Keeping Things in Sync It is important to understand that OpenBSD is an Operating System, intended to be taken as a whole, not a kernel with a bunch of utilities stuck on. You must make sure your kernel, "userland" (the supporting utilities and files) and ports tree are all in sync, or unpleasant things will happen. Said another way (because people just keep making the error), you can not run brand new ports on a month old system, or rebuild a kernel from -current source and expect it to work with a -release userland. Yes, this does mean you need to update your system if you want to run a new program which was added to the ports tree today. Sorry, but again, OpenBSD has limited resources available. One should also understand that when upgrading by source, the update process is supported in only one direction: from older to newer, and from -stable to -current. You can not run 3.2-current (or a snapshot), then decide you are living too dangerously, and step back to 3.2-stable. You are on your own if you choose any path other than the supported option of reloading your system from scratch, do not expect assistance from the OpenBSD development team. Yes, this does mean you should think long and hard before committing yourself to using -current. 5.2 - Why would I want to create my own custom kernel? Several reasons, although this practice is generally geared towards knowledgeable users who have a good overall understanding of the system. * Your computer has a very small amount of RAM and you want to preserve as much as possible by removing device drivers you don't use * You wish to remove default options or add options which may not have been enabled by default * You wish to enable experimental options Under most circumstances you will NOT need to compile your own kernel. The GENERIC kernel will usually be all that you need. In fact, there are several reasons why you do not want to create your own kernel. The main reason is that it is very easy to make changes to the kernel configuration which look logical, but do not work. This is your danger sign. If something does not appear to work properly, please try the GENERIC kernel before sending in a bug report. Developers will usually ignore bug reports dealing with custom kernels, unless the problem can be reproduced in a GENERIC kernel as well. You have been warned. 5.3 - Kernel Configuration Options Kernel Configuration Options are options that you add to your kernel configuration that place certain features into your kernel. This allows you to have exactly the support you want, without having support for unneeded devices. There are a multitude of options that allow you to customize your kernel. Here we will go over only some of them, those that are most commonly used. Check the options(4) man page for a more complete list of options. You can also check the example configuration files that are available for your architecture. Not all kernel options have been tested for compatibility with all other options. Don't put an option in your kernel unless you actually have a reason to do so! The one kernel configuration which gets the most testing is the GENERIC kernel. This is usually a combination of the options in /usr/src/sys/ arch/`arch -s`/conf/GENERIC and /usr/src/sys/conf/GENERIC. * Alpha Kernel Conf Files * i386 Kernel Configuration files * macppc Kernel Configuration files * sparc Kernel Configuration Files * sparc64 Kernel Configuration Files * vax Kernel Configuration Files * Other Arch's Look closely at these files and you will notice a line like: include "../../../conf/GENERIC" This means that it is referencing yet another configuration file. This file stores non arch-dependent options. So when creating your Kernel Config be sure to look through /sys/conf/GENERIC and see what you want. There are options in there that are necessary. All of the options listed below should be placed in your kernel configuration file in the format of: option OPTION for example. To place option debug in the kernel, add a line like this: option DEBUG Options in the OpenBSD kernel are translated into compiler preprocessor options, therefore an option like DEBUG would have the source compiled with option -DDEBUG. Which is equivalent to doing a #define DEBUG throughout the kernel. OpenBSD has many compatibility options which allow you to use binaries from other OS's. Not all are availably on every architecture, so be sure to read the man pages for each option to see if your arch is supported. * COMPAT_SVR4(8) - Compatibility with SVR4 binaries. * COMPAT_BSDOS(8) - Compatibility with BSD/OS binaries. * COMPAT_LINUX(8) - Compatibility with Linux binaries. * COMPAT_SUNOS(8) - Compatibility with SunOS binaries. * COMPAT_ULTRIX(8) - Compatibility with Ultrix binaries. * COMPAT_FREEBSD(8) - Compatibility with FreeBSD binaries. * COMPAT_HPUX(8) - Compatibility with HP-UX binaries. Only available on some m68k arch's. * COMPAT_IBCS2(8) - Compatibility to run ibcs2 binaries. * COMPAT_OSF1(8) - Run Digital Unix binaries. Available only on Alpha platform. * COMPAT_43 - Compatibility with 4.3BSD. Use of this is discouraged, but it is needed for some applications. * COMPAT_11 - Compatibility with NetBSD 1.1. * COMPAT_NOMID - Compatibility with a.out executables that lack a machine id. It is always helpful to be able to debug problems with the kernel. But many choose not to put these options in their kernel because these options add considerable size to the kernel. They are however extremely helpful in a case where a bug might be present. This will help the developers discover the source of your problems much quicker. Here is a list of popular debugging options that can be added to your kernel. * DDB(4) - This compiles in the in-kernel debugger. This isn't available on all platforms. So be sure to read before adding it. * KGDB(7) - Compiles a remote kernel debugger using gdb's `remote target` feature. * makeoptions DEBUG="-g" - Makes bsd.gdb along with bsd. This is useful for debugging crash dumps with gdb. * DEBUG - Used to put various debugging options in the kernel, where the source has defined them. * KTRACE - Adds hooks for the system call tracing facility. Which allows users to use ktrace(1). * DIAGNOSTIC - Adds code to the kernel that does internal consistency checks. * GPROF - adds code to the kernel for kernel profiling with kgmon(8). * makeoptions PROF="-pg" - The -pg flag causes the kernel to be compiled with support for profiling. Option GPROF is required to use this option. Filesystem Options. * FFS - Berkeley Fast Filesystem NOTE: This option is required. * EXT2FS - Second Extended File System. This is needed for those of you who want to read Linux partitions. * MFS - Memory File System that stores files in swappable memory. * NFS - Network File System. This is needed if you will be using NFS. * CD9660 - This is iso9660 + rockridge filesystem. This is required to read from CDs. * MSDOSFS - Needed to read MS-DOS FAT filesystems. Also has support for Windows 95 long name + mixed case extensions. * FDESC - Includes code for a file system which can be mounted on /dev/fd. * KERNFS - Includes code that permits the mounting of a special file system (normally mounted on /kern) in which files representing various kernel variables and parameters may be found. * NULLFS - Code to have a loopback filesystem. mount_null(8) has more information. * PROCFS - Includes code for a special file system (conventionally mounted on /proc). * PORTAL - Includes the (experimental) portal filesystem. This permits interesting tricks like opening TCP sockets by opening files in the file system. * UMAPFS - Includes a loopback file system in which user and group ids may be remapped -- this can be useful when mounting alien file systems with different uids and gids than the local system (eg, remote NFS). * UNION - Includes code for the union file system, which permits directories to be mounted on top of each other in such a way that both file systems remain visible. This code isn't quite stable yet. * XFS - Add hooks for using a filesystem that is compatible with the AFS filesystem. Currently used by the Arla/AFS code. * FFS_SOFTUPDATES - Allows for the use of softupdates. To read more on softupdates read the Softupdates FAQ section. * NFSSERVER - Allow for the server-side NFS code to be included in the kernel. * NFSCLIENT - Allow for the client-side NFS code to be included in the kernel. * FIFO - Support for FIFOs. RECOMMENDED. * NVNODE=integer - Where integer is the size of the cache used by the name-to-inode translation routines, (a.k.a. the namei() cache, though called by many other names in the kernel source). * EXT2FS_SYSTEM_FLAG - This option changes the behavior of the APPEND and IMMUTABLE flags for a file on an EXT2FS filesystem. Read options(4) for more details. * QUOTA - Support for Filesystem Quota's. To read up on using quotas read FAQ 10, Quotas. Misc. Options * PCIVERBOSE - Make the boot process more verbose for PCI peripherals. * EISAVERBOSE - Make the boot process more verbose for EISA peripherals. * PCMCIAVERBOSE - Make the boot process more verbose for PCMCIA peripherals. * APERTURE - Provide in-kernel support for VGA framebuffer mapping by user processes. Needed to run X. * LKM - Support for Loadable Kernel Modules. Not available on all arch's. Read lkm(4) for more information. * INSECURE - Hardwires the kernel security level to -1. Read init(8) for more information on kernel security levels. * RAM_DISK_HOOKS - Allows for machine dependent functions to be called when the ramdisk driver is configured. * RAM_DISK_IS_ROOT - Forces the ramdisk to be root. * CCDNBUF=integer - Set number of component buffers used by CCD(4). Default is 8. For more on CCD, read the man page, or the Performance Tuning FAQ section. * KMEMSTATS - This makes malloc(9), the kernel memory allocator, keep statistics on its use. If option DEBUG is used, this option is automatically turned on by config. * BOOT_CONFIG - Adds support for the -c boot option. Networking Options Also check the Networking FAQ or the Networking Performance Tuning FAQ. * GATEWAY - Enables IPFORWARDING and (on most ports) increases the size of NMBCLUSTERS. * NMBCLUSTERS=integer - Controls the size mbuf cluster map. * IPFORWARDING - Enables IP routing behavior. With this option enabled, the machine will forward IP datagrams between its interfaces that are destined for other machines. * MROUTING - Includes support for IP multicast routers. * INET - Includes support for the TCP/IP protocol stack. This option is REQUIRED. * MCLSHIFT=value - This option is the base-2 logarithm of the size of mbuf clusters. Read options(4) for more information on this option. * NS - Include support for the Xerox XNS protocol stack. See ns(4). * ISO,TPIP - Include support for the ubiquitous OSI protocol stack. See iso (4) for more information. * EON - Include support for OSI tunneling over IP. * CCITT,LLC,HDLC - Include support for the X.25 protocol stack. * IPX, IPXIP - Include support for Internetwork Packet Exchange protocol commonly in use by Novell NetWare. * NETATALK - Include kernel support for the AppleTalk family of protocols. * TCP_COMPAT_42 - Use of this option is extremely discouraged, so it should not be enabled. TCP bug compatibility with 4.2BSD. In 4.2BSD, TCP sequence numbers were 32-bit signed values. Modern implementations of TCP use unsigned values. * TCP_NEWRENO - Turns on NewReno fast recovery phase, which allows one lost segment to be recovered per round trip time. * TCP_SACK - Turns on selective acknowledgements. * TCP_FACK - Turns on forward acknowledgements allowing a more precise estimate of outstanding data during the fast recovery phase by using SACK information. This option can be used together with TCP_SACK. * PPP_FILTER - This option turns on pcap(3) based filtering for ppp connections. * PPP_BSDCOMP - PPP BSD compression. * PPP_DEFLATE - Used in conjunction with PPP_BSDCOMP. * IPSEC - This option enables IP security protocol support. See ipsec(4) for more details. This now implies option KEY, which gives support for PFKEYv2. * ENCDEBUG - This option enables debugging information to be conditionally logged in case IPSEC encounters errors. SCSI Subsystem Options * SCSITERSE - Terser SCSI error messages. This omits the table for decoding ASC/ASCQ info, saving about 8 bytes or so. * SCSIDEBUG - Prints extra debugging info for the SCSI subsystem to the console. 5.4 - Building your own kernel Full instructions for creating your own custom kernel are in the afterboot(8) man page. To compile your kernel from the cdrom you need to first have the source code available. The source is available on both the official CD (disk 3) and on the FTP sites. The following example assumes that CD3 is mounted on /mnt: # cd /usr/src # tar xvzf /mnt/src.tar.gz Note: If you are downloading from the FTP servers, you will find TWO files, src.tar.gz and srcsys.tar.gz. The first is the "userland" -- everything but the kernel, the second is the kernel source. Download and extract both of them as above, as for most uses, you will want both. On the CDROM, they are combined into one file. Now to create your custom kernel it is easiest to start with the GENERIC kernel. This is located at /usr/src/sys/arch/$ARCH/conf/GENERIC, where $ARCH is your architecture. There are other sample configurations available in that directory as well. Here are two examples for compiling your kernel. The first example is compiling your kernel on a read-only source tree. The second on a writable source tree. # cd /somewhere # cp /usr/src/sys/arch/$ARCH/conf/SOMEFILE . # vi SOMEFILE (to make the changes you want) # config -s /usr/src/sys -b . SOMEFILE followed by either: # make depend - OR - # make clean # make You must run 'make depend' when you have made any changes (including updates and patches) to your source tree (in other words, almost always, unless you need to run 'make clean'). If you have made changes to your kernel configuration options, and/or made major changes to your source tree, you should use 'make clean' instead of the above 'made depend'. Note that it is always safe to do a 'make clean', though it may result in longer compile times, as more will be rebuilt. To compile a kernel inside a writable source tree do the following: # cd sys/arch/$ARCH/conf # vi SOMEFILE (to make any changes you want) # config SOMEFILE (read more about it here: config(8)) # cd ../compile/SOMEFILE # make Where $ARCH is the architecture you are using (e.g. i386). You can also do a make depend to make the dependencies for the next time you compile your kernel. To move your kernel into place. # cp /bsd /bsd.old # cp /sys/arch/$ARCH/compile/SOMEFILE/bsd /bsd To revert to your old kernel at boot you just need to boot> bsd.old and your old kernel will be loaded instead of /bsd. Sometimes when you build a new kernel you will be required to install new bootblocks. To do so, read FAQ 14, Installing Bootblocks, which will give you an overview on using OpenBSD's Bootloader. 5.5 - Boot Time Configuration Sometimes when booting your system you might notice that the kernel finds your device but maybe at the wrong IRQ. And maybe you need to use this device right away. Well, without rebuilding the kernel you can use OpenBSD's boot time