SEO

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 wrote:

> 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 ?

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<

gtori wrote:
> 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



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

On Thu, 28 Aug 2003 09:15:29 +0200, Roberto Zini <r.zini@strhold.it>
wrote:

>gtori wrote:
> > 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
>
>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
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 Fonseca wrote:

> On Thu, 28 Aug 2003 09:15:29 +0200, Roberto Zini <r.zini@strhold.it>
> wrote:
>
> >gtori wrote:
> > > 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
> >
> >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
> 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.

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<

Roberto Zini wrote:

> gtori wrote:
> > 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 ?
>
> 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 ?

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<

On Thu, 28 Aug 2003 21:13:29 GMT, Bela Lubkin <belal@sco.com> wrote:

>Frederico Fonseca wrote:
>
Snip
>> ----------------
>>
>> 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.
>
>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<
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 Fonseca wrote:

> >> i=254
> >> while true

or better, while [ $i -gt 0 ]

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

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

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<

On Fri, 29 Aug 2003 10:12:40 GMT, Bela Lubkin <belal@sco.com> wrote:

>Frederico Fonseca wrote:
>
snip
>
>> Out of curiosity do you know if the above construct (using the correct
>> minor/major) would work with a SCSI environment?
>
>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.

Thanks Bela




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