Professional Web Applications Themes

Restore partition table - SCO

On SCO Openserver 5.0.6, whit command badtrk -e .... i have cleaned the partition table. Thre's a tool for restore a correct table, or a tool for search the first block by any file system on the hard disk ? excuse me for the language. thanks -- Posted via http://dbforums.com...

  1. #1

    Default Restore partition table


    On SCO Openserver 5.0.6, whit command badtrk -e .... i have cleaned the
    partition table.



    Thre's a tool for restore a correct table, or a tool for search the
    first block by any file system on the hard disk ?



    excuse me for the language.



    thanks


    --
    Posted via http://dbforums.com
    gtori Guest

  2. #2

    Default Re: Restore partition table

    gtori wrote:
     

    Running `badtrk -e` would have damaged the divvy table within your Unix
    partition. You _may_ be able to recover from this, but it won't be
    very easy.

    ftp://ftp.armory.com/~rts/fsrd/ contains a tool that may help.

    With the default system tools, you can proceed as follows. Go into
    `divvy` and define a division that starts at block 0 and ends somewhere
    higher up (doesn't matter exactly where). DO NOT TELL IT TO MAKE A NEW
    FILESYSTEM, just set the first and last block numbers. "q[uit]",
    "i[nstall]" the changes, then run `divvy` again. Look at the "Type"
    column. If you've found the start of the divvy area, your division
    number 0 should give a filesystem type like "EAFS" or "HTFS". If it
    says "NON FS" then you probably have the wrong start block.

    You didn't say whether this is the root disk or a secondary disk. If
    it's the root, the typical layout made by ISL looks like this:

    division 0 boot (EAFS)
    division 1 swap (NON FS)
    division 2 root (HTFS)

    If you haven't found the first filesystem, you need to use `badtrk -e`
    to set the badtrack table size back to the original size. This number
    isn't stored anywhere, but the default for IDE drives is 15 tracks. I'm
    not sure what the default is for SCSI drives (I think it varies with
    drive geometry). Hopefully you remember the original value.

    Once the badtrack table size is restored, then you probe again with
    `divvy`. It will have reset the divvy table to blank again. You make
    another test division starting at 0, then see if it comes up with a
    sensible filesystem type. (Remember that `divvy` does not recheck
    filesystem types until you exit and re-enter.)

    Once you find the beginning of a filesystem, set its end block to the
    highest block number `divvy` will allow. Run `df -vk /dev/fs` (where
    /dev/fs is the name you gave it). This tells you the size of the
    filesystem in 1K blocks, which is what `divvy` uses. Now set that
    division's end block to (start + size - 1). Start a new division on the
    next block and do the process again.

    If it's a root disk, you'll need to get past the swap area. Default
    suggested sizes for swap have varied in different releases. It will
    probably be at least the size of the system's memory at the time of ISL
    (which may not be the same as now), and won't be any larger than 4GiB
    (i.e. 4194304K). `fsrd` might be particularly useful for jumping past
    the swap space gap.
     
    Bela Guest

  3. #3

    Default Re: Restore partition table

    gtori wrote: 



    --
    Best,
    Roberto
    --
    Roberto Zini - Technical Support Manager - email:r.zini<AT>strhold.it
    Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

    Roberto Guest

  4. #4

    Default Re: Restore partition table

    On Thu, 28 Aug 2003 09:15:29 +0200, Roberto Zini <it>
    wrote:
     
    >
    >I think a better explanation of what happened is in order.
    >
    >This guy got in touch with me this afternoon since he wanted to mount an
    >existing SCO OS5 HD (taken from a previously working box) on a new SCO
    >OS5 box as to copy some data from the old HD to the new one.
    >
    >He previously executed "mkdev hd" on the new server (the one where data
    >had to be copied to) but, while doing so, he managed to corrupt the
    >divvy table on the HD, probably because "mkdev hd" executed "badtrk -e"
    >and allocated a new bad tracks table.
    >
    >Dunno about the answers given to "mkdev hd" prompts so I'm unable to
    >describe what he did in detail.
    >
    >As a result, divvy is now unable to detect the previously installed
    >filesystems (on the old HD) and thus he's unable to mount it and copy
    >the data over the new one.
    >
    >Is there a method to recover the original divvy layout ?
    >
    >Best,
    >Roberto[/ref]
    Doing the following MAY help if the HD is an IDE. Similar could
    eventually be done for SCSI, but you would need to figure out the
    minor/major values.


    create a directory "dev" in /tmp
    and execute the following code
    ----------------

    i=254
    while true
    do
    mknod dev/$i b 1 $i
    i=`expr $i - 1`
    done


    for i in `ls dev`
    do
    echo $i>>dtype1
    dtype dev/$i>>dtype1 2>>dtype1 1>>dtype1
    done

    ------------
    You will now have a directory with several special devices that can be
    "mounted", and a file "dtype1" with a description of each valid file
    system in each special file from /tmp/dev.

    You can mount the valid entries as normal.
    e.g. mount -r /tmp/dev/114 /mnt

    and then copy whatever you need.

    Note sure if it will work now because of the badtracing bit.




    Frederico Fonseca
    ema il: frederico_fonseca at syssoft-int.com
    Frederico Guest

  5. #5

    Default Re: Restore partition table

    Frederico Fonseca wrote:
     
    > >
    > >I think a better explanation of what happened is in order.
    > >
    > >This guy got in touch with me this afternoon since he wanted to mount an
    > >existing SCO OS5 HD (taken from a previously working box) on a new SCO
    > >OS5 box as to copy some data from the old HD to the new one.
    > >
    > >He previously executed "mkdev hd" on the new server (the one where data
    > >had to be copied to) but, while doing so, he managed to corrupt the
    > >divvy table on the HD, probably because "mkdev hd" executed "badtrk -e"
    > >and allocated a new bad tracks table.
    > >
    > >Dunno about the answers given to "mkdev hd" prompts so I'm unable to
    > >describe what he did in detail.
    > >
    > >As a result, divvy is now unable to detect the previously installed
    > >filesystems (on the old HD) and thus he's unable to mount it and copy
    > >the data over the new one.
    > >
    > >Is there a method to recover the original divvy layout ?
    > >
    > >Best,
    > >Roberto[/ref]
    > Doing the following MAY help if the HD is an IDE. Similar could
    > eventually be done for SCSI, but you would need to figure out the
    > minor/major values.
    >
    >
    > create a directory "dev" in /tmp
    > and execute the following code
    > ----------------
    >
    > i=254
    > while true
    > do
    > mknod dev/$i b 1 $i
    > i=`expr $i - 1`
    > done
    >
    >
    > for i in `ls dev`
    > do
    > echo $i>>dtype1
    > dtype dev/$i>>dtype1 2>>dtype1 1>>dtype1
    > done
    >
    > ------------
    > You will now have a directory with several special devices that can be
    > "mounted", and a file "dtype1" with a description of each valid file
    > system in each special file from /tmp/dev.
    >
    > You can mount the valid entries as normal.
    > e.g. mount -r /tmp/dev/114 /mnt
    >
    > and then copy whatever you need.
    >
    > Note sure if it will work now because of the badtracing bit.[/ref]

    Your `while true' loop won't ever stop. But aside from that, this would
    only work if the divvy table wasn't destroyed. The device nodes you're
    making refer to every division of every partition on all four possible
    units of the "wd" driver. (Actually, 4 "wd" units of the "hd" driver,
    in a system that is rooting from an IDE drive.) Each of those divisions
    and partitions will only be correct if the division and partition tables
    are intact.
     
    Bela Guest

  6. #6

    Default Re: Restore partition table

    Roberto Zini wrote:
     
    >
    > I think a better explanation of what happened is in order.
    >
    > This guy got in touch with me this afternoon since he wanted to mount an
    > existing SCO OS5 HD (taken from a previously working box) on a new SCO
    > OS5 box as to copy some data from the old HD to the new one.
    >
    > He previously executed "mkdev hd" on the new server (the one where data
    > had to be copied to) but, while doing so, he managed to corrupt the
    > divvy table on the HD, probably because "mkdev hd" executed "badtrk -e"
    > and allocated a new bad tracks table.
    >
    > Dunno about the answers given to "mkdev hd" prompts so I'm unable to
    > describe what he did in detail.
    >
    > As a result, divvy is now unable to detect the previously installed
    > filesystems (on the old HD) and thus he's unable to mount it and copy
    > the data over the new one.
    >
    > Is there a method to recover the original divvy layout ?[/ref]

    See my previous post.

    `mkdev hd` _does_ run `badtrk`, probably with "-e" flag. If you make
    changes and tell it to write them to the disk, you lose the divvy table.
    If you just quit `badtrk` and tell it _not_ to write changes, you don't.
    So that's where he went wrong -- not that the script makes it very clear
    what to do...
     
    Bela Guest

  7. #7

    Default Re: Restore partition table

    On Thu, 28 Aug 2003 21:13:29 GMT, Bela Lubkin <com> wrote:
     
    Snip 
    >
    >Your `while true' loop won't ever stop. But aside from that, this would
    >only work if the divvy table wasn't destroyed. The device nodes you're
    >making refer to every division of every partition on all four possible
    >units of the "wd" driver. (Actually, 4 "wd" units of the "hd" driver,
    >in a system that is rooting from an IDE drive.) Each of those divisions
    >and partitions will only be correct if the division and partition tables
    >are intact.
    > [/ref]
    Thats why I said I wasn't sure it would work. (loop bit was a code
    ommission (cut and past)!)

    Out of curiosity do you know if the above construct (using the correct
    minor/major) would work with a SCSI environment?




    Frederico Fonseca
    ema il: frederico_fonseca at syssoft-int.com
    Frederico Guest

  8. #8

    Default Re: Restore partition table

    Frederico Fonseca wrote:
     [/ref][/ref]

    or better, while [ $i -gt 0 ]
     [/ref][/ref]
     

    See hd(HW). The minor number scheme described there applies to all hard
    disks on an OpenServer system, using any of the various disk drivers (in
    order of my guess of their current popularity: wd, Sdsk, ida, Dsk, esdi,
    st, omti). The major number would have to be adjusted to match the
    driver being used.

    But again, that just makes device nodes that point to the starts of the
    various constructs known to the disk partitioning driver (dk). If the
    partition or divvy tables are corrupt, no amount of fiddling with minor
    numbers will find your data.
     
    Bela Guest

  9. #9

    Default Re: Restore partition table

    On Fri, 29 Aug 2003 10:12:40 GMT, Bela Lubkin <com> wrote:
     
    snip 
    >
    >See hd(HW). The minor number scheme described there applies to all hard
    >disks on an OpenServer system, using any of the various disk drivers (in
    >order of my guess of their current popularity: wd, Sdsk, ida, Dsk, esdi,
    >st, omti). The major number would have to be adjusted to match the
    >driver being used.
    >
    >But again, that just makes device nodes that point to the starts of the
    >various constructs known to the disk partitioning driver (dk). If the
    >partition or divvy tables are corrupt, no amount of fiddling with minor
    >numbers will find your data.[/ref]

    Thanks Bela




    Frederico Fonseca
    ema il: frederico_fonseca at syssoft-int.com
    Frederico Guest

Similar Threads

  1. Physical restore that doesn't require a logical restore
    By Christian Eriksson in forum Informix
    Replies: 6
    Last Post: September 24th, 11:30 AM
  2. Replies: 3
    Last Post: July 18th, 07:47 AM
  3. Replies: 1
    Last Post: December 16th, 08:00 AM
  4. Replies: 0
    Last Post: December 15th, 01:15 PM
  5. Index Partition Rebuild is using Full Table Scan
    By Dave in forum Oracle Server
    Replies: 1
    Last Post: December 13th, 03:11 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139