Source

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.