Error file system creation failed for / c0t0d0s0. . . any ideas?
Can any one tell me what these error messages mean and what to do to fix this problem? "Error file system creation failed for / c0t0d0s0.. could not check or create system critical file system. Could not update disk with new configuration."
I have an Ultra 5 server that had two 9 GB IDE disk installed (mirrored). After a power outage, the system would not boot to the primary or mirrored drive. To make a long story short, I have one disk installed now. When I attempt to installed OS 9 using suninstall, it gets to the part where it trys to configure disk c0t0d0.. create disk label (VTOC); create and check UFS file system; create / (c0t0d0s0).. Then I get an error "Error file system creation faile for / c0t0d0s0. . ."
----------------------
Here's the output of the command " probe-ide"
Device 0 (Primary Master)
ATA Model: ST9140A
Device 1 (Priary Slave)
Device 2 (Secondary Master)
Removable ATAPI Model: CRD-8322B
Device 3 (Seconary Slave)
not present
I have an Ultra 5 server that had two 9 GB IDE disk installed (mirrored). After a power outage, the system would not boot to the primary or mirrored drive. To make a long story short, I have one disk installed now. When I attempt to installed OS 9 using suninstall, it gets to the part where it trys to configure disk c0t0d0.. create disk label (VTOC); create and check UFS file system; create / (c0t0d0s0).. Then I get an error "Error file system creation faile for / c0t0d0s0. . ."
----------------------
Here's the output of the command " probe-ide"
Device 0 (Primary Master)
ATA Model: ST9140A
Device 1 (Priary Slave)
Device 2 (Secondary Master)
Removable ATAPI Model: CRD-8322B
Device 3 (Seconary Slave)
not present
ASKER
Yuzh,
I get this message when I try to fsck on c0t0d0s0.
** /dev/rdsk/c0t0d0s0
BAD SUPER BLOCK: MAGIC NUMBER WRONG
USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; ...
What does this mean?
I get this message when I try to fsck on c0t0d0s0.
** /dev/rdsk/c0t0d0s0
BAD SUPER BLOCK: MAGIC NUMBER WRONG
USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; ...
What does this mean?
What it mean is that filesystem was corrupt (the Super block is damaged).
Try to run:
fsck -F ufs /dev/rdsk/c0t0d0s0
again, if it come back with "USE AN ALTERNATE SUPER-BLOCK "
run
newfs -Nv /dev/rdsk/c0t0d0s0
it will will generate a list of alternate superblocks. Then do:
fsck -F ufs -o b= /dev/rdsk/c0t0d0s0
IF you have good data backup, you can run:
newfs /dev/rdsk/c0t0d0s0
to rebuild the file system (all you date will LOST!!!)
also have a look at the following Sun doc to learn more:
Document ID Synopsis Date
ID74314 Solaris[TM] Operating System: The fsck Command Cannot Find the Superblock 16 Jun 2004
--------------------------
Keyword(s):superblock, bad, fix, fsck, newfs, bad magic number, filesystem
Problem Statement Top
The ufs filesystems contain the following types of blocks:
boot block: The boot block stores information used to boot the system.
superblock: Much of the filesystems internal information is stored in superblocks.
inode: The inode stores location information about a file--everything except for the file name. The number of inodes in a filesystem can be changed from the default if newfs -i is used to create the filesystem.
data block: The file's data is stored in data blocks.
Filesystem corruption can be detected and often repaired by the format and fsck commands. Sometimes the fsck command complains that it cannot find the superblock. Alternative superblock locations were created by newfs at the time that the filesystem was created. The newfs -N command can be invoked to nondestructively discover the superblock locations for the filesystem.
Here are errors you can get:
clean flag in superblock is wrong: fix?
File system state in superblock is wrong fix?
Bad magic number
wrong magic number
Resolution Top
If the superblock is corrupted, the file system can still be repaired using alternate superblocks that are formed while making the new file system. Superblock numbers can be found using the following command:
newfs -Nv /dev/rdsk/c?t?d?s?
Caution: If the "n" option is used, the filesystem may be destroyed.
Newfs -N shows superblock backups. Refer to the following example:
newfs -Nv /dev/rdsk/c0t0d0s0
mkfs -F ufs -o N /dev/rdsk/c0t0d0s0 15440544 63 16 8192 1024 224 1 90 8192 t 0 -1 8 16
/dev/rdsk/c0t0d0s0: 15440544 sectors in 15318 cylinders of 16 tracks, 63 sectors
7539.3MB in 175 cyl groups (88 c/g, 43.31MB/g, 5504 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 88800, 177568, 266336, 355104, 443872, 532640, 621408, 710176, 798944,
887712, 976480, 1065248, 1154016, 1242784, 1331552, 1419296, 1508064, 1596832,
1685600, 1774368, 1863136, 1951904, 2040672, 2129440, 2218208, 2306976,
2395744, 2484512, 2573280, 2662048, 2750816, 2838560, 2927328, 3016096,
3104864, 3193632, 3282400, 3371168, 3459936, 3548704, 3637472, 3726240,
3815008, 3903776, 3992544, 4081312, 4170080, 4257824, 4346592, 4435360,
4524128, 4612896, 4701664, 4790432, 4879200, 4967968, 5056736, 5145504,
5234272, 5323040, 5411808, 5500576, 5589344, 5677088, 5765856, 5854624,
5943392, 6032160, 6120928, 6209696, 6298464, 6387232, 6476000, 6564768,
6653536, 6742304, 6831072, 6919840, 7008608, 7096352, 7185120, 7273888,
7362656, 7451424, 7540192, 7628960, 7717728, 7806496, 7895264, 7984032,
8072800, 8161568, 8250336, 8339104, 8427872, 8515616, 8604384, 8693152,
8781920, 8870688, 8959456, 9048224, 9136992, 9225760, 9314528, 9403296,
9492064, 9580832, 9669600, 9758368, 9847136, 9934880, 10023648, 10112416,
10201184, 10289952, 10378720, 10467488, 10556256, 10645024, 10733792,
10822560, 10911328, 11000096, 11088864, 11177632, 11266400, 11354144,
11442912, 11531680, 11620448, 11709216, 11797984, 11886752, 11975520,
12064288, 12153056, 12241824, 12330592, 12419360, 12508128, 12596896,
12685664, 12773408, 12862176, 12950944, 13039712, 13128480, 13217248,
13306016, 13394784, 13483552, 13572320, 13661088, 13749856, 13838624,
13927392, 14016160, 14104928, 14192672, 14281440, 14370208, 14458976,
14547744, 14636512, 14725280, 14814048, 14902816, 14991584, 15080352,
15169120, 15257888, 15346656, 15435424
If the primary superblock of any filesystem is corrupted, the system will fail fsck during bootup.with the following message:
BAD MAGIC NUMBER
MAGIC NUMBER WRONG
Very often, the bad information in the primary superblock might not have been propagated to the backup superblocks. Therefore, if you use a backup superblock for the fsck command, you might be able to save the corrupted file system. When you run the fsck command with a backup superblock, the uncorrupted information at that location is copied to the primary superblock, fixing the original problem.
Never run a fsck on a mounted filesystem. When a filesystem cannot be unmounted, boot the server into single user mode or boot from the CD-ROM. When you get the "clean flag in superblock is wrong, fix?" error, and answering "yes" does not help fixing the problem, then fsck is being run on a mounted filesystem, and the clean flag is set to “active” when fsck is run. This causes the message that the clean flag is wrong. Fsck should be run repeatedly until it doesn't come back with an error. You can use the options "-of," which will do a force checking of file systems regardless of the state of their super block clean flag.
Temporary Workaround Top
Additional Information Top
Top
#-------------------------
Try to run:
fsck -F ufs /dev/rdsk/c0t0d0s0
again, if it come back with "USE AN ALTERNATE SUPER-BLOCK "
run
newfs -Nv /dev/rdsk/c0t0d0s0
it will will generate a list of alternate superblocks. Then do:
fsck -F ufs -o b= /dev/rdsk/c0t0d0s0
IF you have good data backup, you can run:
newfs /dev/rdsk/c0t0d0s0
to rebuild the file system (all you date will LOST!!!)
also have a look at the following Sun doc to learn more:
Document ID Synopsis Date
ID74314 Solaris[TM] Operating System: The fsck Command Cannot Find the Superblock 16 Jun 2004
--------------------------
Keyword(s):superblock, bad, fix, fsck, newfs, bad magic number, filesystem
Problem Statement Top
The ufs filesystems contain the following types of blocks:
boot block: The boot block stores information used to boot the system.
superblock: Much of the filesystems internal information is stored in superblocks.
inode: The inode stores location information about a file--everything except for the file name. The number of inodes in a filesystem can be changed from the default if newfs -i is used to create the filesystem.
data block: The file's data is stored in data blocks.
Filesystem corruption can be detected and often repaired by the format and fsck commands. Sometimes the fsck command complains that it cannot find the superblock. Alternative superblock locations were created by newfs at the time that the filesystem was created. The newfs -N command can be invoked to nondestructively discover the superblock locations for the filesystem.
Here are errors you can get:
clean flag in superblock is wrong: fix?
File system state in superblock is wrong fix?
Bad magic number
wrong magic number
Resolution Top
If the superblock is corrupted, the file system can still be repaired using alternate superblocks that are formed while making the new file system. Superblock numbers can be found using the following command:
newfs -Nv /dev/rdsk/c?t?d?s?
Caution: If the "n" option is used, the filesystem may be destroyed.
Newfs -N shows superblock backups. Refer to the following example:
newfs -Nv /dev/rdsk/c0t0d0s0
mkfs -F ufs -o N /dev/rdsk/c0t0d0s0 15440544 63 16 8192 1024 224 1 90 8192 t 0 -1 8 16
/dev/rdsk/c0t0d0s0: 15440544 sectors in 15318 cylinders of 16 tracks, 63 sectors
7539.3MB in 175 cyl groups (88 c/g, 43.31MB/g, 5504 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 88800, 177568, 266336, 355104, 443872, 532640, 621408, 710176, 798944,
887712, 976480, 1065248, 1154016, 1242784, 1331552, 1419296, 1508064, 1596832,
1685600, 1774368, 1863136, 1951904, 2040672, 2129440, 2218208, 2306976,
2395744, 2484512, 2573280, 2662048, 2750816, 2838560, 2927328, 3016096,
3104864, 3193632, 3282400, 3371168, 3459936, 3548704, 3637472, 3726240,
3815008, 3903776, 3992544, 4081312, 4170080, 4257824, 4346592, 4435360,
4524128, 4612896, 4701664, 4790432, 4879200, 4967968, 5056736, 5145504,
5234272, 5323040, 5411808, 5500576, 5589344, 5677088, 5765856, 5854624,
5943392, 6032160, 6120928, 6209696, 6298464, 6387232, 6476000, 6564768,
6653536, 6742304, 6831072, 6919840, 7008608, 7096352, 7185120, 7273888,
7362656, 7451424, 7540192, 7628960, 7717728, 7806496, 7895264, 7984032,
8072800, 8161568, 8250336, 8339104, 8427872, 8515616, 8604384, 8693152,
8781920, 8870688, 8959456, 9048224, 9136992, 9225760, 9314528, 9403296,
9492064, 9580832, 9669600, 9758368, 9847136, 9934880, 10023648, 10112416,
10201184, 10289952, 10378720, 10467488, 10556256, 10645024, 10733792,
10822560, 10911328, 11000096, 11088864, 11177632, 11266400, 11354144,
11442912, 11531680, 11620448, 11709216, 11797984, 11886752, 11975520,
12064288, 12153056, 12241824, 12330592, 12419360, 12508128, 12596896,
12685664, 12773408, 12862176, 12950944, 13039712, 13128480, 13217248,
13306016, 13394784, 13483552, 13572320, 13661088, 13749856, 13838624,
13927392, 14016160, 14104928, 14192672, 14281440, 14370208, 14458976,
14547744, 14636512, 14725280, 14814048, 14902816, 14991584, 15080352,
15169120, 15257888, 15346656, 15435424
If the primary superblock of any filesystem is corrupted, the system will fail fsck during bootup.with the following message:
BAD MAGIC NUMBER
MAGIC NUMBER WRONG
Very often, the bad information in the primary superblock might not have been propagated to the backup superblocks. Therefore, if you use a backup superblock for the fsck command, you might be able to save the corrupted file system. When you run the fsck command with a backup superblock, the uncorrupted information at that location is copied to the primary superblock, fixing the original problem.
Never run a fsck on a mounted filesystem. When a filesystem cannot be unmounted, boot the server into single user mode or boot from the CD-ROM. When you get the "clean flag in superblock is wrong, fix?" error, and answering "yes" does not help fixing the problem, then fsck is being run on a mounted filesystem, and the clean flag is set to “active” when fsck is run. This causes the message that the clean flag is wrong. Fsck should be run repeatedly until it doesn't come back with an error. You can use the options "-of," which will do a force checking of file systems regardless of the state of their super block clean flag.
Temporary Workaround Top
Additional Information Top
Top
#-------------------------
Please let me kown if you have good system backup.
ASKER
yuzh,
I tried to rebuild the file system using the command "newfs /dev/rdsk/c0t0d0s0" I get an error message "intenal error: can't find block in cyl 0. Does this mean that the HD is bad?
I tried to rebuild the file system using the command "newfs /dev/rdsk/c0t0d0s0" I get an error message "intenal error: can't find block in cyl 0. Does this mean that the HD is bad?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Yuzh. I already thought about purchasing two new HDs. I have one more question. Can you confirm the HD configuration for two IDE drives in an Ultra 5 system? I going to mirror the drives using solstice disk suite. This is what I think it should be:
1st IDE controller - primary disk - jumper settings: cable select
2nd IDE controller - second disk & CDROM - jumper settings: cable select
1st IDE controller - primary disk - jumper settings: cable select
2nd IDE controller - second disk & CDROM - jumper settings: cable select
I would leave the CDROM alone (default is 2nd Master), otherwise you endup have to
change the device aliase for cdrom in the OBP.
For the IDE HDs, jumper settings you can use "cable select", likely one as primary
master, the other one is primary slave. When I use 3rd HD, I normally set the
jumper settings as master or slave.
After you install the HDs, when you power up the box to ok prompt, type in:
probe-ide
to make sure the box can see the HDs and cdrom, then use:
boot -rv
to boot up.
All the best and good luck!
Cheers!
yuzh
change the device aliase for cdrom in the OBP.
For the IDE HDs, jumper settings you can use "cable select", likely one as primary
master, the other one is primary slave. When I use 3rd HD, I normally set the
jumper settings as master or slave.
After you install the HDs, when you power up the box to ok prompt, type in:
probe-ide
to make sure the box can see the HDs and cdrom, then use:
boot -rv
to boot up.
All the best and good luck!
Cheers!
yuzh
Was you trying to run an upgrade install on top of the HD?
You can try the followings:
Use the Solaris Software CD to boot up the box in single use mode,
try:
fsck -y /dev/rdsk/c0t0d0s0
If fsck runs ok then run fsck to all filesystems (partions).
then
mount the / filesystem
{
if the data ok ; then
installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0
and try to boot up from HD
else
you need to reinstall
fi
}
else
you have problem with the HD, you can try to use format to fix the HD
(repair option), but it is better to replace with a new one,IDE HD is very
cheap now.
In case you want to try to use use the old HD, you can use format to fix
the disk errors and try to install the OS (or restore from backup) again.
fi
GOOD LUCK!