|
|||
|
 |
|
  |
|
  |
|
| ||||||||||
Example--Checking Non-root (/) or Non-/usr File Systems InteractivelyThe following example shows how to check the /dev/rdsk/c0t0d0s6 file system and corrects the incorrect block count. This example assumes that the file system is unmounted.
Preening UFS File SystemsThe fsck -o p command (p is for preen) checks UFS file systems and automatically fixes the problems that normally result from an unexpected system shutdown. This command exits immediately if it encounters a problem that requires operator intervention. This command also permits parallel checking of file systems. You can run the fsck -o p command to preen the file systems after an unclean shutdown. In this mode, the fsck command does not look at the clean flag and does a full check. These actions are a subset of the actions that the fsck command takes when it runs interactively.
|
# umount /mount-point |
Check the UFS file system with the preen option.
# fsck -o p /dev/rdsk/device-name |
You can preen individual file systems by using /mount-point or /dev/rdsk/device-name as arguments to the fsck command.
The following example shows how to preen the /export/home file system.
# fsck -o p /export/home |
The fsck command operates in several passes, and a problem corrected in a later pass can expose other problems that are only detected by earlier passes. Therefore, it is sometimes necessary to run fsck repeatedly until it no longer reports any problems, to ensure that all errors have been found and repaired. The fsck command does not keep running until it comes up clean, so you must rerun it manually.
Pay attention to the information displayed by the fsck command. This information might help you fix the problem. For example, the messages might point to a damaged directory. If you delete the directory, you might find that the fsck command runs cleanly.
If the fsck command still cannot repair the file system, you can try to use the ff, clri, and ncheck commands to figure out and fix what is wrong. For information about how to use these commands, see fsdb(1M), ff(1M), clri(1M), and ncheck(1M). You might, ultimately, need to re-create the file system and restore its contents from backup media.
For information about restoring complete file systems, see Chapter 49, Restoring Files and File Systems (Tasks).
If you cannot fully repair a file system but you can mount it read-only, try using the cp, tar, or cpio commands to retrieve all or part of the data from the file system.
If hardware disk errors are causing the problem, you might need to reformat and divide the disk into slices again before re-creating and restoring file systems. Check that the device cables and connectors are functional before replacing the disk device. Hardware errors usually display the same error again and again across different commands. The format command tries to work around bad blocks on the disk. If the disk is too severely damaged, however, the problems might persist, even after reformatting. For information about using the format command, see format(1M). For information about installing a new disk, see Chapter 34, SPARC: Adding a Disk (Tasks) or Chapter 35, x86: Adding a Disk (Tasks).
When the superblock of a file system becomes damaged, you must restore it. The fsck command tells you when a superblock is bad. Fortunately, copies of the superblock are stored within a file system. You can use the fsck -o b command to replace the superblock with one of the copies.
For more information about the superblock, see The Superblock.
If the superblock in the root (/) file system becomes damaged and you cannot restore it, you have two choices:
Reinstall the system
Boot from the network or local CD, and attempt the following steps. If these steps fail, recreate the root (/) file system with the newfs command and restore it from a backup copy.
How to Restore a Bad SuperblockBecome superuser or assume an equivalent role.
Determine whether the bad superblock is in the root (/) or /usr file system and select one of the following:
Stop the system and boot from the network or a locally-connected CD if the bad superblock is in the root (/) or /usr file system.
From a locally-connected CD, use the following command:
ok boot cdrom -s |
From the network where a boot or install server is already setup, use the following command:
ok boot net -s |
If you need help stopping the system, see SPARC: How to Stop the System for Recovery Purposes or x86: How to Stop a System for Recovery Purposes.
Change to a directory outside the damaged file system and unmount the file system if the bad superblock is not in the root (/) or /usr file system.
# umount /mount-point |
Caution - Be sure to use the newfs -N in the next
step. If you omit the -N option, you will destroy all of the
data in the file system and replace it with an empty file system.
Display the superblock values with the newfs -N command.
# newfs -N /dev/rdsk/device-name |
The output of this command displays the block numbers that were used for the superblock copies when the newfs command created the file system, unless the file system was created with special parameters. For information on creating a customized file system, see Custom File System Parameters.
Provide an alternate superblock with the fsck command.
# fsck -F ufs -o b=block-number /dev/rdsk/device-name |
The fsck command uses the alternate superblock you specify to restore the primary superblock. You can always try 32 as an alternate block, or use any of the alternate blocks shown by the newfs -N command.
The following example shows how to restore the superblock copy 5264.
# newfs -N /dev/rdsk/c0t3d0s7 /dev/rdsk/c0t3d0s7: 163944 sectors in 506 cylinders of 9 tracks, 36 sectors 83.9MB in 32 cyl groups (16 c/g, 2.65MB/g, 1216 i/g) super-block backups (for fsck -b #) at: 32, 5264, 10496, 15728, 20960, 26192, 31424, 36656, 41888, 47120, 52352, 57584, 62816, 68048, 73280, 78512, 82976, 88208, 93440, 98672, 103904, 109136, 114368, 119600, 124832, 130064, 135296, 140528, 145760, 150992, 156224, 161456, # fsck -F ufs -o b=5264 /dev/rdsk/c0t3d0s7 Alternate superblock location: 5264. ** /dev/rdsk/c0t3d0s7 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 36 files, 867 used, 75712 free (16 frags, 9462 blocks, 0.0% fragmentation) /dev/rdsk/c0t3d0s7 FILE SYSTEM STATE SET TO OKAY ***** FILE SYSTEM WAS MODIFIED ***** # |
 Previous Contents Index Next  |