Hard disk installation and configuration on Solaris is often more complicated than other UNIX systems. However, this complexity is required to support the sophisticated hardware operations typically undertaken by Solaris systems. For example, Linux refers to hard disks using a simple BSD-style scheme: /dev/hdn are the IDE hard disks on a system, and /dev/sdn are the SCSI hard disks on a system, where n refers to the hard disk number. A system with two IDE hard disks and two SCSI hard disks will therefore have the following device files configured:


Partitions created on each drive are also sequentially numbered: if /dev/hda is the boot disk, it may contain several partitions on the disk, reflecting the basic UNIX system directories:

/dev/hda1 (/ partition)
/dev/hda2 (/usr)
/dev/hda3 (/var)
/dev/hda4 (swap)

Instead of simply referring to the disk type, disk number, and partition number, the device filename for each partition (“slice”) on a Solaris disk contains four identifiers: controller (c), target (t), disk (d), and slice (s). Thus, the device file


identifies slice 0 of disk 0, controller 0 at SCSI target ID 3. To complicate matters further, disk device files exist in both the /dev/dsk and /dev/rdsk directories, which correspond to block device and raw device entries, respectively. Raw and block devices refer to the same physical partition, but are used in different contexts: using raw devices only allows operations of small amounts of data, whereas a buffer can be used with a block device to increase the data read size. It is not always clear whether to use a block or raw device interface, but low-level system commands (like the fsck command, which performs disk maintenance) typically use raw device interfaces.

Commands that operate on the entire disk (such as df, which reports disk usage) will most likely use block devices.

To install a new hard drive on a Solaris system, just follow these steps:

  1. Prepare the system for a reconfiguration boot, by issuing this command:

    # touch /reconfigure
  2. Synchronize disk data, and power down the system using this command:

    # sync; init 0
  3. Switch off power to the system and attach the new hard disk to the external SCSI chain, or install it internally into an appropriate disk bay.

  4. Check that the SCSI device ID does not conflict with any existing SCSI devices. If a conflict exists, simply change the ID using the switch;

  5. Power on the system, and use the boot command to load the kernel, if the OpenBoot monitor appears:

    ok boot

The next step, assuming that you have decided which partitions you wish to create on your drive, using the information supplied above, is to run the format program. In addition to creating slices, format also displays information about existing disks and slices, and can be used to repair a faulty disk. When format is invoked without a command-line argument:

# format

it displays a list of the current disks, and asks the administrator to enter the number of the disk to format. Selecting a disk for formatting at this point is nondestructive, so even if you make a mistake you can always exit the format program without damaging data. For example, on a SPARC-20 system with three 1.05G SCSI disks, format opens with the screen:

Searching for disks...done
0. c0t1d0 <SUN1.05 cyl 2036 alt 2 hd 14 sec 72>
1. c0t2d0 <SUN1.05 cyl 2036 alt 2 hd 14 sec 72>
2. c0t3d0 <SUN1.05 cyl 2036 alt 2 hd 14 sec 72>
Specify disk (enter its number):

It is also possible to pass a command-line option to format, comprising the disk (or disks) to be formatted—for example:

# format /dev/rdsk/c0t2d0

After selecting the appropriate disk, the message

[disk formatted]

will appear if the disk has previously been formatted. This is an important message, as it is a common mistake to misidentify a target disk from the available selection of both formatted and unformatted disks. The menu looks like this:

        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        fdisk      - run the fdisk program
        repair     - repair a defective sector
        show       - translate a disk address
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        save       - save new disk/partition definitions
        volname    - set 8-character volume name
        !<cmd>     - execute <cmd>, then return

If the disk has not been formatted, the first step is to prepare the disk to contain slices and file systems by formatting the disk, by issuing the command format:

format> format
Ready to format. Formatting cannot be interrupted
and takes 15 minutes (estimated). Continue? yes

The purpose of formatting is to identify defective blocks, and mark them as bad, and generally to verify that the disk is operational from a hardware perspective. Once this has been completed, new slices can be created and sized by using the “partition” option at the main menu:

