Commits

Sevan Janiyan committed dd5e739

Changes from faq14.html r1.218 to 1.212

changed faq14.tex

  • Participants
  • Parent commits 133201b

Comments (0)

Files changed (1)

 
 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.
  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 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 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.
 
 \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 this reason, OpenBSD now defaults to starting the first partition at block 64 instead of 63.
+\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.
 
 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 drive to the system.
+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}
 
 
 \begin{alltt}probing: pc0 com0 com1 apm mem[636k 190M a20=on]
 disk: fd0 hd0+
-\textgreater{}\textgreater{} OpenBSD/i386 BOOT 3.02
+\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 a i386 system.
+\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
 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.15
+\textgreater{}\textgreater{} OpenBSD/i386 BOOT 3.17
 boot\textgreater{}
 booting hd0a:/bsd 4464500+838332 [58+204240+181750]=0x56cfd0
 entry point at 0x100120
         The Regents of the University of California.  All rights reserved.
 Copyright (c) 1995-2008 OpenBSD.  All rights reserved.  http://www.OpenBSD.org
 
-OpenBSD 4.9 (GENERIC) \#671: Wed Mar  2 07:09:00 MST 2011
+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}
 
 /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 SCSI fixed disk 0, partition a. The \texttt{/usr} filesystem resides on \texttt{sd0h}, which indicates SCSI fixed disk 0, partition h.
+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:
 
 
 \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{svnd(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.
+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 svnd0 /tmp/ISO.image}
-\# \textbf{mount -t cd9660 /dev/svnd0c /mnt}\end{alltt}
+\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 svnd0}\end{alltt}
+\# \textbf{vnconfig -u vnd0}\end{alltt}
 
 For more information, refer to the \texttt{vnconfig(8)} man page.
 
 
 \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)
+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. 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 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, the USB device will show up as a SCSI disk, sometimes \texttt{sd0}. However, 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 will have to update \texttt{/etc/fstab}.
+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:
 
 \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 If your target machine has an \texttt{ahci(4)} or SCSI interface, you will probably find your USB drive's identifier changing. Having multiple versions of your \texttt{/etc/fstab} file may make this easier to "fix" (in single user mode).
+\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}