Re: PANIC : srmountfun - Error 22

From: Steve M. Fabac, Jr. (smfabac_at_att.net)
Date: 09/19/04

  • Next message: Steve M. Fabac, Jr.: "Re: PANIC : srmountfun - Error 22"
    Date: Sun, 19 Sep 2004 05:13:20 GMT
    
    

    Hari wrote:
    >
    > I am running SCO Open Server 5.0.5 on HP Net Server E800. This morning
    > i have following message on console
    >
    > NOTICE: Sdisk: Unrecoverable error reading SCCI disk 0 dev 1/42 (hd=0
    > bus=0 id=0 lun=0) block=0
    >
    > Medium Error
    >
    > "PANIC : srmountfun - Error 22 mounting rootdev hd(1/42)

    1/42 is the root file system.

    > Cannot dump 32654 pages to dumpdev hd (1/41) Space for only 0 pages."
    >
    > Dump not completed
    >
    > ** Safe to Power Off **
    > -or-
    > ** Press Any Key to Reboot **
    >
    > I have searched both SCO TA's and archive of the news groups but no
    > help. Could any one help me?
    >
    > Thanks
    > Hari.

    The last time I saw that message was on a client's SCO Xenix 2.3.4 system.
    The message then meant that the superblock on the root file system was
    corrupted. All SCO tech articles indicated that the only fix was to
    boot the emergency boot floppy, divvy and create a new (empty) root
    file system, and restore the root file system backup. Since my client
    did not have a good root file system backup, I had to develop the
    the following information and fix the problem. Once fsck was happy,
    I booted the emergency boot floppy, mounted the recovered root
    file system (hd0root) read-only and used cpio to back up the file system
    to tape. I then used divvy to create a clean root file system and restored
    the tape.

    With the Xenix file system, there were only 4 important settings and
    once they were fixed with the filesystem debugger (fsdb), fsck would then
    rebuild the rest of the superblock. I don't know it that remains the same
    for SCO 5.0.5 HTFS file system. Executing 1024p0e will display the Xenix
    superblock after typing fsdb /dev/hd0root.

    2000: The ISIZE of the file system
    2002D: The low byte value of the FSIZE
    3770D: The magic number for the file system
    3774: 2 (file system type for lK file systems)

    For Xenix 2.3.4 these values are determined as follows:

    Boot the Xenix emergency boot floppy and execute fsdb /dev/hd0root.
    To get the value for ISIZE you need only type 2i to display
    the root i-node. The value labeled A0: is the starting block
    of the root directory. This block is the same or one number higher
    than the number of blocks for ISIZE. Enter this value in 2000
    by typing 1024=1562 (Use the correct number for your system.)

    The file size is determined by using the divvy command to display
    the division table of the file system. The file system size to use
    is the starting block number of the first division starting after
    the root division. Convert this number to the high and low components
    of the 32-bit integer value to be stored at 2002D. As an example: The
    starting block of the next file system is 99841, subtract 65536 from
    99841 and enter the result in 2002 as 34305. The number you enter
    in 2004 is the whole number of times that 99841 is divided by 65536.
    So the hi-byte value entered in 2004 is 1.

    The "magic number" is used to identify the superblock. The
    value of the magic number is arbitrary (up until it has been chosen
    by the system designer) and its occurrence at address 3770D in any
    other block is reported to be one chance in 4.3 billion. To find what
    magic number to use is simple, just use fsdb to look at the superblock
    on your emergency boot floppy. (Remember this was developed on
    Xenix 2.3.4 and the magic number for SCO 5.0.5 systems may be different.)

    On my client's Xenix system I found the magic number by typing 2038
    and then pressing return until the display was: 003770: 052504 (21828)
    and then pressing return again resulted in 003772: 000053 (43). This
    representation of the magic number is more useful because you can
    transfer the values inside of the parentheses directly to the hard
    disk when you are ready. Pressing return again displays 03774: 000002 (2),
    the indicator for the Xenix System V 1K type file system.

    Credits: Before I tried this I had read the section
    on fsdb in UNIX ADMINISTRATION GUIDE FOR SYSTEM V by Rebecca
    Thomas and Rik Farrow.

    End Xenix discussion. If you have another SCO 5.0.5 system you have the option
    to install a disk and configure it to match the disk layout of the failed
    system. you can then use dd if=/dev/root of=root.superblock bs=1k count=1
    to copy the superblock of a good file system. Then place the root.supreblock
    file on a UNIX file system floppy and use your emergency boot floppy and
    boot it in the failed system. Copy the root.superblock to the failed
    root file system by executing dd if=root.superblock of=/dev/hd0root bs=1k.

    Use caution. A good idea is to use dd to copy the bad superblock to a file
    on the unix file system floppy before you write the copied root.superblock:
    dd if=/dev/hd0root of=bad.root.superblock bs=1k count=1.

    I just checked 5.0.6 HTFS and found fsdb displays the superblock with
    512p0e and the table becomes

    1000: The ISIZE of the file system
    1002D: The low byte value of the FSIZE
    1770D: The magic number for the file system
    1774: 2 (file system type for lK file systems)

    On 5.0.6 /dev/root /dev/u and /dev/app1 the magic
    number and file system type is as follows:

    001770: 044452 (18730)
    001772: 120140 (41056)
    001774: 000002 (2

    Type 1016=18730 [Enter]
         1018=41056 [Enter]
         1020=2 [Enter]

    --
                                          Steve Fabac
                                           S.M. Fabac & Associates
                                            816/765-1670
    

  • Next message: Steve M. Fabac, Jr.: "Re: PANIC : srmountfun - Error 22"