BAD MAGIC NUMBER MAGIC NUMBER WRONG – restore primary superblock with fsck
Before going to actual error we should look at the basic components of the UFS filesystem. There are four components of file system
- boot block : The boot block stores information used to boot the system.
- super-block : Much of the filesystems internal information( like data location, address mappings …etc. ) 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
We will receive superblock errors either during the boot ( after unexpected server crash) or while running fsck command on the filesystem and the typical errors appear like below
- clean flag in superblock is wrong: fix
- File system state in superblock is wrong fix
- Bad magic number
- wrong magic number
If the primary superblock of any filesystem [ referenced in the vfstab, to automatically mount during booting ] 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. Hence we have chances to use a backup superblock for the fsck command to save the corrupted filesystem.
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.
To resolve the bad superblock issue we should find out the alternate superblocks which were created during the file system creation. you can list all available superblocks with the below command
# newfs -Nv /dev/dsk/c#t#d#s# (where # is the actual device number)
Once you get the list of backup superblocks, you can use below fsck command to recover the filesystem using the backup superblock
fsck -o b= 15435424 /dev/rdsk/c#t#d#s# ( where c#t#d#S# is actual disk device name)
Precautions:
Everytime when you mount a filesystem the clean flag for the superblock will be unset automatically, and if you run fsck on mounted filesystem you will get the “clean flag in superblock is wrong, fix ” error, and answering “yes” does not help fixing the 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.
This is one of the most common error faced during the reboot. Specially for the servers with high uptime.
Depends how carefully you reboot the server . Hopefully the normal commands are used so that diskinfo is in sync and all handles are written to disk .
Also the fsck command is not correct and should beÂ
fsck -o b= /dev/rdsk/c#t#d#s# Â Â —-> fsck should be always be run on raw devices else chances of data loss is high .
@ravi – it doesn’t really matter how careful SAs you and me, File systems will struggle to keep their integrity whenever the server crashes due to hardware/OS issues.
and about the rdsk point, thanks for that … I corrected the typo.
we can use sblock 32 , it will be available by default in all fs.
@prakash – true. The big number mentioned here is to grab attention from the new-bee towards the alternative superblock address.
btw, nice to see your comment at gurkulindia :) pls keep feedback on.
@Velu, nice query, @Ram, good response!!!..:-)
But default the FS try to take the 32nd block, if not found then only it will state “super block corrupted”. Now we need to find the next available super block “newfs -N” and assign the same value while fsck’ing with b=<block no." . Hope this helps…
Yogesh/RamÂ
   I do not believe that with a large uptime and normal reboot you will get this error and if there were to be integrity issues you first start to notice it with your backup failures of root FS.
Now coming to your issue of abnormal reboot and hardware failure reboot when it cant sync it i am sure it will not comeup with this error it will be more than this and you will see a different error .
Hi Ravi, I came across such situation many times (specailly when I rebooted the server) and the only solution I got from SUN is its because of high uptime and lower kernel patch level. :)
And yes you are very true its not only the error but one of the errors which we will encounter during reboots on the server with high uptime.
@ravi… will keep your point in mind, and will capture real scenario for this post. Thanks. please Keep looking at other posts
Good one.. Could you pls post on ‘Kernal patching’ ?
@Saurabh, we will try to post your request.
@Saurabh, the kernel patching procedure has been posted as committed. :)
Thanks yogesh :)
you are always welcome Saurabh,,