This chapter provides overview information and step-by-step instructions about checking UFS file system consistency.This is a list of step-by-step instructions in this chapter.How to Check the root (/), /usr, or /var File Systems From an Alternate Boot Device How to Check Other File Systems (Not root (/), /usr, or /var) How to Preen a UFS File System How to Restore a Bad Superblock (Solaris 8, 9, and 10 Releases) How to Restore a Bad Superblock ( Solaris Express Release) This is a list of the overview information in this chapter.File System Consistency How the File System State Is Recorded What the fsck Command Checks and Tries to Repair Interactively Checking and Repairing a UFS File System Restoring a Bad Superblock Syntax and Options for the fsck Command For new information about fsck in the Solaris Express release, see Enhancements to UFS File System Utilities (fsck, mkfs, and newfs).For information about fsck error messages, see Chapter 20, Resolving UFS File System Inconsistencies (Tasks), in System Administration Guide: Advanced Administration.For background information on the UFS file system structures referred to in this chapter, see Chapter 22, UFS File System (Reference). The UFS file system relies on an internal set of tables to keep track of inodes used and available blocks. When these internal tables are not properly synchronized with data on a disk, inconsistencies result and file systems need to be repaired.File systems can be inconsistent because of abrupt termination of the operating system from the following:Power failure Accidental unplugging of the system Turning off the system without proper shutdown procedure A software error in the kernel File system inconsistencies, while serious, are not common. When a system is booted, a check for file system consistency is automatically performed (with the fsck command). Often, this file system check repairs problems it encounters.The fsck command places files and directories that are allocated but unreferenced in the lost+found directory. An inode number is assigned as the name of unreferenced file and directory. If the lost+found directory does not exist, the fsck command creates it. If there is not enough space in the lost+found directory, the fsck command increases its size.For a description of inodes, see Inodes. The fsck command uses a state flag, which is stored in the superblock, to record the condition of the file system. This flag is used by the fsck command to determine whether a file system needs to be checked for consistency. The flag is used by the /sbin/rcS script during booting and by the fsck m command. If you ignore the result from the fsck m command, all file systems can be checked regardless of the setting of the state flag. For a description of the superblock, see Superblock.The possible state flag values are described in the following table.State Flag Value Description FSACTIVE Indicates a mounted file system that has modified data in memory. A mounted file system with this state flag indicates that user data or metadata would be lost if power to the system is interrupted. FSBAD Indicates that the file system contains inconsistent file system data. FSCLEAN Indicates an undamaged, cleanly unmounted file system. FSLOG Indicates that the file system has logging enabled. A file system with this flag set is either mounted or unmounted. If a file system has logging enabled, the only flags that it can have are FSLOG or FSBAD. A file system that has logging disable can have FSACTIVE, FSSTABLE, or FSCLEAN. FSSTABLE Indicates an idle mounted file system. A mounted file system with this state flag indicates that neither user data nor metadata would be lost if power to the system is interrupted. This section describes what happens in the normal operation of a file system, what can go wrong, what problems the fsck command (the checking and repair utility) looks for, and how this command corrects the inconsistencies it finds.Every working day, hundreds of files might be created, modified, and removed. Each time a file is modified, the operating system performs a series of file system updates. These updates, when written to the disk reliably, yield a consistent file system.When a user program does an operation to change the file system, such as a write, the data to be written is first copied into an in-core buffer in the kernel. Normally, the disk update is handled asynchronously. The user process is allowed to proceed even though the data write might not happen until long after the write system call has returned. Thus, at any given time, the file system, as it resides on the disk, lags behind the state of the file system that is represented by the in-core information.The disk information is updated to reflect the in-core information when the buffer is required for another use or when the kernel automatically runs the fsflush daemon (at 30-second intervals). If the system is halted without writing out the in-core information, the file system on the disk might be in an inconsistent state.A file system can develop inconsistencies in several ways. The most common causes are operator error and hardware failures.Problems might result from an unclean shutdown, if a system is shut down improperly, or when a mounted file system is taken offline improperly. To prevent unclean shutdowns, the current state of the file systems must be written to disk (that is, “synchronized”) before you shut down the system, physically take a disk pack out of a drive, or take a disk offline.Inconsistencies can also result from defective hardware or problems with the disk or controller firmware. Blocks can become damaged on a disk drive at any time. Or, a disk controller can stop functioning correctly. This section describes the kinds of consistency checks that the fsck command applies to these UFS file system components: superblock, cylinder group blocks, inodes, indirect blocks, and data blocks.For information about UFS file system structures, see Structure of Cylinder Groups for UFS File Systems.The superblock stores summary information, which is the most commonly corrupted component in a UFS file system. Each change to file system inodes or data blocks also modifies the superblock. If the CPU is halted and the last command is not a sync command, the superblock almost certainly becomes corrupted.The superblock is checked for inconsistencies in the following: File system size Number of inodes Free block count Free inode count The file system size must be larger than the number of blocks used by the superblock and the list of inodes. The number of inodes must be less than the maximum number allowed for the file system. An inode represents all the information about a file. The file system size and layout information are the most critical pieces of information for the fsck command. There is no way to actually check these sizes because they are statically determined when the file system is created. However, the fsck command can check that the sizes are within reasonable bounds. All other file system checks require that these sizes be correct. If the fsck command detects corruption in the static parameters of the primary superblock, it requests the operator to specify the location of an alternate superblock.For more information about the structure of the UFS file system, see Structure of Cylinder Groups for UFS File Systems. Free blocks are stored in the cylinder group block maps. The fsck command checks that all the blocks marked as free are not claimed by any files. When all the blocks have been accounted for, the fsck command checks if the number of free blocks plus the number of blocks that are claimed by the inodes equal the total number of blocks in the file system. If anything is wrong with the block maps, the fsck command rebuilds them, leaving out blocks already allocated.The summary information in the superblock includes a count of the total number of free blocks within the file system. The fsck command compares this count to the number of free blocks it finds within the file system. If the counts do not agree, the fsck command replaces the count in the superblock with the actual free block count. Summary information in the superblock contains a count of the free inodes within the file system. The fsck command compares this count to the number of free inodes it finds within the file system. If the counts do not agree, fsck replaces the count in the superblock with the actual free inode count. The list of inodes is checked sequentially starting with inode 2. (Inode 0 and inode 1 are reserved). Each inode is checked for inconsistencies in the following:Format and type Link count Duplicate block Bad block numbers Inode size Each inode contains a mode word, which describes the type and state of the inode. Inodes might be one of nine types:Regular Directory Block special Character special FIFO (named pipe) Symbolic link Shadow (used for ACLs) Attribute directory Socket Inodes might be in one of three states:Allocated Unallocated Partially allocated When the file system is created, a fixed number of inodes are set aside. However, these inodes are not allocated until they are needed. An allocated inode is one that points to a file. An unallocated inode does not point to a file and, therefore, should be empty. The partially allocated state means that the inode is incorrectly formatted. An inode can get into this state if, for example, bad data is written into the inode list because of a hardware failure. The only corrective action the fsck command can take is to clear the inode. Each inode contains a count of the number of directory entries linked to it. The fsck command verifies the link count of each inode by examining the entire directory structure, starting from the root (/) directory, and calculating an actual link count for each inode.Discrepancies between the link count stored in the inode and the actual link count as determined by the fsck command might be one of three types:The stored count is not 0, and the actual count is 0.This condition can occur if no directory entry exists for the inode. In this case, the fsck command puts the disconnected file in the lost+found directory. The stored count is not 0 and the actual count is not 0. However, the counts are unequal.This condition can occur if a directory entry has been added or removed, but the inode has not been updated. In this case, the fsck command replaces the stored link count with the actual link count. The stored count is 0, and the actual count is not 0. In this case, the fsck command changes the link count of the inode to the actual count. Each inode contains a list, or pointers to lists (indirect blocks), of all the blocks claimed by the inode. Because indirect blocks are owned by an inode, inconsistencies in indirect blocks directly affect the inode that owns the indirect block.The fsck command compares each block number claimed by an inode to a list of allocated blocks. If another inode already claims a block number, the block number is put on a list of duplicate blocks. Otherwise, the list of allocated blocks is updated to include the block number. If duplicate blocks are found, the fsck command makes a second pass of the inode list to find the other inode that claims each duplicate block. The fsck command cannot determine with certainty which inode is in error. So, the fsck command prompts you to choose which inode should be kept and which inode should be cleared. Note that a large number of duplicate blocks in an inode might be caused by an indirect block not being written to the file system The fsck command checks each block number claimed by an inode to determine whether its value is higher than the value of the first data block and lower than that of the last data block in the file system. If the block number is outside this range, it is considered a bad block number. Bad block numbers in an inode might be caused by an indirect block not being written to the file system. The fsck command prompts you to clear the inode. Each inode contains a count of the number of data blocks that it references. The number of actual data blocks is the sum of the allocated data blocks and the indirect blocks. The fsck command computes the number of data blocks and compares that block count against the number of blocks that the inode claims. If an inode contains an incorrect count, the fsck command prompts you to fix it.Each inode contains a 64-bit size field. This field shows the number of characters (data bytes) in the file associated with the inode. A rough check of the consistency of the size field of an inode uses the number of characters shown in the size field to calculate how many blocks should be associated with the inode, and then compares that number to the actual number of blocks claimed by the inode. Indirect blocks are owned by an inode. Therefore, inconsistencies in an indirect block affect the inode that owns it. Inconsistencies that can be checked are the following:Blocks already claimed by another inode Block numbers outside the range of the file system These consistency checks listed are also performed for direct blocks. An inode can directly or indirectly reference three kinds of data blocks. All referenced blocks must be of the same kind. The three types of data blocks are the following: Plain data blocks Symbolic-link data blocks Directory data blocks Plain data blocks contain the information stored in a file. Symbolic-link data blocks contain the path name stored in a symbolic link. Directory data blocks contain directory entries. The fsck command can check only the validity of directory data blocks.Directories are distinguished from regular files by an entry in the mode field of the inode. Data blocks associated with a directory contain the directory entries. Directory data blocks are checked for inconsistencies involving the following: Directory inode numbers that point to unallocated inodes Directory inode numbers that are greater than the number of inodes in the file system Incorrect directory inode numbers for “.” and “..” directories Directories that are disconnected from the file system If the inode number in a directory data block points to an unallocated inode, the fsck command removes the directory entry. This condition can occur if the data blocks that contain a new directory entry are modified and written out, but the inode does not get written out. This condition can occur if the CPU is shut down abruptly. If a directory entry inode number points beyond the end of the inode list, the fsck command removes the directory entry. This condition can occur when bad data is written into a directory data block. The directory inode number entry for “.” must be the first entry in the directory data block. The directory inode number must reference itself. That is, its value must be equal to the inode number for the directory data block.The directory inode number entry for “..” must be the second entry in the directory data block. The directory inode number value must be equal to the inode number of the parent directory or the inode number of itself if the directory is the root (/) directory).If the directory inode numbers for “.” and “..” are incorrect, the fsck command replaces them with the correct values. If there are multiple hard links to a directory, the first hard link found is considered the real parent to which “..” should point. In this case, the fsck command recommends that you have it delete the other names. The fsck command checks the general connectivity of the file system. If a directory that is not linked to the file system is found, the fsck command links the directory to the lost+found directory of the file system. This condition can occur when inodes are written to the file system. However, the corresponding directory data blocks are not. Data blocks associated with a regular file hold the contents of the file. The fsck command does not attempt to check the validity of the contents of a regular file's data blocks. When you run the fsck command interactively and it completes successfully, a message similar to the following is displayed:# fsck /dev/rdsk/c0t0d0s7 ** /dev/rdsk/c0t0d0s7 ** Last Mounted on /export/home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups 2 files, 9 used, 2833540 free (20 frags, 354190 blocks, 0.0% fragmentation) # The last line of fsck output describes the following information about the file system:# filesNumber of inodes in use # usedNumber of fragments in use # freeNumber of unused fragments # fragsNumber of unused non-block fragments # blocksNumber of unused full blocks % fragmentationPercentage of fragmentation, where: free fragments x 100 / total fragments in the file system For information about fragments, see Fragment Size. You might need to interactively check file systems in the following instances:When they cannot be mounted When they develop inconsistencies while in use When an in-use file system develops inconsistencies, error messages might be displayed in the console window or the system messages file. Or, the system might crash. For example, the system messages file, /var/adm/messages, might include messages similar to the following:Sep 5 13:42:40 hostname ufs: [ID 879645 kern.notice] NOTICE: /: unexpected free inode 630916, run fsck(1M)hostname is the system reporting the error.Before using the fsck command, you might want to refer to these references for information on resolving fsck error messages:Syntax and Options for the fsck Command Chapter 20, Resolving UFS File System Inconsistencies (Tasks), in System Administration Guide: Advanced Administration Keep the following points in mind when running the fsck command to check UFS file systems:A file system should be inactive when you use fsck to check a file system. File system changes waiting to be flushed to disk or file system changes that occur during the fsck checking process can be interpreted as file system corruption. These issues may not be a reliable indication of a problem. A file system must be inactive when you use fsck to repair that file system. File system changes waiting to be flushed to disk or file system changes that occur during the fsck repairing process might cause the file system to become corrupted. Or, they might cause the system to crash. Unmount a file system before you use fsck on that file system. Doing so ensures that the file system data structures are consistent as possible. The only exceptions are for the active root (/), /usr, and /var file systems because they must be mounted to run fsck. If you need to repair the root (/), /usr, and /var file systems, boot the system from an alternate device, if possible, so that these file systems are unmounted and inactive.For step-by-step instructions on running fsck on the root (/), /usr, or /var file systems, see How 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). Become superuser or assume an equivalent role. 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. 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. 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 . . . # 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 . . . 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. If fsck cannot repair all of the problems after running it, see Fixing a UFS File System That the fsck Command Cannot Repair. 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. Bring the system back to multiuser mode.# init 6 For systems with mirrored root (/) file systems only: Reattach the root (/) mirror. 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 the file system to be checked is unmounted.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). Become superuser or assume an equivalent role. Unmount the local file system 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 . . . 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. If fsck cannot repair all of the problems after running it, see Fixing a UFS File System That the fsck Command Cannot Repair. Mount the repaired file system to determine 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. Rename and move any files put in the lost+found directory.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. The following example shows how to check the /dev/rdsk/c0t0d0s6 file system and correct the incorrect block count. This example assumes that the file system is unmounted.# fsck /dev/rdsk/c0t0d0s6 ** Phase 1 - Check Block and Sizes INCORRECT BLOCK COUNT I=2529 (6 should be 2) CORRECT? y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Cylinder Groups 929 files, 8928 used, 2851 free (75 frags, 347 blocks, 0.6% fragmentation) ***** FILE SYSTEM WAS MODIFIED ***** # The 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. This procedure assumes that the file system is unmounted or inactive. Become superuser or assume an equivalent role. Unmount the UFS file system.# umount /mount-point Check the UFS file system with the preen option.# fsck -o p /dev/rdsk/device-nameYou 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 until it no longer reports any problems. Doing so ensures that all errors have been found and repaired.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, 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 the following references:fsdb1M ff1M clri1M ncheck1M Ultimately, you might need to re-create the file system and restore its contents from backup media.For information about restoring complete file systems, see Chapter 26, 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 repartition the disk 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. However, if the disk is too severely damaged, the problems might persist, even after reformatting. For information about using the format command, see format1M. For information about installing a new disk, see Chapter 12, SPARC: Adding a Disk (Tasks) or Chapter 13, 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 these copies or use fsck's automatic search for backup superblocks feature, which is new in the Solaris Express release. For more information about this feature, see Automatic Search for Backup Superblocks.For more information about the superblock, see 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 by using the newfs command and restore it from a backup copy. This procedure is new in the Solaris Express release. If your file system has a bad superblock, fsck automatically calculates an alternative superblock as seen in the following messages:BAD SUPERBLOCK AT ... LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS?If a file system with a damaged superblock was created with newfs or mkfs customized parameters, such as ntrack or nsect, using fsck's automatically calculated superblock for the repair process could irreparably damage your file system.In the case of a file system that was created with customized parameters and it has a bad superblock, fsck provides the following prompt to cancel the fsck session:CANCEL FILESYSTEM CHECK?Canceling the fsck session would be an appropriate response if this file system was created with customized parameters or if there is some other concern about running fsck on this file system. Become superuser or assume an equivalent role. Check the file system with the suspected bad superblock.# fsck /dev/rdsk/c0t1d0s0 ** /dev/rdsk/c0t1d0s0 BAD SUPERBLOCK at ... Determine how the file system was created and select one of the following:The file system was created with the newfs command. fsck responds that all superblocks are corrupt and it must use a generic superblock. Answer the fsck prompts as described in the example below.Do not use this option if the file system was created with customized parameters. This option should only be used as a last resort. Be prepared to restore the file system from a backup copy. # fsck /dev/dsk/c1t2d0s0 ** /dev/rdsk/c1t2d0s0 BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? no LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? yes SEARCH FOR ALTERNATE SUPERBLOCKS FAILED. USE GENERIC SUPERBLOCK FROM MKFS? no USE GENERIC SUPERBLOCK FROM NEWFS? yes CALCULATED GENERIC SUPERBLOCK WITH NEWFS If filesystem was created with manually-specified geometry, using auto-discovered superblock may result in irrecoverable damage to filesystem and user data. CANCEL FILESYSTEM CHECK? no ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups CORRECT GLOBAL SUMMARY SALVAGE? y UPDATE STANDARD SUPERBLOCK? y 81 files, 3609 used, 244678 free (6 frags, 30584 blocks, 0.0% fragmentation) ***** FILE SYSTEM WAS MODIFIED ***** fsck responds that it found an alternate superblock with a message similar to the following:FOUND ALTERNATE SUPERBLOCK 32 WITH NEWFSWith this fsck scenario, follow the prompts as shown in Automatic Search for Backup Superblocks. The file system was created with the mkfs command.fsck responds that all superblocks are corrupt and must use a generic superblock. Answer the fsck prompts as described in the example below.Do not use this option if the file system was created with customized parameters. This option should only be used as a last resort. Be prepared to restore the file system from a backup copy. # fsck /dev/dsk/c1t2d0s0 ** /dev/rdsk/c1t2d0s0 BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? yes LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? no SEARCH FOR ALTERNATE SUPERBLOCKS FAILED. USE GENERIC SUPERBLOCK FROM MKFS? yes CALCULATED GENERIC SUPERBLOCK WITH MKFS If filesystem was created with manually-specified geometry, using auto-discovered superblock may result in irrecoverable damage to filesystem and user data. CANCEL FILESYSTEM CHECK? no ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups CORRECT GLOBAL SUMMARY SALVAGE? y UPDATE STANDARD SUPERBLOCK? y 81 files, 3609 used, 243605 free (117 frags, 30436 blocks, 0.0% fragmentation) fsck responds that it found an alternate superblock with a message similar to the following:FOUND ALTERNATE SUPERBLOCK 32 WITH MKFSWith this fsck scenario, follow the prompts as shown in Automatic Search for Backup Superblocks. Answer the prompts to salvage and restore the superblock.There is no need to rerun fsck when 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. Become superuser or assume an equivalent role. Determine whether the bad superblock is in the root (/), /usr, or /var file system and select one of the following:If the bad superblock is in either the root (/), /usr, or /var file system, then boot from the network or a locally connected CD.From a locally-connected CD, use the following command:ok boot cdrom -sFrom the network where a boot or install server is already setup, use the following command:ok boot net -sIf you need help stopping the system, see Chapter 10, Booting a System (Tasks), in System Administration Guide: Basic Administration or Chapter 12, Booting a Solaris System With GRUB (Tasks), in System Administration Guide: Basic Administration. If the bad superblock is not in either the root (/), /usr, /var file system, change to a directory outside the damaged file system and unmount the file system.# umount /mount-pointBe 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 by using the newfs -N command.# newfs -N /dev/rdsk/device-nameThe command output 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 Customizing UFS File System Parameters. Provide an alternate superblock by using the fsck command.# fsck -F ufs -o b=block-number /dev/rdsk/device-nameThe 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) ***** FILE SYSTEM WAS MODIFIED ***** # The fsck command checks and repairs inconsistencies in file systems. If you run the fsck command without any options, it interactively asks for confirmation before making repairs. This command has four options.Command and Option Description fsck m Checks whether a file system can be mounted fsck y Assumes a yes response for all repairs fsck n Assumes a no response for all repairs fsck o p Noninteractively preens the file system, fixing all expected (innocuous) inconsistencies, but exits when a serious problem is encountered