format> partition

In this case, we want to create a new slice 5 on disk 0 at target 3, which will be used to store user files when mounted as /export/home, and corresponding to block device /dev/dsk/c0t2d0s5. After determining the maximum amount of space available, enter that size in gigabytes (in this case, 1.05g) when requested to do so by the format program for slice 5 (enter 0 for the other slices). If the disk is not labeled, you will also be prompted to enter a label that contains details of the disk’s current slices, which is useful for recovering data. This is an important step, as the operating system will not be able to find any newly created slices unless the volume is labeled. To view the disk label, use the prtvtoc command. Here’s the output from the primary drive in an x86 system:

# prtvtoc /dev/dsk/c0d0s2
* /dev/dsk/c0d0s2 partition map
* Dimensions:
*     512 bytes/sector
*      63 sectors/track
*     255 tracks/cylinder
*   16065 sectors/cylinder
*    1020 cylinders
*    1018 accessible cylinders
* Flags:
*   1: unmountable
*  10: read-only
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00      48195    160650    208844   /
       1      7    00     208845     64260    273104   /var
       2      5    00          0  16354170  16354169
       3      3    01     273105    321300    594404
       6      4    00     594405   1317330   1911734   /usr
       7      8    00    1911735  14442435  16354169   /export/home
       8      1    01          0     16065     16064
       9      9    01      16065     32130     48194

The disk label contains a full partition table, which can be printed for each disk using the print command:

format> print

For our 1.05g disk, the partition table will look like this:

Part Tag Flag Cylinders Size Blocks
0 root wm 0 0 (0/0/0) 0
1 swap wu 0 0 (0/0/0) 0
2 backup wm 0 - 3732 (3732/0/0) 2089920
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 home wm 0 - 3732 1075MB (3732/0/0) 2089920
6 usr wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0

After saving the changes to the disk’s partition table, exit the format program and create a new UFS file system on the target slice using the newfs command:

# newfs /dev/rdsk/c0t2d0s5

For large disks, the –m flag should be used. After a new file system is constructed, it is ready to be mounted. First, a mount point is created

# mkdir /export/home

followed by the appropriate mount command:

# mount /dev/dsk/c0t2d0s5 /export/home

At this point, the disk is available to the system for the current session. However, if you want the disk to be available after reboot, it is necessary to create an entry in the virtual file systems table, which is created from /etc/vfstab file. An entry like

/dev/dsk/c0t2d0s5 /dev/rdsk/c0t2d0s5 /export/home ufs 2 yes –

contains details of the slice’s block and raw devices, the mount point, the file system type, instructions for fsck, and most importantly, a flag to force mount at boot. If you require a journaling file system, then you would need to include the logging flag here.

For an x86 system, the output of format looks slightly different, given the differences in the way that devices are denoted:

       0. c0d0 <DEFAULT cyl 1018 alt 2 hd 255 sec 63>
Specify disk (enter its number):

The partition table is similar to that for the SPARC architecture systems:

partition> print
Current partition table (original):
Total disk cylinders available: 1018 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders        Size            Blocks
  0       root    wm       3 -   12       78.44MB    (10/0/0)     160650
  1        var    wm      13 -   16       31.38MB    (4/0/0)       64260
  2     backup    wm       0 - 1017        7.80GB    (1018/0/0) 16354170
  3       swap    wu      17 -   36      156.88MB    (20/0/0)     321300
  4 unassigned    wm       0               0         (0/0/0)           0
  5 unassigned    wm       0               0         (0/0/0)           0
  6        usr    wm      37 -  118      643.23MB    (82/0/0)    1317330
  7       home    wm     119 - 1017        6.89GB    (899/0/0)  14442435
  8       boot    wu       0 -    0        7.84MB    (1/0/0)       16065
  9 alternates    wu       1 -    2       15.69MB    (2/0/0)       32130

Mounting Local File Systems

