BAD MAGIC NUMBER MAGIC NUMBER WRONG – restore primary superblock with fsck

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

Loading Facebook Comments ...

15 Responses

  1. Yogesh Raheja says:

    This is one of the most common error faced during the reboot. Specially for the servers with high uptime.

  2. Ravi Singh says:

    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 .

    • Ramdev says:

      @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.

  3. Velu Prakash says:

    we can use sblock 32 , it will be available by default in all fs.

  4. ramdev says:

    @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.

  5. Yogesh Raheja says:

    @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…

  6. Ravi Singh says:

    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 .

  7. Yogesh Raheja says:

    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. :)

  8. Yogesh Raheja says:

    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.

  9. ramdev says:

    @ravi… will keep your point in mind, and will capture real scenario for this post. Thanks. please Keep looking at other posts

  10. Saurabh says:

    Good one.. Could you pls post on ‘Kernal patching’ ?

  11. Yogesh Raheja says:

    @Saurabh, we will try to post your request.

  12. Yogesh Raheja says:

    @Saurabh, the kernel patching procedure has been posted as committed. :)

  13. Saurabh says:

    Thanks yogesh :)

  14. Yogesh Raheja says:

    you are always welcome Saurabh,,

Leave a Reply

Your email address will not be published.

[contact-form to='ramkumar.ramadevu@gmail.com' subject='New Learning Request Submitted'][contact-field label='Name' type='name' required='1'/][contact-field label='Email' type='email' required='1'/][contact-field label='Learning Request' type='textarea' required='1'/][contact-field label='Are you Looking for ' type='radio' required='1' options='Paid Training,Free Training'/][/contact-form]

What is your Learning Goal for Next Six Months ? Talk to us