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

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.

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 (/) or /usr file system that needs to be checked.

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

4. Boot the system with the root (/) or /usr file system that needs to be checked from an alternate device, such as a local CD or the network, in single-user mode to ensure 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 (/) or /usr 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. Be sure to check that the fsck -n message Last Mounted on ... indicates the expected device for the file system.

   For 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 about how to respond to the error message prompts while interactively checking one or more UFS file systems, see "Resolving UFS File System Inconsistencies (Tasks)" in System Administration Guide: Advanced Administration.

7. If necessary, run the fsck command again if you see messages similar to the following, FILE SYSTEM STATE NOT SET TO OKAY or FILE SYSTEM MODIFIED.

   The fsck command might be unable to fix all errors in one execution.

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

8. Mount the repaired file system to see if there are any files 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. You might be able 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 it doesn't fill it up unnecessarily.

9. Bring the system back to multi-user mode.

   # init 6

   
   

   If you press Control-D when booted in single-user mode from an alternate device, the system will start the Solaris installation process.

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

How to Check Non-root (/) or Non-/usr File Systems

This procedure assumes that the file system to be checked is unmounted.

For information on restoring a bad superblock, see How to Restore a Bad Superblock.

1. Become superuser or assume an equivalent role.

2. Unmount the local file system first to ensure that there is no activity on the file system.

   Specify the mount point directory or /dev/dsk/device-name as arguments to the fsck command. Any inconsistency messages are displayed.

   For example:

   # umount /export/home # fsck /dev/rdsk/c0t0d0s7 ** /dev/dsk/c0t0d0s7 ** Last Mounted on /export/home . . .

   
   

3. Correct any reported fsck errors.

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

4. If necessary, run the fsck command again if you see the following messages, FILE SYSTEM STATE NOT SET TO OKAY or FILE SYSTEM MODIFIED.

   The fsck command might be unable to fix all errors in one execution.

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

5. Mount the repaired file system to see if there are any files 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. You might be able 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 it doesn't fill it up unnecessarily.

6. Rename and move any files put in the lost+found directory.