Solaris (UNIX File System, or UFS) file systems are mapped in a one-to-one relationship to physical slices, which makes it easy for you to associate file systems with partitions, even if the physical and logical device references are complex. For example, the slice /dev/dsk/c0t2d0s5 may be mounted on the mount point /export/home.

Mount points are simply empty directories that have been created using the mkdir command. One of the nice features of the UFS is that it has a one-to-many mapping to potential mount points: this means that a file system can be mounted, and its files and directories can be manipulated, unmounted, and then remounted on a different mount point. All of the data that was modified when the file system was mounted using a different mount point are retained. For example, if you mount /dev/dsk/c0t2d0s5 on /export/ home, create a directory called pwatters (that is, /export/home/pwatters), unmount the file system, and then remount it on /usr/local, the content of the folder pwatters will still be available, albeit with a new absolute path (/usr/local/pwatters).

The following procedure can be used to mount a local file system:

# mkdir /export/home
# mount  /dev/dsk/c0t2d0s5 /export/home
# cd /export/home
# mkdir pwatters
# ls 

There is also nothing stopping you from mounting the file system on a different mount point, preserving all data:

# umount /export/home
# mkdir /usr/local
# mount  /dev/dsk/c0t2d0s5 /usr/local
# cd /usr/local
# ls

The mkdir command is used to create mount points, which are equivalent to directories. If you wish to make a mount point one level below an existing directory, you can use the mkdir command with no options. However, if you want to make a mount point several directory levels below an existing directory, you will need to pass the option –p to the mkdir command. For example, the following command will create the mount point /staff, since the parent / directory already exists:

# mkdir /staff

However, to create the mount point /staff/nfs/pwatters, you would use the –p option, if the directory /staff/nfs did not already exist:

# mkdir -p /staff/nfs/pwatters

Once a mount point has been created, the mount command is used to attach the file system to the mount point. For example, to mount the file system /dev/dsk/c0t3d0s5 on the mount point /export/home, you would use the following command:

# mount  /dev/dsk/c0t2d0s5 /export/home

The mount command assumes a UFS will be mounted. If the target file system is non-UFS, an option specifying the file system type will need to be passed on the command line using the –F options. Supported file system types include:

  • nfs Network File System (NFS)

  • pcfs MS-DOS formatted file system

  • s5fs System V compliant file system

Details of all currently mounted files are kept in the /etc/mnttab file. This file should never be directly edited, even by the superuser. The /etc/mnttab file will contain entries similar to the following:

# cat /etc/mnttab
/dev/dsk/c0t0d0s0 / ufs rw,intr,largefiles,suid,dev=1100000 921334412
/proc /proc proc dev=2280000 922234443
fd /dev/fd fd rw,suid,dev=2240000 922234448
mnttab /etc/mnttab mntfs dev=2340000 922234442
swap /tmp tmpfs dev=1 922234451
/dev/dsk/c0t0d0s5 /usr ufs rw,intr,onerror=panic,suid,dev=1100005 922234441

Unmounting Local File Systems

In normal operations, a file system is mounted at boot time if its mount point and options are specified in the virtual file systems table (/etc/vfstab). The file system is unmounted before the system is shut down. However, at times, you may find it necessary to unmount a file system manually. For example, if the file system’s integrity needs to be checked using the fsck command, the target file system must be unmounted. Alternatively, if the mount point of a file system is going to be modified, the file system needs to be unmounted from its current mount point and remounted on the new mount point.


You cannot mount a file system on two different mount points.

Configuring /etc/vfstab

If you want a disk to be available after reboot, you must create an entry in the virtual file systems table (/etc/vfstab). An entry like this

/dev/dsk/c0t2d0s5 /dev/rdsk/c0t2d0s5 /export/home ufs 2 yes -

contains details of the slice’s block and raw devices, the mount point, the file system type, instructions for fsck, and most importantly a flag to force the mount at boot.


These options are largely equivalent to those used with the mount command.

All file systems, including floppy disks, can be listed in the virtual file systems table. The mount point configuration for the floppy drive is typically similar to the following:

fd  -  /dev/fd  fd  -  no  -

