Professional Web Applications Themes

HTFS changed to DOS after doing divvy on /dev/hd1a - SCO

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

  1. #1

    Default HTFS changed to DOS after doing divvy on /dev/hd1a

    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 Guest

  2. #2

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     

    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 Guest

  3. #3

    Default HTFS changed to DOS after doing divvy on /dev/hd1a

    More info on the partition table:

    / : divvy /dev/hd1a
    +-------------------+------------+--------+---+-------------+------------+
    | Name | Type | New FS | # | First Block | Last Block |
    +-------------------+------------+--------+---+-------------+------------+
    | | EAFS | no | 0 | 0| 25599|
    | | NON FS | no | 1 | 25600| 537599|
    | root1 | DOS | no | 2 | 537600| 4745215|
    | | DOS | no | 3 | 4745216| 14985215|
    | u2 | DOS | no | 4 | 14985216| 25225215|
    | bkp | DOS | no | 5 | 25225216| 59737691|
    | | NON FS | no | 6 | 59737692| 59737701|
    | hd1a | WHOLE DISK | no | 7 | 0| 60042905|
    +-------------------+------------+--------+---+-------------+------------+
    59737702 1K blocks for divisions, 305203 1K blocks reserved for the system

    Earlier, the FSs of type "DOS" were "HTFS".

    Thanks for your kind assistance.

    Chacrint
    Chacrint Guest

  4. #4

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a



    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 so. I tried to manually keyed in the CHS into BIOS but this
    would not help.
     

    They are both running SCO Open server 5.04

    Thanks,
    Chacrint
    Chacrint Guest

  5. #5

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     
    >
    > 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 so. I tried to manually keyed in the CHS into BIOS but this
    > would not help.[/ref]

    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.
     
    >
    > They are both running SCO Open server 5.04[/ref]

    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 Guest

  6. #6

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

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

  7. #7

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     
    >
    > 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?[/ref]

    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
     

    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 Guest

  8. #8

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    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 Guest

  9. #9

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     

    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 Guest

  10. #10

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    > We need to go back to how this problem started in the first place. You 

    Thank you for your continuous help on my problem.

    I will refer to my post three weks ago.

    com (Chacrint Charinthorn) wrote in message news:<google.com>... 

    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 Guest

  11. #11

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     
    >
    > 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"[/ref]

    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 Guest

  12. #12

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Thanks Bela, I started with two partitions and it seemed to work. When
    I do "fsck -ofull", it generates a lot of warnings when I presses "y"
    to let it fix. When mounted (read only), all files and directories are
    put into the "lost+found" direstory with names like #0000011, or
    #0001885

    Is there anyway we can rename to the original file automatically?

    Chacrint



    Bela Lubkin <com> wrote in message news:<com>... 
    > >
    > > 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"[/ref]
    >
    > 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.
    > [/ref]
    Chacrint Guest

  13. #13

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     

    Some of the items in lost+found are directories; within those
    directories, the files should have their original names. In many cases
    you should be able to reconstruct the directory names from the names of
    the files.

    For this sort of crash recovery, you shouldn't be concerned about the
    files that belong to the operating system. You just want to get your
    data files out alive. Start by searching the wreckage for files with
    the names your applications use. If you are lucky, they will all be
    present in subdirectories, bearing their original filenames (but not
    pathnames).

    For the entries that were moved directly into lost+found, you'll need to
    do a manual inventory. You can identify both directories and files by
    their contents. You basically have to start with the pool of all
    nameless files and eliminate them one by one from your interest --
    either by copying them into a safe place under a new name, or by noting
    that they simply aren't interesting. Use `file`, `hd`, text pagers /
    viewers like `more` and `vi`. Executable binaries are probably not
    interesting (they're either part of the operating system or part of an
    application that you should be able to reinstall from original media).

    If you have old backups, restore them into a test location and use them
    to help you decide what _type_ of files you're looking at. For example
    you might have a nameless directory full of files whose names are
    intact, but don't mean anything to you. If you can find a directory
    with similar names (and files of similar size and contents) in the
    backup, you'll have a much better idea of what you're lookin at -- and
    whether it's valuable.

    Good luck.
     
    Bela Guest

  14. #14

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Bela, I really appreciate your help regarding this matter and also
    other useful information I wasn't normally aware of.

    I have now regained most of my data back apart from system software on
    the root partition which I can compile and install again.

    Cheers,

    Chacrint


    Bela Lubkin <com> wrote in message news:<com>... 
    >
    > Some of the items in lost+found are directories; within those
    > directories, the files should have their original names. In many cases
    > you should be able to reconstruct the directory names from the names of
    > the files.
    >
    > For this sort of crash recovery, you shouldn't be concerned about the
    > files that belong to the operating system. You just want to get your
    > data files out alive. Start by searching the wreckage for files with
    > the names your applications use. If you are lucky, they will all be
    > present in subdirectories, bearing their original filenames (but not
    > pathnames).
    >
    > For the entries that were moved directly into lost+found, you'll need to
    > do a manual inventory. You can identify both directories and files by
    > their contents. You basically have to start with the pool of all
    > nameless files and eliminate them one by one from your interest --
    > either by copying them into a safe place under a new name, or by noting
    > that they simply aren't interesting. Use `file`, `hd`, text pagers /
    > viewers like `more` and `vi`. Executable binaries are probably not
    > interesting (they're either part of the operating system or part of an
    > application that you should be able to reinstall from original media).
    >
    > If you have old backups, restore them into a test location and use them
    > to help you decide what _type_ of files you're looking at. For example
    > you might have a nameless directory full of files whose names are
    > intact, but don't mean anything to you. If you can find a directory
    > with similar names (and files of similar size and contents) in the
    > backup, you'll have a much better idea of what you're lookin at -- and
    > whether it's valuable.
    >
    > Good luck.
    > [/ref]
    Chacrint Guest

  15. #15

    Default Re: HTFS changed to DOS after doing divvy on /dev/hd1a

    Chacrint Charinthorn wrote:
     

    Congratulations! You had a real mess there. I wasn't sure whether full
    recovery was going to be possible, especially since you were learning
    how to use the tools along the way...
     
    Bela Guest

Similar Threads

  1. Everything I changed is gone
    By BJKNJ in forum Macromedia Contribute General Discussion
    Replies: 2
    Last Post: November 20th, 01:07 AM
  2. HTFS Filesystem
    By Michael in forum SCO
    Replies: 5
    Last Post: October 9th, 08:24 PM
  3. $name getting changed to $_
    By Brian in forum PERL Miscellaneous
    Replies: 2
    Last Post: August 5th, 11:03 PM
  4. "HTFS: No space on dev hd (1/32)"
    By person@24-119-32-27.cpe.cableone.net in forum SCO
    Replies: 0
    Last Post: July 18th, 01:05 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