Search Text         
Search Tips?
Search By   And   Or   Boolean   Exact Match   TA #
Search In   Whole Doc   Keywords Sort By  
Product   Sub Product  

View Technical Articles (sorted by Product) New/Updated in the last:    7 days      14 days      30 days             
TA # Date Created Date Updated Resolved Issue?   Printer Friendly Version of This TA   Print Article
  E-mail This TA   E-mail Article
113281 03/30/2001 09:22 AM 12/06/2006 05:49 AM
Yes No
I am unable to fsck my non-root filesystem and re-mount the filesystem after a power failure
Keywords
openserver open server ose corrupted corrupt corruption ups power 5.0.0 5.0.2 5.0.4 5.0.5 5.0.6 500 502 504 505 506 synchronous failures fsck disk failure fsdb htfs nolog nochkpt phase 5 checking log 507 5.0.7 dtype hd trouble troubleshoot troubleshooting divvy cannot cant determine filesystem type unrecognised data backup restore fs superblock
Release
          SCO OpenServer Enterprise System Release 5.0.5, 5.0.6, 5.0.7 
          SCO OpenServer Host System Release 5.0.5, 5.0.6, 5.0.7 
	  SCO OpenServer Desktop System Release 5.0.5, 5.0.6, 5.0.7 
	  SCO OpenServer Enterprise System Release 5.0.0, 5.0.2, 5.0.4 
	  SCO OpenServer Host System Release 5.0.0, 5.0.2, 5.0.4 
          SCO OpenServer Desktop System Release 5.0.0, 5.0.2, 5.0.4 
Problem
          When an "fsck -d -ofull" is performed on a non-root filesystem,
          the fsck hangs and at the point it runs Phase 5 Checking
          Synchronous Log.

CAUSE:
      	  The filesystem's log has become corrupted.


Solution
          SCO documentation regarding corrupted filesystems can be found
	  in Technical Article 110488.

	  Note: If your building has power problems, it is recommended
	  that you protect you data with a UPS.

          First try, mounting the filesystem without any logging:

		mount -v -o nolog /dev/u /u

	  OR in /etc/default/filesys:

          Change your entry to include "mtnopts=nolog",eg.

                from:

bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes mount=no fstyp=HTFS
fsck=yes rcfsck=yes fsckflags=-y mountflags=

                to:

bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes mount=no fstyp=HTFS
mntopts=nolog fsck=yes rcfsck=yes fsckflags=-y mountflags=

          Secondly, you can try mounting the filesystem without any
          logging or checkpointing:

		mount -v -o nolog,nochkpt /dev/u /u

	  or in /etc/default/filesys:

                Add the "nochkpt" option as below:

bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes mount=no fstyp=HTFS
mntopts=nolog,nochkpt fsck=yes rcfsck=yes fsckflags=-y mountflags=

	  See mount(ADM)

	If this is successful, then it is strongly recommended that the
        filesystem should be backed up, before the following steps.

	This attempt to recover involves using the fsdb command to truncate
	the HTFS journal logfile. Running the fsck command on the filesystem
	thereafter will remove the logfile and then recreate one from      
        scratch. If your hard disk is too damaged then it may be possible 
        that this method will not work.

	(Note that fsdb is powerful, cryptic and unfriendly, and you can 
	damage your filesystem irrevocably if you are not familiar with the
    	details of filesystem structure. Use it with caution.)

	  The following steps need to be followed:

		1. Shut the machine down into single user mode and ensure that
		   the filesystem in question is NOT mounted.
		2. Run the fsdb command on the damaged filesystem:
		    	# fsdb /dev/r<filesystem>
		3. The fsdb command does not have a prompt.
			Type in 4i and press enter.
		4. Type in sz=0 and enter.
		5. Type 4i again and press enter.
		6. Type in =0100666 and enter.
		7. Type in q to quit and then enter.
                8. Run fsck -ofull /dev/r<filesystem>.

		The fsck command will notify you that the file .slog0000 is an
		incorrect file type and will seek confirmation to remove it.
		Answer 'yes' to remove the file.

	        The fsck command will then ask you further questions as to
		fixing the inode count, correcting the superblock and whether
		you would like to salvage files. Answer 'yes' to
		these questions.

		9. Once you have run the fsck command you can then mount your
		filesystem and do your own checks to ascertain the validity of
		the data on the filesystem.

		See fsdb(ADM)

                For example :

