test

System Administration Guide: Devices and File Systems

ProcedureHow to Check the root (/), /usr, or /var File Systems From an Alternate Boot Device

For new information about fsck in the Solaris Express release, see Enhancements to UFS File System Utilities (fsck, mkfs, and newfs). There is no need to rerun fsck if you see the following message:


***** FILE SYSTEM WAS MODIFIED *****

However, it doesn't harm the file system to rerun fsck after this message. This message is just informational about fsck's corrective actions.

This procedure assumes that a local CD or network boot server is available so that you can boot the system from an alternate device.

For information on restoring a bad superblock, see How to Restore a Bad Superblock ( Solaris Express Release) or How to Restore a Bad Superblock (Solaris 8, 9, and 10 Releases).

  1. Become superuser or assume an equivalent role.

  2. For systems with mirrored root (/) file systems only: Detach the root (/) mirror before booting from the alternate device, or you risk corrupting the file system.

    For information on detaching the root (/) mirror, see Working With Submirrors in Solaris Volume Manager Administration Guide.

  3. Identify the device, such as /dev/dsk/c0t0d0s0, of the root (/), /usr, or /var file system that needs to be checked.

    You'll need to supply this device name when booted from an alternate device. Identifying this device when you are already booted from the alternate device is more difficult.

  4. Boot the system with the root (/), /usr, or /var file system that needs to be checked from an alternate device, such as a local CD or the network, in single-user mode.

    Doing so ensures that there is no activity on these file systems.

    For example:


    # init 0
ok boot net -s
.
.
.
#

  5. Check the device that contains the root (/), /usr, or /var file system as identified in Step 3.

    If the hardware for the file system to be checked or repaired has changed, the device names might have changed. Check that the fsck -n message Last Mounted on ... indicates the expected device for the file system.

    In this example, the root (/) file system to be checked is /dev/dsk/c0t0d0s0. 


    # fsck -n /dev/rdsk/c0t0d0s0
** /dev/rdsk/c0t0d0s0 (NO WRITE)
** Last Mounted on /
.
.
.
fsck /dev/rdsk/c0t0d0s0
** /dev/rdsk/c0t0d0s0
** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
.
.
.

  6. Correct any reported fsck errors.

    For information on how to respond to the error message prompts while you interactively check one or more UFS file systems, see Chapter 20, Resolving UFS File System Inconsistencies (Tasks), in System Administration Guide: Advanced Administration.

  7. If fsck cannot repair all of the problems after running it, see Fixing a UFS File System That the fsck Command Cannot Repair.

  8. Mount the repaired file system to determine if any files exist in the lost+found directory.

    Individual files put in the lost+found directory by the fsck command are renamed with their inode numbers. If possible, rename the files and move them where they belong. Try to use the grep command to match phrases within individual files and the file command to identify file types.

    Eventually, remove unidentifiable files or directories left in the lost+found directory so that it doesn't fill up unnecessarily.

  9. Bring the system back to multiuser mode.


    # init 6

  10. For systems with mirrored root (/) file systems only: Reattach the root (/) mirror.