reconstructing dparam disk geometry changed

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: OSR 5.0.6a Strange problem after BIOS upgrade FLASH and IDE
Date: Sun, 13 Jan 2002 22:46:45 GMT
References: <3C41B914.8D64B3E0@tkg.ca> <Pine.SC5.4.43.0201131003210.15491-100000@xenau105.zenez.com> 

Boyd Lynn Gerber wrote:

> > 1. Add 80G HD, MB BIOS not able to boot.
> > 2. Upgraded MB BIOS, Unix bootable, hence BIOS upgrade not the problem.
> > 3. mkdev hd to add disk, reboot Unix so all HW and BIOS tested twice.
> > 4. Unix can find the 80G HD and FDISK it, so Unix is not having a problem.
> > 5. On reboot now getting a stage 1 boot error.  The last thing that was done
> >    was the fdisk, any chance of 'fdisking' the wrong drive?  I normally
> >    run 'mkdev hd' a second time, not a manual fdisk.  What was the reason
> >    to run fdisk and reboot?
> 
> This is correct for the most part.  The second mkdev hd all that was done
> was show partition table... no partition was shown on disk, i.e. blank
> partition.  Create partition use whole disk. quit install partition.  hit
> the delete key to stop mkdev hd.  Then with fdisk all I did was show the
> partition and quit no update just quit.
> 
> > > partitions with the sizes all being correct but did not have the EAFS or
> > > HTFS in the filesystem type.  The only time I have seen this with SCSI
> > > devices is with the adaptec BIOS being in different modes LBA vers non
> > > LBA.
> > >
> >
> > Yes, changing a disks parameters and running FDISK on it leaves a partition
> > table, but generally no correct filesystems.
> >
> > Can you HD the raw device that points to the boot filesystem?  Does it
> > still have data?  It may be possible to recover the filesystems with
> > a raw disk editor.  Tough work.
> 
> hd on boot and root show data.  It even looks good compared to the booting
> 80G HD.

We're not going to be able to solve this in cookbook manner for you --
you have to be at the controls with a clear understanding of what you're
doing.

It sound like, during all the gyrations, you overwrite the disk
parameters for the 40GB disk (equivalent of running `dparam /dev/hdx0
bunch of numbers`).  To restore access to the disk, you need to restamp
it with the right parameters, where "right" means "whatever they were
before the drive became inaccessible".

There are many ways to learn the old parameters.  Perhaps the easiest is
this: connect it to a working system and dump the contents of the drive,
searching for "cyls=".  See, somewhere on the root filesystem on that
drive are the files /usr/adm/messages and /usr/adm/syslog, both of which
will have a whole bunch of messages similar to:

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

You're looking for the messages associated with "type=W0" (i.e. primary
wd1010/IDE controller), "unit=0" (master).

Since you have a new blank-slate Unix install on the 80GB drive, and
have the 40GB drive in place, you're most of the way there.  You need to
do something like:

  strings -a /dev/rhd10 | grep cyls= > /tmp/old-parms

Then look through the output.  You will have lost the "%disk... 0x"
parts because `strings` things a TAB is a non-printable char.  So the
output will look like a bunch of:

 14   -  type=W0 unit=0 cyls=2434 hds=255 secs=63

lines.  Pick out the W0/0 entries.  If they aren't all identical, choose
the one that appears most frequently.  Apply those parameters to the
drive.  Then look at it with fdisk & divvy, see if things look sane (in
particular, you're looking for divvy to report sane filesystem types).

By "apply those parameters to the drive", I mean something like:

  dparam /dev/rhd10                         # print existing parms
  dparam /dev/rhd10 cyls hds ... cyls secs

where "..." should be the middle 4 of the existing parameters.  (cyls
appears twice, once for the size of the drive and once for landing
zone.)

>Bela<
 

Macworld Mac Security Superguide $9.99

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.