Restoring a Bad Superblock
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:
How to Restore a Bad Superblock ( Solaris Express Release)
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?
Caution - 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:
- 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.
How to Restore a Bad Superblock (Solaris 8, 9, and 10 Releases)
- 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 -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 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-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 by using the newfs -N command.
# newfs -N /dev/rdsk/device-name
The 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-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.
Example 22-3 Restoring a Bad Superblock (Solaris 8, 9, and 10 Releases)
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 *****
#