Instead of mounting file systems individually using the mount command, all file systems defined in /etc/vfstab can be mounted by using the mountall command:

# mountall
mount: /tmp already mounted
mount: /dev/dsk/c0t0d0s5 is already mounted

This attempts to mount all listed file systems, and reports file systems that have previously been mounted. Obviously, file systems that are currently mounted cannot be mounted twice.


The mount command, executed without any options, provides a list of all mounted file systems:

# mount
/ on /dev/dsk/c0t0d0s0 read/write/setuid/intr/largefiles/onerror=
    panic on Tue Jul 10 09:10:01 2001
/usr on /dev/dsk/c0t0d0s6 read/write/setuid/intr/largefiles/
    onerror=panic on Tue Jul 10 09:10:02 2001
/proc on /proc read/write/setuid on Tue Jul 10 09:10:03 2001
/etc/mnttab on mnttab read/write/setuid on Tue Jul 10 09:10:04 2001
/tmp on swap read/write/setuid on Tue Jul 10 09:10:05 2001
/export/home on /dev/dsk/c0t0d0s7 read/write/setuid/intr/largefiles
    /onerror=panic on Tue Jul 10 09:10:06 2001

The mount command has several options, which are described below. These can also be used to specify mounting options in /etc/vfstab:


If mounting initially fails, continue to attempt mounting in the background. Useful for mounting NFS volumes where the server is temporarily unavailable. The default is fg, which attempts to mount in the foreground.


Specifies that hard mounting is attempted, where requests to mount are continually sent. The alternative is soft, which just returns an error message.


Allows keyboard commands to be used during mounting. To switch this off, use nointr.


Enables support for large file systems (those greater than 2GB in size). To remove support for large file systems, the nolargefiles option is used.


Allows a log of all UFS transactions to be maintained. In the event of a system crash, the log can be consulted and all transactions verified. This virtually eliminates the need to run lengthy fsck passes on file systems at boot. The default option is nologging since logs occupy around 1 percent of file system space.


Prevents access timestamps from being touched on files. This significantly speeds up access times on large file systems with many small files.


Permits a file system’s properties to be modified while it is still mounted, reducing downtime.


Specifies the number of attempts to remount a file system.


Specifies that the file system is to be mounted as read-write. Some file systems, however, are read-only (such as CD-ROMs). In this case, the ro option should be specified. Note that it is not physically possible to write to a read-only file system.


Permits set user ID applications to be executed from the file system, while nosuid prevents set user ID applications from executing.


Unmounting local file systems is easy using the umount command. The file system to be unmounted is specified on the command line. For example, to unmount the file system mounted on /export/home, the following command would be used:

# umount /export/home

However, if there are open files on the file system, or users logging into their home directories on the target file system, it’s obviously a bad idea to unmount the file system without giving users some kind of notice. It’s also important to determine whether other processes are using files on the file system. In fact, umount requires that no processes have files open on the target file system. The fuser command can be used to determine which users are accessing a particular file system. For example, to determine whether any processes have open files on the /export/home partition, the following command could be used:

# fuser -c /export/home

To give a listing of the UIDs associated with each process, the following command could be used:

# fuser -c -u /export/home

To warn users about the impending unmounting of the file system, the wall command can be used to send a message to all logged in users. For example, the following message could be sent:

# wall
Attention all users
/export/home is going down for maintenance at 6:00 p.m.
Please kill all processes accessing this file system (or I will)

At 6 P.M., a fuser check should show that no processes are accessing the file system. However, if some users did not heed the warning, the fuser command can be used to kill all processes that are still active:

# fuser -c -k /export/home

Alternatively, umount –f might be used. This is obviously a drastic step, but it may be necessary in emergency or urgent repair situations.

To save time, if you wish to unmount all user file systems (excluding /, /proc, /usr, and /var), you could use the umountall command:

# umountall

This command unmounts only file systems that are listed in the virtual file system table, except the aforementioned exclusions.

Part I: Solaris 9 Operating Environment, Exam I