# OpenBSD-FAQ / faq14.tex

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 \section{Disks and Partitions} The details of setting up disks in OpenBSD vary between platforms, so you should read the installation instructions in the \texttt{INSTALL.\textless{}arch\textgreater{}} file for your platform to determine the specifics for your system. \subsection*{Drive identification} OpenBSD handles mass storage with two drivers on most platforms, depending upon the normal command set that kind of device supports: \begin{itemize} \item \texttt{wd(4)}: IDE disks (and devices that look like IDE disks, for example, SATA, MFM or ESDI disks, or a flash device with an appropriate adapter) attached to a \texttt{wdc(4)} or \texttt{pciide(4)} interface. \item \texttt{sd(4)}: Devices that utilize SCSI commands, such as SCSI disks attached to a SCSI adapter, USB disks, SATA disks attached to an \texttt{ahci(4)} interface, and disk arrays attached to a RAID controller. \end{itemize} The first drive of a particular type identified by OpenBSD will be drive '\texttt{0}', the second will be '\texttt{1}', etc. So, the first IDE-like disk will be wd0, the third SCSI-like disk will be \texttt{sd2}. If you have two SCSI-like drives and three IDE-like drives on a system, you would have \texttt{sd0}, \texttt{sd1}, \texttt{wd0}, \texttt{wd1}, and \texttt{wd2} on that machine. The order is based on the order they are found during hardware discovery at boot. There are a few key points to keep in mind: \begin{itemize} \item Drives may not be numbered in the same order as your boot ROM attempts to boot them (i.e., your system may attempt to boot what OpenBSD identifies as \texttt{wd2} or \texttt{sd1}). Sometimes you may be able to change this, sometimes not. \item Removing or adding a disk may impact the identity of other drives on the system. \end{itemize} \subsection*{Partitioning} Due to historical reasons, the term "partition" is regularly used for two different things in OpenBSD and this leads to some confusion. The two types of "partitions" are: \begin{itemize} \item "disklabel partitions" created with \texttt{disklabel(8)} (often called "filesystem partitions"). \item "fdisk partitions" created with \texttt{fdisk(8)} (often called "partition table partitions" or "Master Boot Record (MBR) partitions"). \end{itemize} All OpenBSD platforms use disklabel(8) as the primary way to manage OpenBSD filesystem partitions, but only some platforms also require using fdisk(8) to manage Partition Table partitions. On the platforms that use fdisk partitions, one fdisk partition is used to hold all of the OpenBSD file systems, this partition is then sliced up into disklabel partitions. These disklabel partitions are labeled "\texttt{a}" through "\texttt{p}". A few of these are "special": \begin{itemize} \item \texttt{a} -- On the boot disk, the '\texttt{a}' partition is your root partition. \item \texttt{b} -- On the boot disk, the '\texttt{b}' partition is automatically used as a swap partition. \item \texttt{c} -- On all disks, the '\texttt{c}' partition is the entire disk, from the first sector to the last. (Hint: if you wish to totally clear a drive, you write zeros to the 'c' partition of the drive. More commonly, the '\texttt{c}' partition is used by utilities like 'fdisk' to install boot loaders, partition tables, etc.) \end{itemize} \subsection*{Partition identification} An OpenBSD filesystem is identified by the disk it is on, plus the file system partition on that disk. So, file systems may be identified by identifiers like "\texttt{sd0a}" (the "\texttt{a}" partition of the first "\texttt{sd}" device), "\texttt{wd2h}" (the "\texttt{h}" partition of the third "\texttt{wd}" device), or "\texttt{sd1c}" (the entire second sd device). The device files would be \texttt{/dev/sd0a} for the block device, \texttt{/dev/rsd0a} would be the device file for the "\texttt{raw}" (character) device. Some utilities will let you use the "shortcut" name of a partition (i.e., "\texttt{sd0d}") or a drive (i.e., "\texttt{wd1}") instead of the actual device name ("\texttt{/dev/sd0d}" or "\texttt{/dev/wd1c}", respectively). Note again that if you put data on \texttt{wd2d}, then later remove \texttt{wd1} from the system and reboot, your data is now on \texttt{wd1d}, as your old \texttt{wd2} is now \texttt{wd1}. However, a drive's identification won't change after boot, so if a USB drive is unplugged or fails, it won't change the identification of other drives until reboot. \subsection*{Disklabel Unique Identifiers} Disks can also be identified by Disklabel Unique Identifiers (DUIDs), a 16 hex digit number, managed by the \texttt{diskmap(4)} device. This number is generated automatically as a random number when a disklabel is first created, though defaults to all zeros on an existing (pre OpenBSD 4.8) labels. \texttt{disklabel(8)} can be used to change the UID if desired. These UIDs are "persistent" -- if you identify your disks this way, drive "\texttt{f18e359c8fa2522b}" will always be \texttt{f18e359c8fa2522b}, no matter what order or how it is attached. You can specify partitions on the disk by appending a period and the partition letter, for example, \texttt{f18e359c8fa2522b.d} is the 'd' partition of the disk \texttt{f18e359c8fa2522b} and will ALWAYS refer to the same chunk of storage, no matter what order the device is attached to the system, or what kind of interface it is attached to. These UIDs can be used to identify the disks almost anywhere a partition or device would be specified, for example in \texttt{/etc/fstab} or in command lines. Of course, disks and partitions may also be identified in the traditional way, by device, unit number and partition (i.e., \texttt{/dev/sd1f}), and this can be done interchangably. It is worth noting that the DUID is a property of the disklabel, though as OpenBSD only supports one disklabel per disk, this is mostly academic. \section{Using \texttt{fdisk(8)}} Be sure to check the \texttt{fdisk(8)} man page. \texttt{fdisk(8)} is used on some platforms (i386, amd64, macppc, zaurus and armish) to create a partition recognized by the system boot ROM, into which the OpenBSD disklabel partitions can be placed. Other platforms do not need or use \texttt{fdisk(8)}. \texttt{fdisk(8)} can also be used for manipulations of the Master Boot Record (MBR), which can impact all operating systems on a computer. Unlike the fdisk-like programs on some other operating systems, OpenBSD's fdisk assumes you know what you want to do, and for the most part, it will let you do what you need to do, making it a powerful tool to have on hand. It will also let you do things you shouldn't or didn't intend to do, so it must be used with care. Normally, only one OpenBSD fdisk partition will be placed on a disk. That partition will be subdivided by disklabel into OpenBSD filesystem partitions. To just view your partition table using fdisk, use: \begin{alltt}\# \textbf{fdisk sd0}\end{alltt} Which will give an output similar to this: \begin{alltt}Disk: sd0 geometry: 553/255/63 [8883945 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: \#: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ *0: A6 3 0 1 - 552 254 63 [ 48195: 8835750 ] OpenBSD 1: 12 0 1 1 - 2 254 63 [ 63: 48132 ] Compaq Diag. 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused\end{alltt} In this example we are viewing the fdisk output of the first SCSI-like drive. We can see the OpenBSD partition (\texttt{id A6}) and its size. The \texttt{*} tells us that the OpenBSD partition is the bootable partition. In the previous example we just viewed our information. What if we want to edit our partition table? Well, to do so we must use the \texttt{-e} flag. This will bring up a command line prompt to interact with fdisk. \begin{alltt}\# \textbf{fdisk -e wd0} Enter 'help' for information fdisk: 1\textgreater{} \textbf{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 swap Swap two partition entries 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\textgreater{}\end{alltt} Here is an overview of the commands you can use when you choose the \textbf{-e} flag. \begin{itemize} \item \texttt{help} Display a list of commands that fdisk understands in the interactive edit mode. \item \texttt{reinit} Initialize the currently selected, in-memory copy of the boot block. This is a handy way to quickly slap a "full-disk" OpenBSD partition in place, update the boot code, and in general, make the system ready for OpenBSD (and nothing but OpenBSD). \item \texttt{disk} Display the current drive geometry that fdisk is using. You are given a chance to edit it if you wish. \item \texttt{setpid} Change the partition identifier of the given partition table entry. This command is particularly useful for reassigning an existing partition to OpenBSD. \item \texttt{edit} Edit a given table entry in the memory copy of the current boot block. You may edit either in CHS geometry mode, or in sector offsets and sizes. \item \texttt{flag} Make the given partition table entry bootable. Only one entry can be marked bootable. If you wish to boot from an extended partition, you will need to mark the partition table entry for the extended partition as bootable. \item \texttt{update} Update the machine code in the memory copy of the currently selected boot block. \item \texttt{select} Select and load into memory the boot block pointed to by the extended partition table entry in the current boot block. \item \texttt{swap} Swaps two MBR entries, so you can re-order the MBR. \item \texttt{print} Print the currently selected in-memory copy of the boot block and its MBR table to the terminal. \item \texttt{write} Write the in-memory copy of the boot block to disk. You will be asked to confirm this operation. \item \texttt{exit} Exit the current level of fdisk, either returning to the previously selected in-memory copy of a boot block, or exiting the program if there is none. \item \texttt{quit} Exit the current level of fdisk, either returning to the previously selected in-memory copy of a boot block, or exiting the program if there is none. Unlike exit it does write the modified block out. \item \texttt{abort} Quit program without saving current changes. \end{itemize} \subsection*{fdisk tricks and tips} \begin{itemize} \item \texttt{fdisk(8)} offers the ability to specify partitions both in raw sectors and in Cylinder/Head/Sector formats. Both options are given for a reason -- some tasks are easier accomplished one way, others the other way. Don't lock yourself into only using one option. \item A totally blank disk will need to have the master boot record's boot code written to the disk before it can boot. You can use the "reinit" or "update" options to do this. If you fail to do this, you can write a valid partition table with fdisk, but not have a bootable disk. You may wish to update the existing boot code anyway if you are uncertain of its origin. \item If your system has a "maintenance" or "diagnostic" partition, it is recommended that you leave it in place or install it BEFORE installing OpenBSD. \item For historical reasons, "q" saves changes and exits the program, and "x" exits without saving. This is the opposite of what many people are now used to in other environments. fdisk(8) does not warn before saving the changes, so use with care. \end{itemize} \section{Using OpenBSD's \texttt{disklabel(8)}} \subsection*{What is \texttt{disklabel(8)}?} First, be sure to read the \texttt{disklabel(8)} man page. The details of setting up disks in OpenBSD varies somewhat between platforms. For i386, amd64, macppc, zaurus, and armish, disk setup is done in two stages. First, the OpenBSD slice of the hard disk is defined using \texttt{fdisk(8)}, then that slice is subdivided into OpenBSD partitions using \texttt{disklabel(8)}. All OpenBSD platforms, however, use \texttt{disklabel(8)} as the primary way to manage OpenBSD partitions. Platforms that also use \texttt{fdisk(8)} place all the \texttt{disklabel(8)} partitions in a single fdisk partition. Labels hold certain information about your disk, like your drive geometry and information about the filesystems on the disk. The disklabel is then used by the bootstrap program to access the drive and to know where filesystems are contained on the drive. You can read more in-depth information about disklabel in the \texttt{disklabel(5)} man page. On some platforms, disklabel helps overcome architecture limitations on disk partitioning. For example, on i386, you can have 4 primary partitions, but with \texttt{disklabel(8)}, you use one of these 'primary' partitions to store all of your OpenBSD partitions (for example, '\texttt{swap}', '\texttt{/}', '\texttt{/usr}', '\texttt{/var}', etc.), and you still have 3 more partitions available for other OSs. \subsection*{\texttt{disklabel(8)} during OpenBSD's install} One of the major parts of OpenBSD's install is your initial creation of labels. During the install you use disklabel(8) to create your separate partitions. As part of the install process, you can define your mount points from within disklabel(8), but you can change these later in the install or post-install, as well. There is not one "right" way to label a disk, but there are many wrong ways. Before attempting to label your disk, see this discussion on partitioning and partition sizing. For an example of using \texttt{disklabel(8)} during install, see the Setting up disks part of the Installation Guide. \subsection*{Using \texttt{disklabel(8)} after install} After install, one of the most common reasons to use \texttt{disklabel(8)} is to look at how your disk is laid out. The following command will show you the current disklabel, without modifying it: \begin{alltt}\# \texttt{disklabel wd0} \textless{}-- Or whatever disk device you'd like to view type: ESDI disk: ESDI/IDE disk label: SAMSUNG HD154UI uid: d920a43a5a56ad5f flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 2907021 total sectors: 2930277168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: \# size offset fstype [fsize bsize cpg] a: 1024064 64 4.2BSD 2048 16384 1 \# / b: 4195296 1024128 swap c: 2930277168 0 unused d: 4195296 5219424 4.2BSD 2048 16384 1 \# /usr e: 4195296 9414720 4.2BSD 2048 16384 1 \# /tmp f: 20972448 13610016 4.2BSD 2048 16384 1 \# /var h: 2097632 34582464 4.2BSD 2048 16384 1 \# /home\end{alltt} Note how this disk has only part of its disk space allocated at this time. Disklabel offers two different modes for editing the disklabel, a built-in command-driven editor (this is how you installed OpenBSD originally), and a full editor, such as \texttt{vi(1)}. You may find the command-driven editor "easier", as it guides you through all the steps and provides help upon request, but the full-screen editor has definite use, too. Let's add a partition to the above system. \emph{Warning: Any time you are fiddling with your disklabel, you are putting all the data on your disk at risk. Make sure your data is backed up before editing an existing disklabel!} We will use the built-in command-driven editor, which is invoked using the "\texttt{-E}" option to \texttt{disklabel(8)}. \begin{alltt}\# \textbf{disklabel -E wd0} \ldots \textgreater{} a k offset: [36680096] size: [2893591969] 1T Rounding to cylinder: 2147483536 FS type: [4.2BSD] \textgreater{} p m OpenBSD area: 64-2930272065; size: 1430796.9M; free: 364310.8M \# size offset fstype [fsize bsize cpg] a: 500.0M 64 4.2BSD 2048 16384 1 # / b: 2048.5M 1024128 swap c: 1430799.4M 0 unused d: 2048.5M 5219424 4.2BSD 2048 16384 1 # /usr e: 2048.5M 9414720 4.2BSD 2048 16384 1 # /tmp f: 10240.5M 13610016 4.2BSD 2048 16384 1 # /var h: 1024.2M 34582464 4.2BSD 2048 16384 1 # /home k: 1048575.9M 36680192 4.2BSD 8192 65536 1 \textgreater{} q Write new label?: [y]\end{alltt} In this case, \texttt{disklabel(8)} was kind enough to calculate a good starting offset for the partition. In many cases, it will be able to do this, but if you have "holes" in the disklabel (i.e., you deleted a partition, or you just like making your life miserable) you may need to sit down with a paper and pencil to calculate the proper offset. Note that while \texttt{disklabel(8)} does some sanity checking, it is very possible to do things very wrong here. Be careful, understand the meaning of the numbers you are entering. On most OpenBSD platforms, there are sixteen disklabel partitions available, labeled "a" through "p". (some "specialty" systems may have only eight). Every disklabel should have a 'c' partition, with an "fstype" of "unused" that covers the entire physical drive. If your disklabel is not like this, it must be fixed, the "D" option (below) can help. Never try to use the "c" partition for anything other than accessing the raw sectors of the disk, do not attempt to create a file system on "c". On the boot device, "a" is reserved for the root partition, and "b" is the swap partition, but only the boot device makes these distinctions. Other devices may use all fifteen partitions other than "c" for file systems. \subsection*{Disklabel tricks and tips} \begin{itemize} \item \textbf{Get help}: In the command-driven mode, hitting "?" will produce a list of available commands. "M" will show the man page for \texttt{disklabel(8)}. \item \textbf{Reset to default}: In some cases, you may wish to completely restart from scratch and delete all existing disklabel information. The "D" command will reset the label back to default, as if there had never been a disklabel on the drive. \item \textbf{Duplicating a disklabel}: In some cases, you may wish to duplicate the partitioning from one disk to another, but not precisely (for example, you wish to have the same partitions, but on different sizes of drives). Use the '-e' (full-screen editor) mode of disklabel(8) to capture the partitions of the "model" drive, paste it into the new drive, remove the model's 'c' partition, save, and you have copied the disk layout to the other drive without altering its basic parameters. \item (sparc/sparc64) \textbf{Don't put swap at the very beginning of your disk}. While Solaris often puts swap at the very beginning of a disk, OpenBSD requires the boot partition to be at the beginning of the disk. \item (fdisk platforms) \textbf{Leave first track free}: On platforms using fdisk(8), you should leave the first logical track unused, both in disklabel(8) and in fdisk(8). On "modern" computers (i.e., almost everything that will run OpenBSD), the exact amount doesn't really matter, though for performance reasons on the newest disks, having partitions aligned at 4k boundaries is good for performance. For this reason, OpenBSD now defaults to starting the first partition at block 64 instead of 63. \item \textbf{Devices without a disklabel}: If a device does not currently have an OpenBSD disklabel on it but has another file system (for example, a disk with a pre-existing FAT32 file system), the OpenBSD kernel will "create" one in memory, and that can form the basis of a formal OpenBSD disklabel to be stored on disk. However, if a disklabel is created and saved to disk, and a non-OpenBSD file system is added later, the disklabel will not be automatically updated. You must do this yourself if you wish OpenBSD to be able to access this file system. More on this below. \item \textbf{"q" vs. "x"}: For historical reasons, while in the command-driven editor mode, "q" saves changes and exits the program, and "x" exits without saving. This is the opposite of what many people are now used to in other environments. disklabel(8) does warn before saving the changes, though it will "x" quickly and quietly. \item \textbf{Auto-partitioning}: New users are encouraged to use the 'A' command to auto-create a recommended disklabel. You can then edit or alter the auto-created label as you need. \end{itemize} \section{Adding extra disks in OpenBSD} Well once you get your disk installed \textbf{PROPERLY} you need to use \texttt{fdisk(8)} (\emph{i386 only}) and \texttt{disklabel(8)} to set up your disk in OpenBSD. For i386 folks, start with fdisk. Other architectures can ignore this. In the below example we're adding a third SCSI-like drive to the system. \begin{alltt}\# \textbf{fdisk -i sd2}\end{alltt} This will initialize the disk's "real" partition table for exclusive use by OpenBSD. Next you need to create a disklabel for it. This will seem confusing. \begin{alltt}\# \textbf{disklabel -e sd2} (\textit{screen goes blank, your \$EDITOR comes up}) type: SCSI \ldots{}bla\ldots{} sectors/track: 63 total sectors: 6185088 \ldots{}bla\ldots{} 16 partitions: \# size offset fstype [fsize bsize cpg] c: 6185088 0 unused 0 0 \# (Cyl. 0 - 6135) d: 1405080 63 4.2BSD 1024 8192 16 \# (Cyl. 0*- 1393*) e: 4779945 1405143 4.2BSD 1024 8192 16 \# (Cyl. 1393*- 6135)\end{alltt} First, ignore the 'c' partition, it's always there and is for programs like disklabel to function! Fstype for OpenBSD is 4.2BSD. Total sectors is the total size of the disk. Say this is a 3 gigabyte disk. Three gigabytes in disk manufacturer terms is 3000 megabytes. So divide 6185088/3000 (use \texttt{bc(1)}). You get 2061. So, to make up partition sizes for a, d, e, f, g, ... just multiply X*2061 to get X megabytes of space on that partition. The offset for your first new partition should be the same as the "sectors/track" reported earlier in disklabel's output. For us it is 63. The offset for each partition afterwards should be a combination of the size of each partition and the offset of each partition (except the 'c' partition, since it has no play into this equation.) Or, if you just want one partition on the disk, say you will use the whole thing for web storage or a home directory or something, just take the total size of the disk and subtract the sectors per track from it. 6185088-63 = 6185025. Your partition is \begin{alltt}d: 6185025 63 4.2BSD 1024 8192 16\end{alltt} \textbf{If all this seems needlessly complex, you can just use disklabel -E to get the same partitioning mode that you got on your install disk!} There, you can just use "96M" to specify "96 megabytes", or 96G for 96 gigs. That was a lot. But you are not finished. Finally, you need to create the filesystem on that disk using \texttt{newfs(8)}. \begin{alltt}\# \textbf{newfs sd2d}\end{alltt} Or whatever your disk was named as per OpenBSD's disk numbering scheme. (Look at the output from \texttt{dmesg(8)} to see what your disk was named by OpenBSD.) Now figure out where you are going to mount this new partition you just created. Say you want to put it on \texttt{/u}. First, make the directory \texttt{/u}. Then, mount it. \begin{alltt}\# \textbf{mount /dev/sd2d /u}\end{alltt} Finally, add it to \texttt{/etc/fstab(5)}. \begin{alltt}/dev/sd2d /u ffs rw 1 1\end{alltt} What if you need to migrate an existing directory like \texttt{/usr/local}? You should mount the new drive in \texttt{/mnt} and use \begin{alltt}cpio -pdum\end{alltt} to copy /usr/local to the \texttt{/mnt} directory. Edit the \texttt{/etc/fstab(5)} file to show that the \texttt{/usr/local} partition is now \texttt{/dev/sd2d} (your freshly formatted partition). Example: \begin{alltt}\textbf{/dev/sd2d /usr/local ffs rw 1 1}\end{alltt} Reboot into single user mode with \texttt{boot -s}, move the existing \texttt{/usr/local} to \texttt{/usr/local-backup} (or delete it if you feel lucky) and create an empty directory \texttt{/usr/local}. Then reboot the system, and voila, the files are there! \section{How is swap handled?} \subsection{About swap} Historically, all kinds of rules have been tossed about to guide administrators on how much swap to configure on their machines. The problem, of course, is there are few "normal" application. One non-obvious use for swap is to be a place the kernel can dump a copy of what is in core in the event of a system panic for later analysis. For this to work, you must have a swap partition (not a swap file) at least as large as your RAM. By default, the system will save a copy of this dump to \texttt{/var/crash} on reboot, so if you wish to be able to do this automatically, you will need sufficient free space on \texttt{/var}. However, you can also bring the system up single-user, and use \texttt{savecore(8)} to dump it elsewhere. Many types of systems may be appropriately configured with no swap at all. For example, firewalls should not swap in normal operation. Machines with flash storage generally should not swap. If your firewall is flash based, you may benefit (slightly) by not allocating a swap partition, though in most other cases, a swap partition won't actually hurt anything; most disks have more than enough space to allocate a little to swap. There are all kinds of tips about optimizing swap (where on the disk, separate disks, etc.), but if you find yourself in a situation where optimizing swap is an issue, you probably need more RAM. In general, the best optimization for swap is to not need it. In OpenBSD, swap is managed with the \texttt{swapctl(8)} program, which adds, removes, lists and prioritizes swap devices and files. \subsection{Swapping to a partition} On OpenBSD, the '\texttt{b}' partition of the boot drive is used by default and automatically for swap. No configuration is needed for this to take place. If you do not wish to use swap on the boot disk, do not define a "\texttt{b}" partition. If you wish to use swap on other partitions or on other disks, you need to define these partitions in \texttt{/etc/fstab} with lines something like: \begin{alltt}/dev/sd3b none swap sw 0 0 /dev/sd3d none swap sw 0 0\end{alltt} \subsection{Swapping to a file} (Note: if you are looking to swap to a file because you are getting "virtual memory exhausted" errors, you should try raising the per-process limits first with \texttt{csh(1)}'s \texttt{unlimit(1)}, or \texttt{sh(1)}'s \texttt{ulimit(1)}.) Sometimes, your initial guess about how much swap you need proves to be wrong, and you have to add additional swap space, occasionally in a hurry (as in, "Geez, at the rate it is burning swap, we'll be wedged in five minutes"). If you find yourself in this position, adding swap space as a file on an existing file system can be a quick fix. The file must not reside on a filesystem which has SoftUpdates enabled (they are disabled by default). To start out, you can see how much swap you currently have and how much you are using with the \texttt{swapctl(8)} utility. You can do this by using the command: \begin{alltt}\$ \textbf{swapctl -l} Device 512-blocks Used Avail Capacity Priority swap\_device 65520 8 65512 0\% 0\end{alltt} This shows the devices currently being used for swapping and their current statistics. In the above example there is only one device named "\texttt{swap\_device}". This is the predefined area on disk that is used for swapping. (Shows up as partition b when viewing disklabels) As you can also see in the above example, that device isn't getting much use at the moment, but for the purposes of this document, we will act as if an extra 32M is needed. The first step to setting up a file as a swap device is to create the file. It's best to do this with the \texttt{dd(1)} utility. Here is an example of creating the file \texttt{/var/swap} that is 32M in size. \begin{alltt}\$\textbf{sudo dd if=/dev/zero of=/var/swap bs=1k count=32768} 32768+0 records in 32768+0 records out 33554432 bytes transferred in 20 secs (1677721 bytes/sec)\end{alltt} Once this has been done, we can turn on swapping to that device. Use the following command to turn on swapping to this device \begin{alltt}\$ \textbf{sudo chmod 600 /var/swap} \$\textbf{sudo swapctl -a /var/swap}\end{alltt} Now we need to check to see if it has been correctly added to the list of our swap devices. \begin{alltt}\$ \textbf{swapctl -l} Device 512-blocks Used Avail Capacity Priority swap_device 65520 8 65512 0\% 0 /var/swap 65536 0 65536 0\% 0 Total 131056 8 131048 0\%\end{alltt} Now that the file is setup and swapping is being done, you need to add a line to your \texttt{/etc/fstab} file so that this file is configured on the next boot time also. If this line is not added, your won't have this swap device configured. \begin{alltt}\\$ \textbf{cat /etc/fstab} /dev/wd0a / ffs rw 1 1 /var/swap /var/swap swap sw 0 0\end{alltt} \section{Soft Updates} Soft Updates is based on an idea proposed by Greg Ganger and Yale Patt and developed for FreeBSD by Kirk McKusick. SoftUpdates imposes a partial ordering on the buffer cache operations which permits the requirement for synchronous writing of directory entries to be removed from the FFS code. Thus, a large performance increase is seen in disk writing performance. Enabling soft updates must be done with a mount-time option. When mounting a partition with the \texttt{mount(8)} utility, you can specify that you wish to have soft updates enabled on that partition. Below is a sample \texttt{/etc/fstab(5)} entry that has one partition \texttt{sd0a} that we wish to have mounted with soft updates. \begin{alltt}/dev/sd0a / ffs rw,softdep 1 1\end{alltt} Note to sparc users: Do not enable soft updates on sun4 or sun4c machines. These architectures support only a very limited amount of kernel memory and cannot use this feature. However, sun4m machines are fine. \section{How do OpenBSD/i386 and OpenBSD/amd64 boot?} The boot process for OpenBSD/i386 and OpenBSD/amd64 is not trivial, and understanding how it works can be useful to troubleshoot a problem when things don't work. There are four key pieces to the boot process: \begin{enumerate} \item \textbf{\textit{Master Boot Record (MBR)}}: The Master Boot Record is the first 512 bytes on the disk. It contains the primary partition table and a small program to load the Partition Boot Record (PBR). Note that in some environments, the term "MBR" is used to refer to only the code portion of this first block on the disk, rather than the whole first block (including the partition table). It is critical to understand the meaning of "initialize the MBR" -- in the terminology of OpenBSD, it would involve rewriting the entire MBR, clearing any existing partition table, not just the code, as it might on some systems. You will often not want to do this. Instead, use \texttt{fdisk(8)}'s "\texttt{-u}" command line option ("\texttt{fdisk -u wd0}") to (re)install the MBR boot code. While OpenBSD includes its own MBR code, you are not obliged to use it, as virtually any MBR code can boot OpenBSD. The MBR is manipulated by the fdisk(8) program, which is used both to edit the partition table, and also to install the MBR code on the disk. OpenBSD's MBR announces itself with the message: \begin{alltt}Using drive 0, partition 3.\end{alltt} showing the disk and partition it is about to load the PBR from. In addition to the obvious, it also shows a trailing period ("\texttt{.}"), which indicates this machine is capable of using LBA translation to boot. If the machine were incapable of using LBA translation, the above period would have have been replaced with a semicolon ("\texttt{;}"), indicating CHS translation: \begin{alltt}Using drive 0, partition 3;\end{alltt} Note that the trailing period or semicolon can be used as an indicator of the "new" OpenBSD MBR, introduced with OpenBSD 3.5. \item \textbf{\textit{Partition Boot Record (PBR)}}: The Partition Boot Record, also called the PBR or \texttt{biosboot(8)} (after the name of the file that holds the code) is the first 512 bytes of the OpenBSD partition of the disk. The PBR is the "first-stage boot loader" for OpenBSD. It is loaded by the MBR code, and has the task of loading the OpenBSD second-stage boot loader, \texttt{boot(8)}. Like the MBR, the PBR is a very tiny section of code and data, only 512 bytes, total. That's not enough to have a fully filesystem-aware application, so rather than having the PBR locate \texttt{/boot} on the disk, the BIOS-accessible location of \texttt{/boot} is physically coded into the PBR at installation time. The PBR is installed by \texttt{installboot(8)}, which is further described later in this document. The PBR announces itself with the message: \begin{alltt}Loading\ldots{}\end{alltt} printing a dot for every file system block it attempts to load. Again, the PBR shows if it is using LBA or CHS to load, if it has to use CHS translation, it displays a message with a semicolon: \begin{alltt}Loading;\ldots{}\end{alltt} \item \textbf{\textit{Second Stage Boot Loader, \texttt{/boot}}}: \texttt{/boot} is loaded by the PBR, and has the task of accessing the OpenBSD file system through the machine's BIOS, and locating and loading the actual kernel. boot(8) also passes various options and information to the kernel. \texttt{boot(8)} is an interactive program. After it loads, it attempts to locate and read \texttt{/etc/boot.conf}, if it exists (which it does not on a default install), and processes any commands in it. Unless instructed otherwise by \texttt{/etc/boot.conf}, it then gives the user a prompt: \begin{alltt}probing: pc0 com0 com1 apm mem[636k 190M a20=on] disk: fd0 hd0+ \textgreater{}\textgreater{} OpenBSD/i386 BOOT 3.17 boot\textgreater{}\end{alltt} It gives the user (by default) five seconds to start giving it other tasks, but if none are given before the timeout, it starts its default behavior: loading the kernel, bsd, from the root partition of the first hard drive. The second-stage boot loader probes (examines) your system hardware, through the BIOS (as the OpenBSD kernel is not loaded). Above, you can see a few things it looked for and found: \begin{itemize} \item \texttt{pc0} - the standard keyboard and video display of an i386 system. \item \texttt{com0}, \texttt{com1} - Two serial ports \item \texttt{apm} - Advanced Power Management BIOS functions \item \texttt{636k 190M} - The amount of conventional (below 1M) and extended (above 1M) memory it found \item \texttt{fd0 hd0+} - The BIOS disk devices found, in this case, one floppy and one hard disk. \end{itemize} The '\texttt{+}' character after the "\texttt{hd0}" indicates that the BIOS has told \texttt{/boot} that this disk can be accessed via LBA. When doing a first-time install, you will sometimes see a '\texttt{*}' after a hard disk -- this indicates a disk that does not seem to have a valid OpenBSD disk label on it. \item \textbf{Kernel}: \textbf{\texttt{/bsd}}: This is the goal of the boot process, to have the OpenBSD kernel loaded into RAM and properly running. Once the kernel has loaded, OpenBSD accesses the hardware directly, no longer through the BIOS. \end{enumerate} So, the very start of the boot process could look like this: \begin{alltt}Using drive 0, partition 3. \textbf{\textless{}- MBR} Loading.... \textbf{\textless{}- PBR} probing: pc0 com0 com1 apm mem[636k 190M a20=on] \textbf{\textless{}- /boot} disk: fd0 hd0+ \textgreater{}\textgreater{} OpenBSD/i386 BOOT 3.17 boot\textgreater{} booting hd0a:/bsd 4464500+838332 [58+204240+181750]=0x56cfd0 entry point at 0x100120 [ using 386464 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 \textbf{\textless{}- Kernel} The Regents of the University of California. All rights reserved. Copyright (c) 1995-2008 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.0 (GENERIC) \#43: Wed Aug 17 10:10:52 MDT 2011 deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC \ldots{}\end{alltt} \subsection*{What can go wrong} \begin{itemize} \item \textbf{Bad/invalid/incompatible MBR}: Usually, a used hard disk has some MBR code in place, but if the disk is new or moved from a different platform, AND you don't answer "w" to the "\texttt{Use (W)hole disk or (E)dit the MBR?}" question of the installation process, you may end up with a disk without a valid MBR, and thus, it will not be bootable, even though it has a valid partition table. You may install the OpenBSD MBR on your hard disk using the fdisk program. Boot from your install media, choose "\texttt{Shell}" to get a command prompt: \begin{alltt}\# \textbf{fdisk -u wd0}\end{alltt} You may also install a specific MBR to disk using fdisk: \begin{alltt}\# \textbf{fdisk -u -f /usr/mdec/mbr wd0}\end{alltt} which will install the file \texttt{/usr/mdec/mbr} as your system's MBR. This particular file on a standard OpenBSD install happens to be the standard MBR that is also built into fdisk, but any other MBR could be specified here. \item \textbf{Invalid \texttt{/boot} location installed in PBR}: When installboot(8) installs the partition boot record, it writes the block number and offset of \texttt{/boot}'s inode into the PBR. Therefore, deleting and replacing \texttt{/boot} without re-running \texttt{installboot(8)} will render your system unbootable, as the PBR will load whatever happens to be pointed to by the inode specified in it, which will almost certainly no longer be the desired second-stage boot loader! Since \texttt{/boot} is being read using BIOS calls, old versions of the PBR were sensitive to BIOS disk translation. If you altered the drive's geometry (i.e., took it out of one computer that uses CHS translation and moving it into one that uses LBA translation, or even changed a translation option in your BIOS), it would have appeared to the BIOS to be in a different location (a different numerical block must be accessed to get the same data from the disk), so you would have had to run \texttt{installboot(8)} before the system could be rebooted. The new (as of OpenBSD 3.5 and later) PBR is much more tolerant to changes in translation. \end{itemize} As the PBR is very small, its range of error messages is pretty limited, and somewhat cryptic. Most likely messages are: \begin{itemize} \item \textbf{ERR R} -- BIOS returned an error when trying to read a block from the disk. Usually means exactly what it says: your disk wasn't readable. \item \textbf{ERR M} -- An invalid \texttt{magic(5)} number was read in the second-stage bootloader's header. This generally means whatever it was that was read in was NOT \texttt{/boot}, usually meaning \texttt{installboot(8)} was run incorrectly, the \texttt{/boot} file was altered, or you have exceeded your BIOS's ability to read a large disk. \end{itemize} Other error messages are detailed in the \texttt{biosboot(8)} manual page. For more information on the i386 boot process, see: \begin{itemize} \item \texttt{boot\_i386(8)} \item http://www.ata-atapi.com/hiw.html Hale Landis' "How it Works" documents. \end{itemize} \section{What are the issues regarding large drives with OpenBSD?} OpenBSD supports both FFS and FFS2 (also known as UFS and UFS2) file systems. FFS is the historic OpenBSD file system, FFS2 is new as of 4.3. Before looking at the limits of each system, we need to look at some more general system limits. Of course, the ability of file system and the abilities of particular hardware are two different things. A newer 250G IDE hard disk may have issues on older (pre >137G standards) interfaces (though for the most part, they work just fine), and some very old SCSI adapters have been seen to have problems with more modern drives, and some older BIOSs will hang when they encounter a modern sized hard disk. You must respect the abilities of your hardware and boot code, of course. \subsection*{Partition size and location limitations} Unfortunately, the full ability of the OS isn't available until AFTER the OS has been loaded into memory. The boot process has to utilize (and is thus limited by) the system's boot ROM. For this reason, the entire \texttt{/bsd} file (the kernel) must be located on the disk within the boot ROM addressable area. This means that on some older i386 systems, the root partition must be completely within the first 504M, but newer computers may have limits of 2G, 8G, 32G, 128G or more. It is worth noting that many relatively new computers which support larger than 128G drives actually have BIOS limitations of booting only from within the first 128G. You can use these systems with large drives, but your root partition must be within the space supported by the boot ROM. Note that it is possible to install a 40G drive on an old 486 and load OpenBSD on it as one huge partition, and think you have successfully violated the above rule. However, it might come back to haunt you in a most unpleasant way: \begin{itemize} \item You install on the 40G / partition. It works, because the base OS and all its files (including \texttt{/bsd}) are within the first 504M. \item You use the system, and end up with more than 504M of files on it. \item You upgrade, build your own kernel, whatever, and copy your new /bsd over the old one. \item You reboot. \item You get a message such as "ERR M" or other problems on boot. \end{itemize} Why? Because when you copied "over" the new /bsd file, it didn't overwrite the old one, it got relocated to a new location on the disk, probably outside the 504M range the BIOS supported. The boot loader was unable to fetch the file \texttt{/bsd}, and the system hung. To get OpenBSD to boot, the boot loaders (biosboot(8) and /boot in the case of i386/amd64) and the kernel (\texttt{/bsd}) must be within the boot ROM's supported range, and within their own abilities. To play it safe, the rule is simple: \textbf{The entire root partition must be within the computer's BIOS (or boot ROM) addressable space.} Some non-i386 users think they are immune to this, however most platforms have some kind of boot ROM limitation on disk size. Finding out for sure what the limit is, however, can be difficult. This is another good reason to partition your hard disk, rather than using one large partition. \subsection*{\texttt{fsck(8)} time and memory requirements} Another consideration with large file systems is the time and memory required to \texttt{fsck(8)} the file system after a crash or power interruption. One should not put a 120G file system on a system with 32M of RAM and expect it to successfully \texttt{fsck(8)} after a crash. A rough guideline is the system should have at least 1M of available memory for every 1G of disk space to successfully fsck the disk. Swap can be used here, but at a very significant performance penalty, so severe that it is usually unacceptable, except in special cases. The time required to fsck the drive may become a problem as the file system size expands, but you only have to fsck the disk space that is actually allocated to mounted filesystems. This is another reason NOT to allocate all your disk space Just Because It Is There. Keeping file systems mounted RO or not mounted helps keep them from needing to be fsck(8)ed after tripping over the power cord. Don't forget that if you have multiple disks on the system, they could all end up being \texttt{fsck(8)}ed after a crash at the same time, so they could require more RAM than a single disk. By the time one gets to somewhat larger than 1TB file system with default fragment and block sizes, fsck will require 1GB RAM to run, which is the application limit under OpenBSD. Larger fragments and/or blocks will reduce the number of inodes, and allow for larger file systems. \subsection*{FFS vs. FFS2} Using FFS, OpenBSD supports an individual file system of up to 231-1, or 2,147,483,647 blocks, and as each block is 512 bytes, that's a tiny amount less than 1T. FFS2 is capable of much larger file systems, though other limits will be reached long before the file system limits will be reached. The boot/installation kernels \emph{only support FFS}, not FFS2, so key system partitions (\texttt{/}, \texttt{/usr}, \texttt{/var}, \texttt{/tmp}) should not be FFS2, or severe maintenance problems can arise (there should be no reason for those partitions to be that large, anyway). For this reason, very large partitions should only be used for "non-system" partitions, for example, \texttt{/home}, \texttt{/var/www/}, \texttt{/bigarray}, etc. Note that not all controllers and drivers support large disks. For example, \texttt{ami(4)} has a limit of 2TB per logical volume. Always be aware of what was available when a controler or interface was manufactured, and don't just rely on "the connectors fit". \section{Installing Bootblocks - i386/amd64 specific} Modern versions of OpenBSD (3.5 and later) have a very robust boot loader that is much more indifferent to drive geometries than the older boot loader was, however, they are sensitive to where the file \texttt{/boot} resides on the disk. If you do something that causes \texttt{boot(8)} to be moved to a new place on the disk (actually, a new inode), you will "break" your system, preventing it from booting properly. To fix your boot block so that you can boot normally, just put a boot floppy in your drive (or use a bootable CD-ROM) and at the boot prompt, type "\texttt{b hd0a:/bsd}" to force it to boot from the first hard disk (and not the floppy). Your machine should come up normally. You now need to reinstall the first-stage boot loader (\texttt{biosboot(8)}) based on the position of the \texttt{/boot} file, using the \texttt{installboot(8)} program. Our example will assume your boot disk is sd0 (but for IDE it would be wd0, etc.): \begin{alltt}\# \textbf{cd /usr/mdec; ./installboot /boot biosboot sd0}\end{alltt} If a newer version of bootblocks are required, you will need to compile these yourself. To do so simply: \begin{alltt}\# \textbf{cd /sys/arch/i386/stand/} \# \textbf{make && make install } \# \textbf{cd /usr/mdec; cp ./boot /boot} \# \textbf{./installboot /boot biosboot sd0} (or whatever device your hard disk is)\end{alltt} \section{Preparing for disaster: Backing up and Restoring from tape} \subsection*{Introduction:} If you plan on running what might be called a production server, it is advisable to have some form of backup in the event one of your fixed disk drives fails, or the data is otherwise lost. This information will assist you in using the standard \texttt{dump(8)}/\texttt{restore(8)} utilities provided with OpenBSD. More advanced backup utilities, such as "Amanda" and "Bacula" are available through packages for backing up multiple servers to disk and tape. \subsection*{Backing up to tape:} Backing up to tape requires knowledge of where your file systems are mounted. You can determine how your filesystems are mounted using the \texttt{mount(8)} command at your shell prompt. You should get output similar to this: \begin{alltt}\# \textbf{mount} /dev/sd0a on / type ffs (local) /dev/sd0h on /usr type ffs (local)\end{alltt} In this example, the root (\texttt{/}) filesystem resides physically on sd0a which indicates a SCSI-like fixed disk 0, partition a. The \texttt{/usr} filesystem resides on \texttt{sd0h}, which indicates SCSI-like fixed disk 0, partition h. Another example of a more advanced mount table might be: \begin{alltt}\# \textbf{mount} /dev/sd0a on / type ffs (local) /dev/sd0d on /var type ffs (local) /dev/sd0e on /home type ffs (local) /dev/sd0h on /usr type ffs (local)\end{alltt} In this more advanced example, the root (\texttt{/}) filesystem resides physically on \texttt{sd0a}. The \texttt{/var} filesystem resides on \texttt{sd0d}, the \texttt{/home} filesystem on \texttt{sd0e} and finally \texttt{/usr} on \texttt{sd0h}. To backup your machine you will need to feed dump the name of each fixed disk partition. Here is an example of the commands needed to backup the simpler mount table listed above: \begin{alltt}\# \textbf{/sbin/dump -0au -f /dev/nrst0 /dev/rsd0a} \# \textbf{/sbin/dump -0au -f /dev/nrst0 /dev/rsd0h} \# \textbf{mt -f /dev/rst0 rewind}\end{alltt} For the more advanced mount table example, you would use something similar to: \begin{alltt}\# \textbf{/sbin/dump -0au -f /dev/nrst0 /dev/rsd0a} \# \textbf{/sbin/dump -0au -f /dev/nrst0 /dev/rsd0d} \# \textbf{/sbin/dump -0au -f /dev/nrst0 /dev/rsd0e} \# \textbf{/sbin/dump -0au -f /dev/nrst0 /dev/rsd0h} \# \textbf{mt -f /dev/rst0 rewind}\end{alltt} You can review the \texttt{dump(8)} man page to learn exactly what each command line switch does. Here is a brief description of the parameters used above: \begin{itemize} \item \texttt{0} - Perform a level 0 dump, get everything \item \texttt{a} - Attempt to automatically determine tape media length \item \texttt{u} - Update the file /etc/dumpdates to indicate when backup was last performed \item \texttt{f} - Which tape device to use (/dev/nrst0 in this case) \end{itemize} Finally which partition to backup (\texttt{/dev/rsd0a}, etc.) The \texttt{mt(1)} command is used at the end to rewind the drive. Review the mt man page for more options (such as eject). If you are unsure of your tape device name, use \texttt{dmesg} to locate it. An example tape drive entry in dmesg might appear similar to: \begin{alltt}st0 at scsibus0 targ 5 lun 0: \textless{}ARCHIVE, Python 28388-XXX, 5.28\textgreater{}\end{alltt} You may have noticed that when backing up, the tape drive is accessed as device name "\texttt{nrst0}" instead of the "\texttt{st0}" name that is seen in \texttt{dmesg}. When you access \texttt{st0} as \texttt{nrst0} you are accessing the same physical tape drive but telling the drive to not rewind at the end of the job and access the device in raw mode. To back up multiple file systems to a single tape, be sure you use the non-rewind device, if you use a rewind device (\texttt{rst0}) to back up multiple file systems, you'll end up overwriting the prior filesystem with the next one dump tries to write to tape. You can find a more elaborate description of various tape drive devices in the dump man page. If you wanted to write a small script called "backup", it might look something like this: \begin{alltt}echo " Starting Full Backup..." /sbin/dump -0au -f /dev/nrst0 /dev/rsd0a /sbin/dump -0au -f /dev/nrst0 /dev/rsd0d /sbin/dump -0au -f /dev/nrst0 /dev/rsd0e /sbin/dump -0au -f /dev/nrst0 /dev/rsd0h echo echo -n " Rewinding Drive, Please wait..." mt -f /dev/rst0 rewind echo "Done." echo\end{alltt} If scheduled nightly backups are desired, \texttt{cron(8)} could be used to launch your backup script automatically. It will also be helpful to document (on a scrap of paper) how large each file system needs to be. You can use "\texttt{df -h}" to determine how much space each partition is currently using. This will be handy when the drive fails and you need to recreate your partition table on the new drive. Restoring your data will also help reduce fragmentation. To ensure you get all files, the best way of backing up is rebooting your system in single user mode. File systems do not need to be mounted to be backed up. Don't forget to mount root (\texttt{/}) r/w after rebooting in single user mode or your dump will fail when trying to write out dumpdates. Enter "\texttt{bsd -s}" at the boot\textgreater{} prompt for single user mode. \subsection*{Viewing the contents of a dump tape:} After you've backed up your file systems for the first time, it would be a good idea to briefly test your tape and be sure the data on it is as you expect it should be. You can use the following example to review a catalog of files on a dump tape: \begin{alltt}\# \textbf{/sbin/restore -tvs 1 -f /dev/rst0}\end{alltt} This will cause a list of files that exist on the 1st partition of the dump tape to be listed. Following along from the above examples, 1 would be your root (\texttt{/}) file system. To see what resides on the 2nd tape partition and send the output to a file, you would use a command similar to: \begin{alltt}\# \textbf{/sbin/restore -tvs 2 -f /dev/rst0 \textgreater{} /home/me/list.txt}\end{alltt} If you have a mount table like the simple one, 2 would be \texttt{/usr}, if yours is a more advanced mount table 2 might be \texttt{/var} or another fs. The sequence number matches the order in which the file systems are written to tape. \subsection*{Restoring from tape:} The example scenario listed below would be useful if your fixed drive has failed completely. In the event you want to restore a single file from tape, review the restore man page and pay attention to the interactive mode instructions. If you have prepared properly, replacing a disk and restoring your data from tape can be a very quick process. The standard OpenBSD install/boot floppy already contains the required restore utility as well as the binaries required to partition and make your new drive bootable. In most cases, this floppy and your most recent dump tape is all you'll need to get back up and running. After physically replacing the failed disk drive, the basic steps to restore your data are as follows: \begin{itemize} \item Boot from the OpenBSD install/boot floppy. At the menu selection, choose Shell. Write protect and insert your most recent back up tape into the drive. \item Using the fdisk(8) command, create a primary OpenBSD partition on this newly installed drive. Example: \begin{alltt}\# \textbf{fdisk -e sd0}\end{alltt} See Using \texttt{fdisk(8)}'' for more info. \item Using the disklabel command, recreate your OpenBSD partition table inside that primary OpenBSD partition you just created with fdisk. Example: \begin{alltt}\# \texttt{disklabel -E sd0}\end{alltt} (Don't forget swap, see Using OpenBSD's \texttt{disklabel(8)}'' for more info) \item Use the newfs command to build a clean file system on each partition you created in the above step. Example: \begin{alltt}\# \textbf{newfs /dev/rsd0a} \# \textbf{newfs /dev/rsd0h}\end{alltt} \item Mount your newly prepared root (\textbf{/}) file system on \textbf{/mnt}. Example: \begin{alltt}\# \textbf{mount /dev/sd0a /mnt}\end{alltt} \item Change into that mounted root file system and start the restore process. Example: \begin{alltt}\# \textbf{cd /mnt} \# \textbf{restore -rs 1 -f /dev/rst0}\end{alltt} \item You'll want this new disk to be bootable, use the following to write a new MBR to your drive. Example: \begin{alltt}\# \textbf{fdisk -i sd0}\end{alltt} \item In addition to writing a new MBR to the drive, you will need to install boot blocks to boot from it. The following is a brief example: \begin{alltt}\# \textbf{cp /usr/mdec/boot /mnt/boot} \# \textbf{/usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot sd0}\end{alltt} \item Your new root file system on the fixed disk should be ready enough so you can boot it and continue restoring the rest of your file systems. Since your operating system is not complete yet, be sure you boot back up with single user mode. At the shell prompt, issue the following commands to unmount and halt the system: \begin{alltt}\# \textbf{umount /mnt} \# \textbf{halt}\end{alltt} \item Remove the install/boot floppy from the drive and reboot your system. At the OpenBSD boot> prompt, issue the following command: \begin{alltt}boot\textgreater{} \textbf{bsd -s}\end{alltt} The \texttt{bsd -s} will cause the kernel to be started in single user mode which will only require a root (\texttt{/}) file system. \item Assuming you performed the above steps correctly and nothing has gone wrong you should end up at a prompt asking you for a shell path or press return. Press return to use sh. Next, you'll want to remount root in r/w mode as opposed to read only. Issue the following command: \begin{alltt}\# \texttt{mount -u -w /}\end{alltt} \item Once you have re-mounted in r/w mode you can continue restoring your other file systems. Example: \begin{alltt}(simple mount table) \# \textbf{mount /dev/sd0h /usr; cd /usr; restore -rs 2 -f /dev/rst0} (more advanced mount table) \# \textbf{mount /dev/sd0d /var; cd /var; restore -rs 2 -f /dev/rst0} \# \textbf{mount /dev/sd0e /home; cd /home; restore -rs 3 -f /dev/rst0} \# \textbf{mount /dev/sd0h /usr; cd /usr; restore -rs 4 -f /dev/rst0}\end{alltt} You could use "\texttt{restore rvsf}" instead of just rsf to view names of objects as they are extracted from the dump set. \item Finally after you finish restoring all your other file systems to disk, reboot into multiuser mode. If everything went as planned your system will be back to the state it was in as of your most recent back up tape and ready to use again. \end{itemize} \section{Mounting disk images in OpenBSD} To mount a disk image (ISO images, disk images created with \texttt{dd}, etc.) in OpenBSD you must configure a \texttt{vnd(4)} device. For example, if you have an ISO image located at \texttt{/tmp/ISO.image}, you would take the following steps to mount the image. \begin{alltt}\# \textbf{vnconfig vnd0 /tmp/ISO.image} \# \textbf{mount -t cd9660 /dev/vnd0c /mnt}\end{alltt} Notice that since this is an ISO-9660 image, as used by CDs and DVDs, you must specify type of \emph{cd9660} when mounting it. This is true, no matter what type, e.g. you must use type \emph{ext2fs} when mounting Linux disk images. To unmount the image use the following commands. \begin{alltt}\# \textbf{umount /mnt} \# \textbf{vnconfig -u vnd0}\end{alltt} For more information, refer to the \texttt{vnconfig(8)} man page. \section{Help! I'm getting errors with IDE DMA!} DMA IDE transfers, supported by \texttt{pciide(4)} are unreliable with many combinations of older hardware. OpenBSD is aggressive and attempts to use the highest DMA Mode it can configure. This will cause corruption of data transfers in some configurations because of buggy motherboard chipsets, buggy drives, and/or noise on the cables. Luckily, Ultra-DMA modes protect data transfers with a CRC to detect corruption. When the Ultra-DMA CRC fails, OpenBSD will print an error message and try the operation again. \begin{alltt}wd2a: aborted command, interface CRC error reading fsbn 64 of 64-79 (wd2 bn 127; cn 0 tn 2 sn 1), retrying\end{alltt} After failing a couple times, OpenBSD will downgrade to a slower (hopefully more reliable) Ultra-DMA mode. If Ultra-DMA mode 0 is hit, then the drive downgrades to PIO mode. UDMA errors are often caused by low quality or damaged cables. Cable problems should usually be the first suspect if you get many DMA errors or unexpectedly low DMA performance. It is also a bad idea to put the CD-ROM on the same channel with a hard disk. If replacing cables does not resolve the problem and OpenBSD does not successfully downgrade, or the process causes your machine to lock hard, or causes excessive messages on the console and in the logs, you may wish to force the system to use a lower level of DMA or UDMA by default. This can be done by using \texttt{UKC} or \texttt{config(8)} to change the flags on the \texttt{wd(4)} device. \section{Why does \texttt{df(1)} tell me I have over 100\% of my disk used?} People are sometimes surprised to find they have \emph{negative} available disk space, or more than 100\% of a filesystem in use, as shown by \texttt{df(1)}. When a filesystem is created with \texttt{newfs(8)}, some of the available space is held in reserve from normal users. This provides a margin of error when you accidently fill the disk, and helps keep disk fragmentation to a minimum. Default for this is 5\% of the disk capacity, so if the root user has been carelessly filling the disk, you may see up to 105% of the available capacity in use. If the 5\% value is not appropriate for you, you can change it with the \texttt{tunefs(8)} command. \section{Recovering partitions after deleting the disklabel} If you have a damaged partition table, there are various things you can attempt to do to recover it. Firstly, panic. You usually do so anyways, so you might as well get it over with. Just don't do anything stupid. Panic away from your machine. Then relax, and see if the steps below won't help you out. A copy of the disklabel for each disk is saved in \texttt{/var/backups} as part of the daily system maintenance. Assuming you still have the var partition, you can simply read the output, and put it back into disklabel. In the event that you can no longer see that partition, there are two options. Fix enough of the disc so you can see it, or fix enough of the disc so that you can get your data off. Depending on what happened, one or other of those may be preferable (with dying discs you want the data first, with sloppy fingers you can just have the label). The first tool you need is \texttt{scan\_ffs(8)} (note the underscore, it isn't called "scanffs"). \texttt{scan\_ffs(8)} will look through a disc, and try and find partitions and also tell you what information it finds about them. You can use this information to recreate the disklabel. If you just want \texttt{/var} back, you can recreate the partition for \texttt{/var}, and then recover the backed up label and add the rest from that. \texttt{disklabel(8)} will update both the kernel's understanding of the disklabel, and then attempt to write the label to disk. Therefore, even if the area of the disk containing the disklabel is unreadable, you will be able to \texttt{mount(8)} it until the next reboot. \section{Can I access data on filesystems other than FFS?} Yes. Other supported filesystems include: ext2 (Linux), ISO9660 and UDF (CD-ROM, DVD media), FAT (MS-DOS and Windows), NFS, NTFS (Windows). Some of them have limited, for instance read-only, support. We will give a general overview on how to use one of these filesystems under OpenBSD. To be able to use a filesystem, it must be mounted. For details and mount options, please consult the \texttt{mount(8)} manual page, and that of the mount command for the filesystem you will be mounting, e.g. \texttt{mount\_msdos}, \texttt{mount\_ext2fs}, \ldots First, you must know on which device your filesystem is located. This can be simply your first hard disk, wd0 or sd0, but it may be less obvious. All recognized and configured devices on your system are mentioned in the output of the \texttt{dmesg(1)} command: a device name, followed by a one-line description of the device. For example, my first CD-ROM drive is recognized as follows: \begin{alltt}cd0 at scsibus0 targ 0 lun 0: \textless{}COMPAQ, DVD-ROM LTD163, GQH3\textgreater{} SCSI0 5/cdrom removable\end{alltt} For a much shorter list of available disks, you can use \texttt{sysctl(8)}. The command \begin{alltt}\# sysctl hw.disknames\end{alltt} will show all disks currently known to your system, for example: \begin{alltt}hw.disknames=cd0:,cd1:,wd0:,fd0:,cd2:\end{alltt} At this point, it is time to find out which partitions are on the device, and in which partition the desired filesystem resides. Therefore, we examine the device using \texttt{disklabel(8)}. The disklabel contains a list of partitions, with a maximum number of 16. Partition c always indicates the entire device. Partitions a-b and d-p are used by OpenBSD. Partitions i-p may be automatically allocated to file systems of other operating systems. In this case, I'll be viewing the disklabel of my hard disk, which contains a number of different filesystems. \textbf{NOTE: OpenBSD was installed after the other operating systems} on this system, and during the install a disklabel containing partitions for the native as well as the foreign filesystems was installed on the disk. However, if you install foreign filesystems after the OpenBSD disklabel was already installed on the disk, you need to add or modify them manually afterwards. This will be explained in the The partitions are not in my disklabel! What should I do?'' subsection. \begin{alltt}\# \textbf{disklabel wd0} \# using MBR partition 2: type A6 off 20338290 (0x1365672) size 29318625 (0x1bf5de1) \# /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST340016A uid: d920a43a5a56ad5f flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 78165360 boundstart: 20338290 boundend: 49656915 drivedata: 0 16 partitions: \# size offset fstype [fsize bsize cpg] a: 408366 20338290 4.2BSD 2048 16384 16 # / b: 1638000 20746656 swap c: 78165360 0 unused d: 4194288 22384656 4.2BSD 2048 16384 16 # /usr e: 409248 26578944 4.2BSD 2048 16384 16 # /tmp f: 10486224 26988192 4.2BSD 2048 16384 16 # /var g: 12182499 37474416 4.2BSD 2048 16384 16 # /home i: 64197 63 unknown j: 20274030 64260 unknown k: 1975932 49656978 MSDOS l: 3919797 51632973 unknown m: 2939832 55552833 ext2fs n: 5879727 58492728 ext2fs o: 13783707 64372518 ext2fs\end{alltt} As can be seen in the above output, the OpenBSD partitions are listed first. Next to them are a number of ext2 partitions and one MSDOS partition, as well as a few 'unknown' partitions. On i386 and amd64 systems, you can usually find out more about those using the \texttt{fdisk(8)} utility. For the curious reader: partition i is a maintenance partition created by the vendor, partition j is a NTFS partition and partition l is a Linux swap partition. Once you have determined which partition it is you want to use, you can move to the final step: mounting the filesystem contained in it. Most filesystems are supported in the GENERIC kernel: just have a look at the kernel configuration file, located in the \texttt{/usr/src/sys/arch/\textless{}arch\textgreater{}/conf}directory. If you want to use one of the filesystems not supported in \texttt{GENERIC}, you will need to build a custom kernel. When you have gathered the information needed as mentioned above, it is time to mount the filesystem. Let's assume a directory \texttt{/mnt/otherfs} exists, which we will use as a mount point where we will mount the desired filesystem. In this example, we will mount the ext2 filesystem in partition m: \begin{alltt}\# \textbf{mount -t ext2fs /dev/wd0m /mnt/otherfs}\end{alltt} If you plan to use this filesystem regularly, you may save yourself some time by inserting a line for it in \texttt{/etc/fstab}, for example something like: \begin{alltt}/dev/wd0m /mnt/otherfs ext2fs rw,noauto,nodev,nosuid 0 0\end{alltt} Notice the 0 values in the fifth and sixth field. This means we do not require the filesystem to be dumped, and checked using fsck. Generally, those are things you want to have handled by the native operating system associated with the filesystem. \subsection{The partitions are not in my disklabel! What should I do?} If you install foreign filesystems on your system (often the result of adding a new operating system) after you have already installed OpenBSD, a disklabel will already be present, and it will not be updated automatically to contain the new foreign filesystem partitions. If you wish to use them, you need to add or modify these partitions manually using \texttt{disklabel(8)}. As an example, I have modified one of my existing ext2 partitions: using Linux's fdisk program, I've reduced the size of the 'o' partition (see disklabel output above) to 1G. We will be able to recognize it easily by its starting position (offset: 64372518) and size (13783707). Note that these values are sector numbers, and that using sector numbers (not megabytes or any other measure) is the most exact and safest way of reading this information. Before the change, the partition looked like this using OpenBSD's \texttt{fdisk(8)} utility (leaving only relevant output): \begin{alltt}\# fdisk wd0 . . . Offset: 64372455 Signature: 0xAA55 Starting Ending LBA Info: \#: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ 0: 83 4007 1 1 - 4864 254 63 [ 64372518: 13783707 ] Linux files* . . .\end{alltt} As you can see, the starting position and size are exactly those reported by \texttt{disklabel(8)} earlier. (Dont' be confused by the value indicated by "Offset": it is referring to the starting position of the extended partition in which the ext2 partition is contained.) After changing the partition's size from Linux, it looks like this: \begin{alltt}\# fdisk wd0 . . . Offset: 64372455 Signature: 0xAA55 Starting Ending LBA Info: \#: id C H S - C H S [ start: size ] ------------------------------------------------------------------------ 0: 83 4007 1 1 - 4137 254 63 [ 64372518: 2104452 ] Linux files* . . .\end{alltt} Now this needs to be changed using \texttt{disklabel(8)}. For instance, you can issue \texttt{disklabel -e wd0}, which will invoke an editor specified by the \texttt{EDITOR} environment variable (default is \texttt{vi}). Within the editor, change the last line of the disklabel to match the new size: \begin{alltt}o: 2104452 64372518 ext2fs\end{alltt} Save the disklabel to disk when finished. Now that the disklabel is up to date again, you should be able to mount your partitions as described above. You can follow a very similar procedure to add new partitions. \section{Can I use a flash memory device with OpenBSD?} \subsection{Flash memory as a portable storage device} Normally, the memory device should be recognized upon plugging it into a port of your machine. Shortly after inserting it, a number of messages are written to the console by the kernel. For instance, when I plug in my USB flash memory device, I see the following on my console: \begin{alltt}umass0 at uhub1 port 1 configuration 1 interface 0 umass0: LEXR PLUG DRIVE LEXR PLUG DRIVE, rev 1.10/0.01, addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets sd0 at scsibus2 targ 1 lun 0: \textless{}LEXAR, DIGITAL FILM, /W1.\textgreater{} SCSI2 0/direct removable sd0: 123MB, 512 bytes/sec, 251904 sec total\end{alltt} These lines indicate that the \texttt{umass(4)} (USB mass storage) driver has been attached to the memory device, and that it is using the SCSI system. The last two lines are the most important ones: they are saying to which device node the memory device has been attached, and what the total amount of storage space is. If you somehow missed these lines, you can still see them afterwards with the \texttt{dmesg(1)} command. The reported CHS geometry is a rather fictitious one, as the flash memory is being treated like any regular SCSI disk. We will discuss two scenarios below. \subsection*{The device is new/empty and you want to use it with OpenBSD only} You will need to initialize a disklabel onto the device, and create at least one partition. Please read Using OpenBSD's disklabel'' and the \texttt{disklabel(8)} manual page for details about this. In this example I created just one partition \texttt{a} in which I will place a FFS filesystem: \begin{alltt}\# newfs sd0a Warning: inode blocks/cyl group (125) \textgreater{}= data blocks (62) in last cylinder group. This implies 1984 sector(s) cannot be allocated. /dev/rsd0a: 249856 sectors in 122 cylinders of 64 tracks, 32 sectors 122.0MB in 1 cyl groups (122 c/g, 122.00MB/g, 15488 i/g) super-block backups (for fsck -b \#) at: 32,\end{alltt} Let's mount the filesystem we created in the \texttt{a} partition on \texttt{/mnt/flashmem}. Create the mount point first if it does not exist. \begin{alltt}\# \textbf{mkdir /mnt/flashmem} \# \textbf{mount /dev/sd0a /mnt/flashmem}\end{alltt} \subsection*{You received the memory device from someone with whom you want to exchange data} There is a considerable chance the other person is not using OpenBSD, so there may be a foreign filesystem on the memory device. Therefore, we will first need to find out which partitions are on the device, as described in Can I access data on filesystems other than FFS?'' section. \begin{alltt}\# \textbf{disklabel sd0} \# /dev/rsd0c: type: SCSI disk: SCSI disk label: DIGITAL FILM flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 123 total sectors: 251904 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: \# size offset fstype [fsize bsize cpg] c: 251904 0 unused 0 0 # Cyl 0 - 122 i: 250592 32 MSDOS # Cyl 0*- 122*\end{alltt} As can be seen in the disklabel output above, there is only one partition \texttt{i}, containing a FAT filesystem created on a Windows machine. As usual, the \texttt{c} partition indicates the entire device. Let's now mount the filesystem in the \texttt{i} partition on \texttt{/mnt/flashmem}. \begin{alltt}\# \textbf{mount -t msdos /dev/sd0i /mnt/flashmem}\end{alltt} Now you can start using it just like any other disk. \textbf{WARNING}: You should \textbf{always unmount} the filesystem \textbf{before unplugging} the memory device. If you don't, the filesystem may be left in an inconsistent state, which may result in data corruption. Upon detaching the memory device from your machine, you will again see the kernel write messages about this to the console: \begin{alltt}umass0: at uhub1 port 1 (addr 2) disconnected sd0 detached scsibus2 detached umass0 detached\end{alltt} \subsection{Flash memory as bootable storage} One can also use flash memory in various forms as bootable disk with OpenBSD. This can be done with both USB devices (assuming your computer can boot from a USB flash device, not all can), or with a non-USB (i.e., CF) device with an IDE or SATA adapter. (Non-USB devices attached with a USB adapter are treated as USB devices). In some cases, you may actually use a device in both ways (load the media in a USB adapter, but run it in an IDE adapter). A flash device attached to a USB port will show up as a \texttt{sd(4)} SCSI-like device. When attached to an IDE adapter, it will show up as a \texttt{wd(4)} device. In the case of flash media in an IDE adapter, it can be booted from any system that could boot from an IDE hard disk on the same adapter. In every sense, the system sees the flash media as an IDE disk. Simply configure the hardware appropriately, then install OpenBSD to the flash disk as normal. In the case of booting from a USB device, your system must be able to boot from the USB device without being distracted by other devices on the system. Note that if your intention is to make a portable boot environment on a USB device, you really want to use DUIDs, rather than the traditional "\texttt{/dev/sd0X}" notation. The USB device will show up as a SCSI disk, sometimes sd0. Without DUIDs, if you plug this device into a system which already has a few SCSI-like disks (i.e., devices attached to an \texttt{ahci(4)} interface) on it, it will probably end up with a different identifier, which will complicate carrying the flash device from system to system, as you would have to update \texttt{/etc/fstab}. Using DUIDs completely resolves this issue. Some notes: \begin{itemize} \item \textbf{Speed}: In general, flash devices are much slower than hard disks, especially when it comes to writing. Using soft updates will help this considerably, as will using the "noatime" mount option. \item \textbf{"Write fatigue"}: Much has been written about the finite number of times an individual flash cell can be rewritten before failure. Practically speaking, however, there are many ways a flash device can fail, write fatigue is just one of them. Modern flash devices will verify writes, and in the event of failure, will automatically remap the failed sectors with one of the many spare sectors. Most users with most flash devices will not have to worry about "write fatigue". You would probably experience more down time due to failure of "clever" tricks done to avoid writing to the flash drive than you will by just using the drives as read-write media. \item \textbf{Reliability}: The fact that flash media has no moving parts has prompted many people to assume the flash media is inherently more reliable than hard disks. It is not wise to assume that switching to flash means you don't need to worry about data loss or drive failure. People have reported considerable variation in flash media quality, it is probably best to consider flash storage as a silent and low-power alternative to disk rather than a failure-free storage media. \item \textbf{Creating a bootable USB flash drive}: While a USB device can only be booted on a machine which can boot from USB drives, it can be created on any machine with supported USB hardware. You will, of course, be unable to test your work until you can get to a USB bootable system. \item \textbf{Going from IDE to USB interfaces}: Since flash media can be readable and writable through USB, IDE and other adapters, you can create bootable media with one type of adapter but maintain or use it with another type of adapter. \item \textbf{Mixing OpenBSD and other partitions on one device}: OpenBSD treats the flash disk as any other disk so one can use \texttt{fdisk(8)} to partition a flash device, as you would any hard disk. You can then have OpenBSD file systems on one partition, and use another partition for another file system, for example, FAT32. However, not all OSs treat USB devices as "equals". Windows, at least, will not attempt to use or create a partition that doesn't start at the beginning of the device, nor will the Windows partitioning tools allow you to partition the disk, though it will respect existing partitions. So, if you wish to create a USB flash drive that is bootable with OpenBSD, but also functions as a FAT32-capable device on other OSs, you would want to do something like this: \begin{enumerate} \item Partition the media with OpenBSD's fdisk, creating a partition of the type you desire for Windows to use at the beginning of the disk, and an OpenBSD partition at the end of the disk. \item Install OpenBSD as normal to the OpenBSD fdisk partition, don't forget to flag the OpenBSD partition as "Active" for booting. \item Format the other partition. This can be (and perhaps should be) done on the "target" OS (Windows, in this case). \end{enumerate} Note that if the other partition's type is chosen appropriately, it is possible to have OpenBSD access both partitions on the device. So, a Windows user could populate the FAT32 partition with MP3 files which could be played when they booted from the OpenBSD partition. \end{itemize} \subsection{How do I create a bootable "Live" USB device?} It is very easy to create a bootable USB flash (or other!) drive that can be used as a "live" OpenBSD system without installing OpenBSD on the local hard disk of a machine. Obviously, the target machine must be bootable from a USB device, but the initial load can actually be done from any machine with a USB interface. Some reasons you may want to do this: \begin{itemize} \item A portable, secure "machine" you can carry with you in your pocket. \item Fix problems in OpenBSD and other installs with tools that aren't available with bsd.rd \item Evaluate hardware for OpenBSD compatibility at the point of purchase. \item Install machines that lack any other form of boot media. \item Collect dmesg outputs from your friend's computers! (As OpenBSD's dmesg is useful for identifying hardware, this can be a good way to prep for the install of OTHER OSs on a machine -- make sure you have all the needed drivers before starting). \end{itemize} Creating such a "live OpenBSD drive" is simple. \begin{itemize} \item Mount your USB drive to the machine you are installing from. \item Boot your favorite OpenBSD install media. \item Install as normal, being careful to select your flash drive as the install target. \item Boot from your newly created USB device. \end{itemize} That's it! There are some things you may want to do after the install to improve your results: \begin{itemize} \item Install all packages and utilities you are likely to wish to have available. \item Different target machines will likely have different NICs. You could create a bunch of \texttt{hostname.if(5)} files in \texttt{/etc}, each containing just \texttt{dhcp}, for all the NICs you are likely to encounter (\texttt{fxp0}, \texttt{re0}, \texttt{rl0}, \texttt{bge0}, \texttt{bnx0}, \texttt{em0}, etc.) on USB-bootable machines, plus maybe sample wireless config files as well. OpenBSD will ignore all \texttt{hostname.if(5)} files for devices not present at boot time. \item You may wish to have a copy of the install files and maybe any desired package \texttt{.tgz} files so you can use the drive as an install media (boot \texttt{bsd.rd} instead of letting it boot normally). \item On many machines, X will "Just Work" with no config file, but you may wish to collect X config files for those systems that require them. \item Soft updates will be something you will want to use. \item For maximum flexibility, you probably want to use i386 rather than amd64. However, if you wish to use it as an install media, you could have an amd64 bsd.rd and install files in addition to i386. \item Use DUIDs to identify your partitions. \item You may find it desirable to have a FAT partition on the USB drive, create it as detailed above. \item You may wish to use \texttt{softraid(4)} to encrypt a data partition. \end{itemize} \section{Optimizing disk performance} Disk performance is a significant factor in the overall speed of your computer. It becomes increasingly important when your computer is hosting a multi-user environment (users of all kinds, from those who log-in interactively to those who see you as a file-server or a web-server). Data storage constantly needs attention, especially when your partitions run out of space or when your disks fail. OpenBSD has a few options to increase the speed of your disk operations. \begin{itemize} \item Soft Updates \item Size of the \texttt{namei()} cache \end{itemize} \subsection{Soft updates} An important tool that can be used to speed up your system is softupdates. One of the slowest operations in the traditional BSD file system is updating metainfo (which happens, among other times, when you create or delete files and directories). Softupdates attempts to update metainfo in RAM instead of writing to the hard disk each and every single metainfo update. Another effect of this is that the metainfo on disk should always be complete, although not always up to date. You can read more about softupdates in the Softupdates entry. \subsection{Size of the \texttt{namei()} cache} The name-to-inode translation (a.k.a., \texttt{namei()}) cache controls the speed of pathname to \texttt{inode(5)} translation. A reasonable way to derive a value for the cache, should a large number of \texttt{namei()} cache misses be noticed with a tool such as \texttt{systat(1)}, is to examine the system's current computed value with \texttt{sysctl(8)}, (which calls this parameter "\texttt{kern.maxvnodes}") and to increase this value until either the \texttt{namei()} cache hit rate improves or it is determined that the system does not benefit substantially from an increase in the size of the \texttt{namei()} cache. After the value has been determined, you can set it at system startup time with \texttt{sysctl.conf(5)}. \section{Why aren't we using async mounts?} Question: "I simply do "\texttt{mount -u -o async /}" which makes one package I use (which insists on touching a few hundred things from time to time) usable. Why is async mounting frowned upon and not on by default (as it is in some other unixen)? Isn't it a much simpler, and therefore, a safer way of improving performance in some applications?" Answer: "Async mounts are indeed faster than sync mounts, but they are also less safe. What happens in case of a power failure? Or a hardware problem? The quest for speed should not sacrifice the reliability and the stability of the system. Check the man page for \texttt{mount(8)}." \begin{quote}async \\ All I/O to the file system should be done asynchronously. This is a dangerous flag to set since it does not guaran- tee to keep a consistent file system structure on the disk. You should not use this flag unless you are pre- pared to recreate the file system should your system crash. The most common use of this flag is to speed up restore(8) where it can give a factor of two speed in- crease.\end{quote} On the other hand, when you are dealing with temp data that you can recreate from scratch after a crash, you can gain speed by using a separate partition for that data only, mounted async. Again, do this \emph{only if} you don't mind the loss of all the data in the partition when something goes wrong. For this reason, \texttt{mfs(8)} partitions are mounted asynchronously, as they will get wiped and recreated on a reboot anyway.