# umount /u
# fsdb /dev/ru
/dev/ru(u): HTFS File System
FSIZE = 4217061, ISIZE = 1054272
4i
i#:     4  md: d---rwx------  ln:    2  uid:    2  gid:    2  sz:     1024
a0:131803  a1:     0  a2:     0  a3:     0  a4:     0  a5:     0  a6:     0
a7:     0  a8:     0  a9:     0  a10:     0  a11:     0  a12:     0
at: Tue Apr  3 09:21:23 2001
mt: Tue Apr  3 09:21:23 2001
ct: Tue Apr  3 09:21:23 2001
sz=0
004614.D: 000000 (0)
4i
i#:     4  md: d---rwx------  ln:    2  uid:    2  gid:    2  sz:        0
a0:131803  a1:     0  a2:     0  a3:     0  a4:     0  a5:     0  a6:     0
a7:     0  a8:     0  a9:     0  a10:     0  a11:     0  a12:     0
at: Tue Apr  3 09:21:23 2001
mt: Tue Apr  3 09:21:23 2001
ct: Tue Apr  3 09:21:23 2001
=0100666
i#:     4  md: f---rw-rw-rw-  ln:    2  uid:    2  gid:    2  sz:        0
a0:131803  a1:     0  a2:     0  a3:     0  a4:     0  a5:     0  a6:     0
a7:     0  a8:     0  a9:     0  a10:     0  a11:     0  a12:     0
at: Tue Apr  3 09:21:23 2001
mt: Tue Apr  3 09:21:23 2001
ct: Tue Apr  3 09:21:23 2001
q
#
# fsck -ofull /dev/ru

/dev/ru
HTFS File System: u Volume: u

** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=4
CLEAR? [yn] y

FREE INODE COUNT WRONG IN GROUP - 0
FIX? [yn] y

** Phase 2 - Check Pathnames
UNALLOCATED  I=4  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 00:00 1970
NAME=/.slog0000

REMOVE? [yn] y

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=2  OWNER=root MODE=40777
SIZE=512 MTIME=Apr  3 09:21 2001  COUNT 3 SHOULD BE 2
ADJUST? [yn] y

FREE INODE COUNT WRONG IN SUPERBLOCK
FIX? [yn] y

** Phase 5 - Check Free List Bitmap
1 BLK(S) MISSING

SALVAGE? [yn] y

** Phase 6 - Salvage Free List Bitmap
3 files 513 blocks 4084761 free

*** FILE SYSTEM WAS MODIFIED ***
# mount /dev/u /u
#

NOTES:
        TROUBLESHOOTING
        ---------------
        Should you get the message "Cannot determine filesystem type" when 
        trying your "mount" or "fsck" then the situation is worse and the
        SuperBlock table of that filesystem has become corruped.  Here, running
        "fsdb" would not be advisable because the tools "mount" and "fsck" are
        unable to actually get onto the filesystem to examine it.

        The course of action available would be to remove the filesystem,
        re-create it then restore from backup.

        To help determine this is the correct course of action use the 
        following command to determine if the filesystem's superblock is 
        readable:

        # dtype /dev/<fs>

        If this returns "unrecognised data" then the superblock is damaged or
        corrupted.

        If you get a valid filesystem type returned then "fsck" should have
        been able to fix this.

          If there is no /dev/<fs> filesystem then it's likely the device nodes
          have either been deleted or the disk has been moved here from another
          server.  The device nodes can either be created using "mknod" or 
          "divvy /dev/hd[x]a".  Here you would not create a new filesystem but
          rather would just "install" when you "quit" from divvy to just 
          re-make the device nodes.  NB. x = the hard disk

        In either event, determine if there is data there with:

        # hd /dev/<fs>

        Here, it is likely you see hex data indicating that there is data on 
        filesystem but it can be accessed, again, indicating superblock failure
        of some kind.  If nothing is returned then there is no data either.

        To remake the filesystems, run:

        # divvy -P -N /dev/hd[x]a 

        NB. x = hard disk

        This will give you a list of the filesystems on the active partition:

        eg:

        divvy -P -N /dev/hd0a
        0              0          19999   boot       EAFS
        1          20000         115999   swap       NON FS
        2         116000        1961578   root       HTFS
        3        1961579        3923156   u          HTFS
        6        3923157        3923166   recover    NON FS
        7              0        3924080   hd0a       WHOLE DISK

        If "u", in this example, was to say "NON FS" then this confirms also
        the SuperBlock corruption.

        To recreate it, run:

        # divvy /dev/hd[x]a

        and "create" partition 3.  There would be no need to change the Start
        or End blocks but it would change the New Filesystem flag from No to 
        Yes and set it to HTFS.

        You can then "quit" and "install" and this will a) re-create the 
        filesystem and SuperBlock, effectively re-formatting the filesystem and
        b) will create the /dev/u and /dev/ru device nodes if they were 
        missing.

           Use "mkdev fs" to create the mount points and entry in 
           /etc/default/filesys if this were required.

        You should then be able to mount the filesystem and restore your data.

See Also

	Technical Article 110488, "My filesystem is corrupt even after running fsck. What can
	I do before restoring from backup or consulting a data recovery 
	service?"

        Technical Article 113121, "My OpenServer server has panicked with "NOTICE: growreg -
        Insufficient memory to allocate 1 page - system call failed"
Back to Search ResultsBack to Search Results