OSR 5.0.6a Strange problem after BIOS upgrade FLASH and IDE
Boyd Lynn Gerber
having a strange problem getting to my friends IDE disks. Usually I use
SCSI but a friend had a problem and I wanted to see if I could duplicate
it and I did.
OSR 5.0.6a
Mother Board (MB) is a gigabyte BX2000a BIOS was .F1 and upgraded to .F8
the ATA HD are from WD. One is a 40G and the other is a 80G. He does not
want to loose what is on the 40G hard disk and he does not have backups.
He has been running OSR 5.0.6a since July with all the patches to Dec of
2001 and not had any real problems. He tried to add a 80G hard disk and
the MB would lock up. I downloaded the lastest BIOS Upgrade BX2000.F8.
I saved a copy of the BIOS before the FLASH upgrade. After the FLASH
upgrade both disks could be seen in the BIOS. He booted the system and
did a mkdev hd to add the disk. After the reboot the system saw the 80G
HD. So he ran fdisk and created a UNIX partition on the disk and shutdown
the system. He then tried to reboot the system and he got a boot stage 1
error on the boot disk. This is where I got involved.
I removed the 40G HD and booted from the OSR 5.0.6 CD. The 80G HD did
have a UNIX partition that was blank.
This is the current status of the system. The BIOS has the same USER
defined Head, Cylinder, and sectors and size.
was
Primary IDE Controller
40G HD master
30G HD slave
Secondary IDE Controller
80G HD master
CD Drive Slave
Now
Primary IDE Controller
80G HD master
30G HD slave
Secondary IDE Controller
40G HD master
CD Drive Slave
I had a system with the same MB and BIOS version but with SCSI devices.
I put the IDE junk in my system and tried to boot and could not from the
40G HD. When I add the 80G disk my system froze with the old BIOS
version. I flashed my BIOS to the new version and still could not boot
from the 40G HD. I then switched the 40G and 80G and installed OSR 5.0.6a
on the 80G disk with the new BIOS. All it had was a valid UNIX partition.
I then manually created the devices in the /dev directory. I could not
mount the 40G root partition. I brought it up in divvy and it showed the
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.
I am not a good IDE person so I thought maybe there would be something
similar in the BIOS. I the ran the BIOS find IDE drives and it has both
types with about the same size. I have tried them both. divvy always
shows the correct partitions but never has the correct file system type.
Is there any thing that can be done to get the data off this HD so far all
I have done is look at it with divvy. With SCSI all I have to do is
change the type on the adapter BIOS reboot and then the partitions
are correct for the OS filesystem type. This did not work with the IDE
drives on my system.
Any suggestions?
Thanks,
--
Boyd Gerber <ger...@zenez.com>
ZENEZ 3748 Valley Forge Road, Magna Utah 84044
Mike Brown
>
> I am not really an IDE person so I am asking for a bit of insite. I am
> having a strange problem getting to my friends IDE disks. Usually I use
> SCSI but a friend had a problem and I wanted to see if I could duplicate
> it and I did.
>
> OSR 5.0.6a
> Mother Board (MB) is a gigabyte BX2000a BIOS was .F1 and upgraded to .F8
> the ATA HD are from WD. One is a 40G and the other is a 80G. He does not
> want to loose what is on the 40G hard disk and he does not have backups.
>
> He has been running OSR 5.0.6a since July with all the patches to Dec of
> 2001 and not had any real problems. He tried to add a 80G hard disk and
> the MB would lock up. I downloaded the lastest BIOS Upgrade BX2000.F8.
> I saved a copy of the BIOS before the FLASH upgrade. After the FLASH
> upgrade both disks could be seen in the BIOS. He booted the system and
> did a mkdev hd to add the disk. After the reboot the system saw the 80G
> HD. So he ran fdisk and created a UNIX partition on the disk and shutdown
> the system. He then tried to reboot the system and he got a boot stage 1
> error on the boot disk. This is where I got involved.
So,
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?
Yes, changing a disks parameters and running FDISK on it leaves a partition
table, but generally no correct filesystems.
> I am not a good IDE person so I thought maybe there would be something
> similar in the BIOS. I the ran the BIOS find IDE drives and it has both
> types with about the same size. I have tried them both. divvy always
> shows the correct partitions but never has the correct file system type.
>
> Is there any thing that can be done to get the data off this HD so far all
> I have done is look at it with divvy. With SCSI all I have to do is
> change the type on the adapter BIOS reboot and then the partitions
> are correct for the OS filesystem type. This did not work with the IDE
> drives on my system.
>
> Any suggestions?
>
> Thanks,
>
> --
> Boyd Gerber <ger...@zenez.com>
> ZENEZ 3748 Valley Forge Road, Magna Utah 84044
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.
Mike
--
Michael Brown
The Kingsway Group
Boyd Lynn Gerber
> Boyd Lynn Gerber wrote:
> So,
>
> 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.
Bela Lubkin
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<
Boyd Lynn Gerber
On Sun, 13 Jan 2002, Bela Lubkin wrote:
> 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:
Thanks, I now have more information I would like to share.
I had the 80G hard disk working great. I could not get the 40G to work
yet. Every time I set the BIOS parameters to what was shown I would get
hard disk failure. I then looked at the 80G hard disk and noticed the
size was wrong. SO, I tried to set it and it would not set. I ran the
IDE detection just like I did before installing OSR5.0.6 and then I got
the boot stage one error. Now I can not seem to get the 80G to boot
either just like the 40G. Here are the details.
BIOS before OSR 5.0.6 install on 80G HD.
TYPE SIZE CYN HEADS PRE LZ SECTORS MODE
USER 80G 9729 255 0 38308 63 LBA
BIOS after OSR 5.0.6a install on 80G HD
USER 17109M 9729 255 0 38308 63 LBA
Trying to setup 40G running IDE HD detect. I enterered N for the 80G
HD so I thought nothing would happen but it showed.
USER 80G 9729 255 0 38308 63 LBA
Now the system will not boot and I get the stage 1 boot error.
If I set it to the CYN, HEADS, PRE, LZ, Sectors are all not highlighted
AUTO 80G 9729 255 0 38308 63 AUTO
I can change them to zeros and it always returns the above when it tries
to boot and I get the stage 1 boot error.
Current on my system not my friends.
BIOS before OSR 5.0.6 install on 40G HD.
TYPE SIZE CYN HEADS PRE LZ SECTORS MODE
USER 40G 4865 255 0 19157 63 LBA
BIOS from the above strings command
USER 40G 9693 128 0 19157 63 LBA
The only way I can get the above into the BIOS is with
USER 40G 9693 128 0 19157 63 LARGE
USER 40G 9693 128 0 19157 63 NORMAL
USER 40G 9693 128 0 19157 63 AUTO
When I try to set the BIOS to
USER 40G 9693 128 0 19157 63 LBA
it always goes to
USER 40G 4865 255 0 19157 63 LBA
So I now know how my friend messed up the booting of the HD. He ran the
IDE auto detect and answered N or 2 for the 40G HD and he thought it was
the same. He then chose 2 for LBA mode for the 80G HD to set the HD up
and upon rebooting the system the 40G had came up with the boot stage 1
error. So now my question. How do I get the system back working so I can
boot the machine and get the information off the 40G HD. The 80G hard
disk is in now in a similar state as his 40G HD was when he brought his
computer to me. I have tried messing with the BIOS. I can not get it
back to the weird SIZE with the correct BIOS HEADS, CYN, SECTORS and MODE
Moral do not run IDE auto detect. Now I just have to figure out how to
get things to work. I am trying to boot from the OSR 5.0.6 CD and get the
80G to boot. I will post more information when I get it. Any suggestions
are greatly appreciated.
Thanks,
Mike Brown
You can try booting the PC with no hard drive attached, clear the HD setup,
then connect only the 40Gbyte and try to set it up in the BIOS. It may be
that the new REV of BIOS will not allow the original settings, and you may
have to back rev the MB. Your original post lead me to believe that the HD
setup was done before the reboots, and BIOS settings where not the problem.
Boyd Lynn Gerber
On Sun, 13 Jan 2002, Bela Lubkin wrote:
> 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/rhd20 | grep cyls= > /tmp/old-parms
I found 9693 128 63 as the correct parameters.
> dparam /dev/rhd10 # print existing parms
> dparam /dev/rhd10 cyls hds ... cyls secs
dparam /dev/rhd20 9693 128 0 0 0 8 19157 63 and setting the bios to auto
was the solution.
I have found through a bit of testing that after a HD has been installed
and working to not run the BIOS HD detect when adding a new HD. It is
better to manually set it up with the proper HD settings.
Thanks to every one. I was finally able to recover my friends data.
Good Luck
Bela Lubkin
> On Sun, 13 Jan 2002, Bela Lubkin wrote:
> > 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/rhd20 | grep cyls= > /tmp/old-parms
>
> I found 9693 128 63 as the correct parameters.
>
> > dparam /dev/rhd10 # print existing parms
> > dparam /dev/rhd10 cyls hds ... cyls secs
>
> dparam /dev/rhd20 9693 128 0 0 0 8 19157 63 and setting the bios to auto
> was the solution.
>
> I have found through a bit of testing that after a HD has been installed
> and working to not run the BIOS HD detect when adding a new HD. It is
> better to manually set it up with the proper HD settings.
>
> Thanks to every one. I was finally able to recover my friends data.
You seem to think that the most important thing learned here is "don't
run BIOS HD detect after the HD is already working with OpenServer". I
say you've learned something far more important (which ought to be
written up for the FAQ).
That is: if you _do_ run the BIOS HD detect, and lose control of the
drive, you can recover it.
First, learn the "right" parameters according to Unix. You might have
previously recorded them, might be able to `strings` the drive, might be
able to examine /usr/adm/messages or /usr/adm/syslog from a prior backup
of the drive. Or you might, in fact, be able to use one of the BIOS's
parameter sets (does 9693/128/63 match any of the configs the BIOS came
up with?) -- that is, it may be the case that even with the BIOS
claiming the same parameters as it always did, you still need to have
Unix restamp the drive.
Second, restamp the drive. That means getting the Unix kernel up and
running, could be from a boot floppy, the install CD with "tools", a 3rd
party crash recovery floppy (RecoverEDGE, AirBag, etc.), or by putting
in a different hard disk and doing a minimal install. Get to a shell
prompt. Find or create a device node that points to the drive in
question (/dev/rhd00 if it's primary/master; could be rhd10 or something
else). Run:
dparam -w /dev/rhd00
dparam /dev/rhd00
# or rhd10 or whatever
to print existing parameters, then run:
dparam /dev/rhd00 cyls hds ppp qqq rrr sss cyls secs
# or rhd10 or whatever
where ppp/qqq/rrr/sss are the middle 4 of the existing parameters, and
cyls/hds/secs are the "right" parameters. "cyls" gets stamped twice,
once for the size of the drive and once for landing zone.
Third, go into BIOS setup and set the drive back to "auto".
Fourth, if necessary, rearrange drives (e.g. if this was once, and is
desired again to be the boot drive, move it back to primary/master).
This won't necessarily work in all cases, it's just _one_ discovered way
of recovering from an IDE disk geometry problem. Also, steps "Second"
and "Third" might need to be done in the reverse order, and you will
probably have to change things again in the BIOS if you physically
rearrange drives.
>Bela<
Tony Lawrence
> Boyd Lynn Gerber wrote:
>
>
>>On Sun, 13 Jan 2002, Bela Lubkin wrote:
>>
>>>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/rhd20 | grep cyls= > /tmp/old-parms
>>>
>>I found 9693 128 63 as the correct parameters.
>>
>>
>>> dparam /dev/rhd10 # print existing parms
>>> dparam /dev/rhd10 cyls hds ... cyls secs
>>>
>>dparam /dev/rhd20 9693 128 0 0 0 8 19157 63 and setting the bios to auto
>>was the solution.
>>
>>I have found through a bit of testing that after a HD has been installed
>>and working to not run the BIOS HD detect when adding a new HD. It is
>>better to manually set it up with the proper HD settings.
>>
>>Thanks to every one. I was finally able to recover my friends data.
>>
>
> You seem to think that the most important thing learned here is "don't
> run BIOS HD detect after the HD is already working with OpenServer". I
> say you've learned something far more important (which ought to be
> written up for the FAQ).
You just did :-)
and thanks..
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Tony Lawrence
> Bela Lubkin wrote:
>
>> You seem to think that the most important thing learned here is "don't
>> run BIOS HD detect after the HD is already working with OpenServer". I
>> say you've learned something far more important (which ought to be
>> written up for the FAQ).
>
>
>
> You just did :-)
>
> and thanks..
And here's a first draft of the FAQ, comments and correction always welcome:
http://pcunix.com/SCOFAQ/scotec6.html#recoverdrive
Boyd Lynn Gerber
> You seem to think that the most important thing learned here is "don't
> run BIOS HD detect after the HD is already working with OpenServer". I
> say you've learned something far more important (which ought to be
> written up for the FAQ).
For a novice I think knowing that if they run the HD detect after they
have installed the system will make it unbootable and unmountable is
important. I would never have guess that even though the BIOS was
orignally set using the BIOS HD detect, that running it again would make
the system unbootable. I agree totally about writing it up. I have done
the first part and already sent it to tony. I am trying to decide how
best to write up the rest.
> That is: if you _do_ run the BIOS HD detect, and lose control of the
> drive, you can recover it.
>
> First, learn the "right" parameters according to Unix. You might have
> previously recorded them, might be able to `strings` the drive, might be
> able to examine /usr/adm/messages or /usr/adm/syslog from a prior backup
> of the drive. Or you might, in fact, be able to use one of the BIOS's
> parameter sets (does 9693/128/63 match any of the configs the BIOS came
> up with?) -- that is, it may be the case that even with the BIOS
> claiming the same parameters as it always did, you still need to have
> Unix restamp the drive.
I have done alot of different recovery with SCSI drives. I have mucked
with drives after a BTLD I wrote for a SCSI controller skrewed my disk and
I did not have a backup. I just have never done it wit IDE drives. So
the procedure was already well know on what to do once I found the correct
parameters. With SCSI devices and unknowns I often look at what is
happening with a SCSI sniffer or SCSI bus analyzer and then with dd I can
play with it and massage it to do what I want. I do not know if they make
such things for IDE, they may and I just have never used them. Sadly the
BIOS once upgraded would not give the magical 9693 128 63 parameters.
And all the syslog and messges file were compress using gz. To make a
long story short I dumped all the strings -a to a file and looked for know
file names. Then I used dd to get the data off the drive till I got the
file and was able to gunzip it.
I must admit I did find out that the IDE drive did have to be stamped with
the Unix restamp to get the drive to work after running the BIOS detect.
I did have a drive that I did not care what was on it. So I was able to
play and learn by distruction. I do not think I have ever done as many
installs as I did learning about how the IDE drives and OSR worked
together. I did this on 9 totally different Mother Boards (MB) and 40
different sizes of HDS on each MB.
> Second, restamp the drive. That means getting the Unix kernel up and
> running, could be from a boot floppy, the install CD with "tools", a 3rd
> party crash recovery floppy (RecoverEDGE, AirBag, etc.), or by putting
> in a different hard disk and doing a minimal install. Get to a shell
> prompt. Find or create a device node that points to the drive in
> question (/dev/rhd00 if it's primary/master; could be rhd10 or something
> else). Run:
I agree this would have been a lot easier with a thrid party backup, but
it was my friends drive and he has not purchased one and he did not have
any boot disk specific to his system. I did try at various stages with
with the F8 key while booting from the OSR 5.0.6 CD and with generic OSR
5.0.6a boot floppies. I never could get the generic boot floppies to
work. I did find that if my friend had made boot floppies specific to the
machine it could be done, but I never could get generice boot floppies to
to work. Part of the problem may have been my combination of different
SCSI controllers and IDE devices that I have.
> dparam -w /dev/rhd00
> dparam /dev/rhd00
> # or rhd10 or whatever
The dparam -w /dev/rhd20 did not fix the problem or what ever device
needed depending on where the drive was located. This often does fix the
problem with SCSI devices. I did find I had to match exactly the correct
parameters with how the device was configured.
> to print existing parameters, then run:
>
> dparam /dev/rhd00 cyls hds ppp qqq rrr sss cyls secs
> # or rhd10 or whatever
> where ppp/qqq/rrr/sss are the middle 4 of the existing parameters, and
> cyls/hds/secs are the "right" parameters. "cyls" gets stamped twice,
> once for the size of the drive and once for landing zone.
Good advice to get them.
> Third, go into BIOS setup and set the drive back to "auto".
>
> Fourth, if necessary, rearrange drives (e.g. if this was once, and is
> desired again to be the boot drive, move it back to primary/master).
>
> This won't necessarily work in all cases, it's just _one_ discovered way
> of recovering from an IDE disk geometry problem. Also, steps "Second"
> and "Third" might need to be done in the reverse order, and you will
> probably have to change things again in the BIOS if you physically
> rearrange drives.
Thanks for the previous good advice and words above. I did find that even
if the BIOS setting did match the drive it would not necessarily boot. I
did find that for all the 40 different drives I tested 32 being less than
40G and 8 being 40G or larger that on these 9 different MB's any thing
less that 30G worked great with the BIOS detect, but 40G and larger the
only setting that worked all the time was... (BTW I am trying to give this
below from memory so it may not be totally accurate.)
TYPE SIZE CYN HEADS PRE LZ SECTORS MODE
AUTO XXXX YYYY N NNNN NN AUTO
in my case you could not set the MODE to anything but AUTO because the
BIOS would give a hard disk failure with the correct CYN HEADS...SECTORS
after the BIOS had been flasked. What I did learn is different version of
Mother Board BIOS can and often do set things different. Fortunately auto
setting with a valid UNIX stamp/restamp does work. Getting it will varry
upon how the system is being used. I setup his system so I knew there was
a file called messages.org.gz syslog.org.gz so all I had to do was find it
and uncompress it. I have mucked with the dd images before and laid them
back on a hd not a lot of fund but it too does work.
Thanks,
Mike Brown
I may have been a bit terse in my previous post, but basically I have
had to set the correct settings for IDE after the BIOS has changed
them for me. The steps that somehow where important for me was to
boot the system with no hard drives, clear the bios settings, then
reconnect the original hard drive, then manually configure the original
settings. The drive remained unbootable until I had clear the BIOS with
no HD attached.
Getting the RecoverEdge report on drive parameters saved the day.