I just plugged my one HDD containing full OSR5 system as a second HDD
i.e. on the Primary Slave and the BIOS detects the HDD automatically.

I used divvy /dev/hd1a to rename those partitions and mounted it. Now
all the HTFS partitions have changed to DOS and I can not mount them
any more.

Any suggections?

Thanks for your kind assistance.

Chacrint

Chacrint Charinthorn wrote:

> I just plugged my one HDD containing full OSR5 system as a second HDD
> i.e. on the Primary Slave and the BIOS detects the HDD automatically.
>
> I used divvy /dev/hd1a to rename those partitions and mounted it. Now
> all the HTFS partitions have changed to DOS and I can not mount them
> any more.

When you ran divvy, did you do anything other than "n[ame]" the
divisions?

I think your drive is fine. The problem is that it's being seen with a
different geometry than before. You need to inform the OS of the
drive's original geometry.

What to do next depends on what OS release you are running; which you
did not state. Tell me what OS releases are on _both_ disks.

>Bela<

>
> When you ran divvy, did you do anything other than "n[ame]" the
> divisions?

No, I just name, quit and install. After that I mounted them (with the
/boot partition changed to DOS already).

I would like to refer to what happened earlier. A few days ago, I had
the following error.

"PANIC : srmountfun - Error 22
mounting rootdev hd(1/42) Cannot dump 380745 pages to dumpdev hd
(1/41) Space for only 0 pages."

So I took another HDD and reinstall OSR 5.04. Then used the error disk
as "hd1a".


>
> I think your drive is fine. The problem is that it's being seen with a
> different geometry than before. You need to inform the OS of the
> drive's original geometry.

I think so. I tried to manually keyed in the CHS into BIOS but this
would not help.

>
> What to do next depends on what OS release you are running; which you
> did not state. Tell me what OS releases are on _both_ disks.

They are both running SCO Open server 5.04

Thanks,
Chacrint

Chacrint Charinthorn wrote:

> > When you ran divvy, did you do anything other than "n[ame]" the
> > divisions?
>
> No, I just name, quit and install. After that I mounted them (with the
> /boot partition changed to DOS already).
>
> I would like to refer to what happened earlier. A few days ago, I had
> the following error.
>
> "PANIC : srmountfun - Error 22
> mounting rootdev hd(1/42) Cannot dump 380745 pages to dumpdev hd
> (1/41) Space for only 0 pages."
>
> So I took another HDD and reinstall OSR 5.04. Then used the error disk
> as "hd1a".
>
> > I think your drive is fine. The problem is that it's being seen with a
> > different geometry than before. You need to inform the OS of the
> > drive's original geometry.
>
> I think so. I tried to manually keyed in the CHS into BIOS but this
> would not help.

OpenServer keeps its own record of the drive's geometry. Changing the
BIOS's idea of the geometry can affect OSR5's idea, but the effect is
indirect. It's better just to tell it the "right" geometry.

> > What to do next depends on what OS release you are running; which you
> > did not state. Tell me what OS releases are on _both_ disks.
>
> They are both running SCO Open server 5.04

Ok.

Do you have an old backup of the original drive? The geometry is
recorded in /usr/adm/messages, /usr/adm/syslog, and /usr/adm/hwconfig
every time the machine is booted. If you can restore one of those files
from a backup, you can use it to inform the system of the correct
geometry.

Suppose you restored the old /usr/adm/hwconfig as /tmp/hwconfig.old.
Look in that file for a line similar to:

%disk 0x01F0-0x01F7 14 - type=W0 unit=0 cyls=21889 hds=255 secs=63

(this shows my desktop system's 180GB IDE drive). If the system had
multiple disks, there will be multiple "%disk" lines. Look at the first
one.

In order to "stamp" the drive with its proper geometry, you will need
the "cyls" "hds" and "secs" numbers from the old "%disk" line. Run:

# dparam /dev/rhd10

This will print a set of numbers like:

21889 255 0 36352 0 233 29281 63
^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^^ ^^
cyls hds other numbers secs

-- showing the current (wrong) geometry your system is using for the
drive. Now use `dparam` to write a new set of numbers, replacing the
first, second and last numbers with the ones from the old "%disk" line.
If the right parameters were 11111 222 333, this would look like:

# dparam /dev/rhd10 11111 222 0 36352 0 233 29281 333
^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^^ ^^^
cyls hds other numbers secs

Be sure to use the numbers from your system. You're putting together
the middle 5 "other numbers" + the 3 geometry numbers from the old
"%disk" line.

Then run `divvy /dev/rhd10` and see whether the filesystem types are any
better. If not, reboot and try `divvy /dev/rhd10` again. (I'm not sure
whether the system will fully realize the corrected geometry before
being rebooted.)

If you don't have a suitable backup, you might be able to find the
"%disk" line by searching the disk. The wrong geometry will not prevent
you from reading some data off the disk, it only prevents you from
finding the filesystems properly. Try running:

# grep %disk /dev/rhd1a

This may produce a lot of false matches. It may also fail to find
anything at all. You will have to decide for yourself whether you
believe what it shows.

>Bela<

> Do you have an old backup of the original drive?

No, I don't. I followed your instruction by running "grep %disk
/dev/rhd1a". The following two lines were obtained at the time the
geometry was probably correct (at that time I used it as the boot
disk).

Aug 6 21:15:53 thai22 %disk 0x01F0-0x01F7 14 - type=W0 unit=0
cyls=7476 hds=255 secs=63
Aug 6 21:16:28 thai22 %disk 0x01F0-0x01F7 14 - type=W0 unit=1
cyls=2434 hds=255 secs=63



And when I ran "dparam /dev/rhd10". I had the following.

7476 255 0 0 0 8 29436 63
cyls hds secs

Which I think the geometry is the same as when it was in a good
condition, do you have any other suggestions or I can try restamping
the same parameters?

Moreover, what is the diffenrence btw "/dev/hd1a", "/dev/rhd1a" and
"/dev/rhd10"? do they all represent the Primary-Slave disk?

Thanks again for your kind assistance.

Chacrint

Chacrint Charinthorn wrote:

> > Do you have an old backup of the original drive?
>
> No, I don't. I followed your instruction by running "grep %disk
> /dev/rhd1a". The following two lines were obtained at the time the
> geometry was probably correct (at that time I used it as the boot
> disk).
>
> Aug 6 21:15:53 thai22 %disk 0x01F0-0x01F7 14 - type=W0 unit=0
> cyls=7476 hds=255 secs=63
> Aug 6 21:16:28 thai22 %disk 0x01F0-0x01F7 14 - type=W0 unit=1
> cyls=2434 hds=255 secs=63
>
>
> And when I ran "dparam /dev/rhd10". I had the following.
>
> 7476 255 0 0 0 8 29436 63
> cyls hds secs
>
> Which I think the geometry is the same as when it was in a good
> condition, do you have any other suggestions or I can try restamping
> the same parameters?

It will not make any difference to restamp it with identical parameters.

If the geometry is correct, but it reports all the divisions as "DOS",
that suggests that all of the divisions are actually corrupt. What
happens if you try to mount them? Use read-only mounts to minimize the
chance of further corruption. e.g.:

# mount -r /dev/root2 /mnt
# ls -l /mnt # if the mount succeeded

> Moreover, what is the diffenrence btw "/dev/hd1a", "/dev/rhd1a" and
> "/dev/rhd10"? do they all represent the Primary-Slave disk?

See the man page hd(HW). All three of those represent your second hard
disk, in this case primary/slave. hd1a and rhd1a are the active
partition of that drive, as a block and a raw device. rhd10 is the
whole drive as a raw device. The biggest differences between block and
raw disk devices are: access to a block device is cached in the buffer
cache; mounting a filesystem requires a block device; I/O control
commands (ioctls) require a raw device.

>Bela<

Please see below for the outcome of my "mount" attempt.

| | EAFS | no | 0 | 0| 25599|
| | NON FS | no | 1 | 25600| 537599|
| root2 | DOS | no | 2 | 537600| 4745215|

# mount -r /dev/root2 /mnt/root2
mount: /dev/root2 not a valid file system or not type DOS: Invalid argument (err
or 22)

Does it mean that I have lost all data in those patitions? Can I regain the data?

Chacrint

Chacrint Charinthorn wrote:

> Please see below for the outcome of my "mount" attempt.
>
> | | EAFS | no | 0 | 0| 25599|
> | | NON FS | no | 1 | 25600| 537599|
> | root2 | DOS | no | 2 | 537600| 4745215|
>
> # mount -r /dev/root2 /mnt/root2
> mount: /dev/root2 not a valid file system or not type DOS: Invalid argument (err
> or 22)
>
> Does it mean that I have lost all data in those patitions? Can I regain the data?

We know that some of the data is there, because your `grep %disk
/dev/rhd1a` got some matches.

We need to go back to how this problem started in the first place. You
posted about a panic (I think). Then you moved the drive aside, did a
fresh install on a new drive, and put the old drive in as a secondary.

Can you explain any further what happened to the original drive? What
was it doing before it went down? What was the first indication of a
problem? Any hints that you have, any small observations you made,
might help someone else figure out how to fix the problem, even if it
seems meaningless to you.

>Bela<

> We need to go back to how this problem started in the first place. You
> posted about a panic (I think). Then you moved the drive aside, did a
> fresh install on a new drive, and put the old drive in as a secondary.
>
> Can you explain any further what happened to the original drive? What
> was it doing before it went down? What was the first indication of a
> problem? Any hints that you have, any small observations you made,
> might help someone else figure out how to fix the problem, even if it
> seems meaningless to you.

Thank you for your continuous help on my problem.

I will refer to my post three weks ago.

chacrint@hotmail.com (Chacrint Charinthorn) wrote in message news:<bfe227db.0310120527.7c521050@posting.google. com>...
> I am running OSR504 with 2 IDE ATA 100 HDDs. A few weeks ago,
> - I took out my 3Com 905c out and plug the Dlink 530 NIC instead
> without uninstalling the 3Com's driver.
> - Once I finished installing the drivers for Dlink 530, link_unix,
> and build new environment, I reboot.
> - The Dlink NIC wasn't recognised so I took it out, uninstalled the
> Dlink 530 drivers and put the Micronet NIC instead. Everything went
> fine so I left it there for 1 night.
> - The next morning I found that the screen was screwed up and I reset
> the computer. The following message was found and it asked me to
> reboot.
>
> ----------------------------------
> "PANIC : srmountfun - Error 22
> mounting rootdev hd(1/42) Cannot dump 380745 pages to dumpdev hd
> (1/41) Space for only 0 pages."
> ----------------------------------

After this happened. You are right that I took the 1st disk from the
system put it as Primary-Slave. Then I,

- Re-install OSR5.04 on a new Primary-Master Disk.
- Run divvy /dev/hd1a and I saw that the "root" partition was
changed to "DOS" but others are still "HTFS". I realised that that's
the cause of "srmountfun" problem. I had "root" partition as "DOS"!
- I renamed the "DOS" and "HTFS" partitions and tried to mount them
but I could not mount the "DOS" even I installed the OSR5 "DOS"
support.
- I mounted all other "HTFS" as Read-Write using scoadmin a few
hours after that I found that I could not access the directories on
the mounted "HTFS" partitions.
- I reboot because I realised that there were some IP alias
conflicts with another server on the network.
- After I reboot. I had some errors saying it could not mount those
"HTFS" partitions.
- I ran divvy again and found that they have all changed to "DOS"


Chacrint

Chacrint Charinthorn wrote:

> I will refer to my post three weks ago.
>
> chacrint@hotmail.com (Chacrint Charinthorn) wrote in message news:<bfe227db.0310120527.7c521050@posting.google. com>...
> > I am running OSR504 with 2 IDE ATA 100 HDDs. A few weeks ago,
> > - I took out my 3Com 905c out and plug the Dlink 530 NIC instead
> > without uninstalling the 3Com's driver.
> > - Once I finished installing the drivers for Dlink 530, link_unix,
> > and build new environment, I reboot.
> > - The Dlink NIC wasn't recognised so I took it out, uninstalled the
> > Dlink 530 drivers and put the Micronet NIC instead. Everything went
> > fine so I left it there for 1 night.
> > - The next morning I found that the screen was screwed up and I reset
> > the computer. The following message was found and it asked me to
> > reboot.
> >
> > ----------------------------------
> > "PANIC : srmountfun - Error 22
> > mounting rootdev hd(1/42) Cannot dump 380745 pages to dumpdev hd
> > (1/41) Space for only 0 pages."
> > ----------------------------------
>
> After this happened. You are right that I took the 1st disk from the
> system put it as Primary-Slave. Then I,
>
> - Re-install OSR5.04 on a new Primary-Master Disk.
> - Run divvy /dev/hd1a and I saw that the "root" partition was
> changed to "DOS" but others are still "HTFS". I realised that that's
> the cause of "srmountfun" problem. I had "root" partition as "DOS"!
> - I renamed the "DOS" and "HTFS" partitions and tried to mount them
> but I could not mount the "DOS" even I installed the OSR5 "DOS"
> support.
> - I mounted all other "HTFS" as Read-Write using scoadmin a few
> hours after that I found that I could not access the directories on
> the mounted "HTFS" partitions.
> - I reboot because I realised that there were some IP alias
> conflicts with another server on the network.
> - After I reboot. I had some errors saying it could not mount those
> "HTFS" partitions.
> - I ran divvy again and found that they have all changed to "DOS"

When you first posted this, I don't think I understood that some of the
filesystems were showing as HTFS at first, and only turned into "DOS"
later. That implies two things: that there was never a geometry
problem, and that whatever was causing the problem was an active,
ongoing process. It seems as if writes to the disk were being
corrupted.

It seems that something you changed caused disk writes to be corrupted.
You mentioned a series of NICs: a 3C905C, DLink 530, and then a
"Micronet". It seems unlikely, but maybe one of those hardware changes,
or the corresponding drivers, conflicted with something and caused disk
corruption. Another possibility is that you had bumped the IDE cable
while opening the machine.

There might still be a way to rescue your filesystems. Now that we have
an idea of how they were corrupted, we have some idea of how to proceed.
Your secondary filesystems were OK until you mounted them. During a
mount-unmount cycle, the superblock is written. In this case it was
written with corrupt data. If that's _all_ that was corrupted, the
filesystems are recoverable. You just need to copy in a valid
superblock.

With HTFS this isn't so easily done by hand. The easiest way is a
little complicated. On a scratch drive, you make a filesystem the same
size as the filesystem you're trying to rescue. You copy its superblock
onto the filesystem to be rescued, then run `fsck -o full` on it.

Start by writing down the sizes of each filesystem you're trying to
rescue. Run `divvy` on the drive. The size of each filesystem is the
divvy "Last Block" - "First Block" + 1. A filesystem starting on block
0, ending on 99, is 100 blocks long. So now you make a filesystem of
the same size on your scratch drive -- it could start at 0 and end at
99, or start at 12345 and end at 12444, as long as the size is the same.
Tell divvy to "c[reate]" a filesystem there, then "q[uit]", "i[nstall]".
Be sure you're doing this to a scratch drive!

Once the filesystem is made, capture its superblock:

dd if=/dev/scratchfs of=/tmp/superblock-100 iseek=1 count=1

Then you can stamp this superblock onto the filesystem you're trying to
rescue:

dd if=/tmp/superblock-100 of=/dev/rescue-me oseek=1 count=1

and then:

fsck -o full /dev/rescue-me

Whether this will work depends on how bad the original corruption was,
and whether you've actually fixed whatever was causing it. If it was a
loose cable, you probably fixed it when you swapped in the replacement
root drive. If it was a conflict caused by the NICs, it must have been
the middle one and was fixed when you put in the third one, or you would
be having corruption problems on the new drive. So the remaining big
question is, how much got destroyed during the period of corruption?

Before you do any of this, you should make an image backup of the whole
hard drive. That way you can unwind any changes you make that are
unsuccessful.

>Bela<