PDA

View Full Version : Re: MBR switch on FDISK


jt3
June 4th 04, 07:30 PM
Appreciate the ref, Curt; the machine on which I had all my saved pages,
links, and threads is the one that went down.
Thanks for your time,
Joe
"Curt Christianson" > wrote in message
...
> Hi Joe,
> See this MS article on FDISK /MBR:
>
> FDISK /MBR Rewrites the Master Boot Record
> http://support.microsoft.com/?kbid=69013
> HTH,
> --
> Curt--and NOT the MVP Curt Christianson (I wish!)
> W98 Support & Discussion:
> http://dundats.proboards27.com/index.cgi
> Windows How-tos and and Freeware:
> http://mvps.org/PracticallyNerded/
> Windows Help & Discussion:
> http://forum.aumha.org/
>
> "jt3" > wrote in message
> ...
> > I think I recall reading someone posting that the /MBR switch on
FDISK
> > not only rewrites the master boot record, but also wipes out partition
> table
> > data, so that if you use /MBR on a disk with multiple partitions on it,
> you
> > lose the partition data. Is this true?
> > I have a problem with a corrupted MBR (I think) and my old version
of
> > Partition Magic doesn't do the MBR, apparently.
> > Thanks for your time, as always,
> > Joe
> >
> >
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.698 / Virus Database: 455 - Release Date: 6/3/04
>
>

jt3
June 4th 04, 07:56 PM
Yes that was what I was recalling something about--as I said to Curt,
all my refs went down with that machine.
The problem here is that this is wierd--it's clear that the boot code
is working to some degree--'Starting Windows 98' comes up first, which it
normally wouldn't show, then it comes up with 'Type the name of the Command
Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though there's no
disk, boot or otherwise in the floppy drive. Also, putting in the startup
disk doesn't get me anywhere--after choosing boot without cd-rom, to
simplify it, it just hangs with the floppy drive trying to access something.
But it seems that this must be coming from IO.SYS, since there couldn't be
much else doing it, if no COMMAND.COM has been loaded (of course..who
knows..).
I should mention that this started with an *apparent* CMOS failure--a
little strange since I just replaced it with a new Li cell just a year and a
month ago. Nothing very strange seemed to have happened to it, except all
the drives (floppies, too) had been lost, and this was on the first boot of
the day.
I reset the boot order for it to boot A: first (had been C: then A:) and
was able then to boot to DOS from the startup disk, but could not see the
other drives (just A:). I had previously installed an old version (4.0) of
Partition Magic and used the PM recovery disk to find out that the
partitions were all still there--but this version doesn't do anything for
MBRs, apparently.
In short, the EOS byte could easily be missing, AFAIK, and the only
thing I can see at the moment is to use Debug to see if it's still there.
Clearly, I would welcome any thoughts on the subject before I try
anything. I'm a little leery of slaving the disk to my other machine, if I
don't know for sure what caused the problem.

Thanks for your time,
Joe
"PCR" > wrote in message
...
> Enter "FDISK /MBR"
> This will rewrite the code portion of the Master Boot Record,
> leaving the Partition Table untouched, except it may muss the partition
> table, if there is a missing End-Of-Sector marker (55AA), per
> http://support.microsoft.com/?kbid=149877
> Boot Record Signature AA55 Not Found
>
> Here are the warnings against it...
>
> (a) If you have a boot sector virus, you may lose access to all
> partitions. Then
> http://www.terabyteunlimited.com/utilities.html MBRWork "might" help to
> recover them.
>
> (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast, a
> boot manager, then that will need to be reestablished afterwards.
> http://www.aefdisk.com/ FDISK & Boot Manager
> http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP Overlay
> Utility & FDISK
>
> (c) FDISK may be buggy. So? Use MBRWork to do it, or
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
> solve the 55AA thing.)
>
> (d) If for some reason the "geometry" setting in BIOS does not match the
> hard drive, then any write to the drive may be destructive. So, go into
> BIOS and have it "automatically detect" the proper setting. (If you can
> DIR the drive in DOS, then you have proven the geometry is right. Well,
> Blanton says even that may not be true.)
>
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> should things get worse after this,
> PCR
>
> "jt3" > wrote in message
> ...
> | I think I recall reading someone posting that the /MBR switch on
> FDISK
> | not only rewrites the master boot record, but also wipes out partition
> table
> | data, so that if you use /MBR on a disk with multiple partitions on
> it, you
> | lose the partition data. Is this true?
> | I have a problem with a corrupted MBR (I think) and my old version
> of
> | Partition Magic doesn't do the MBR, apparently.
> | Thanks for your time, as always,
> | Joe
> |
> |
>
>

PCR
June 4th 04, 10:50 PM
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
Err Msg: The Following File Is Missing or Corrupt...
(187641) - When you start your computer, you may receive the following
error message: The following file is missing or corrupt: COMMAND.COM.
Type the name of the Command Interpreter.

It says...
.......Quote article...................
RESOLUTION
To resolve this problem, use the MS-DOS 6.x Upgrade Setup Disk 1 to
restart your computer, and then use the SYS command on drive C. To do
so, follow these steps:

1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and then
restart your computer.
2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS Setup.
3. Type sys c:, and then press ENTER.
4. Restart your computer.
.......End of quote....................

HOWEVER... here are some warnings...

This will copy certain system files (IO.sys, Command.com & perhaps
MSDOS.sys) from the Startup Diskette to C:\. (It also sets the BPB drive
number to HD0, so that it is now in the bootstrap. It does so, no matter
whether it is HD0. To boot it, one must still move it to be HD0,
however.) You may now be able to boot to Windows, if all folders are
intact. If not, some further adjustment need be done to "MSDOS.sys",
that was copied to C:\. The floppy has just a shell of it. Well, remove
the floppy & boot.

Oh gosh! Here are some warnings from Jeff Richards, MS MVP W95/W98,
about "SYS C:". DON'T DO IT, he says, if:

(a) "Major errors were reported in Scandisk."
(b) "A drive is moved from one machine to another", because of the next
two, maybe.
(c) "The BIOS setting for a drive is changed (eg, LBA to LARGE)."
(d) "A drive that uses overlay software is operated without the overlay
loaded."


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"jt3" > wrote in message
...
| Yes that was what I was recalling something about--as I said to
Curt,
| all my refs went down with that machine.
| The problem here is that this is wierd--it's clear that the boot
code
| is working to some degree--'Starting Windows 98' comes up first, which
it
| normally wouldn't show, then it comes up with 'Type the name of the
Command
| Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
there's no
| disk, boot or otherwise in the floppy drive. Also, putting in the
startup
| disk doesn't get me anywhere--after choosing boot without cd-rom, to
| simplify it, it just hangs with the floppy drive trying to access
something.
| But it seems that this must be coming from IO.SYS, since there
couldn't be
| much else doing it, if no COMMAND.COM has been loaded (of course..who
| knows..).
| I should mention that this started with an *apparent* CMOS
failure--a
| little strange since I just replaced it with a new Li cell just a year
and a
| month ago. Nothing very strange seemed to have happened to it, except
all
| the drives (floppies, too) had been lost, and this was on the first
boot of
| the day.
| I reset the boot order for it to boot A: first (had been C: then
A:) and
| was able then to boot to DOS from the startup disk, but could not see
the
| other drives (just A:). I had previously installed an old version
(4.0) of
| Partition Magic and used the PM recovery disk to find out that the
| partitions were all still there--but this version doesn't do anything
for
| MBRs, apparently.
| In short, the EOS byte could easily be missing, AFAIK, and the
only
| thing I can see at the moment is to use Debug to see if it's still
there.
| Clearly, I would welcome any thoughts on the subject before I try
| anything. I'm a little leery of slaving the disk to my other machine,
if I
| don't know for sure what caused the problem.
|
| Thanks for your time,
| Joe
| "PCR" > wrote in message
| ...
| > Enter "FDISK /MBR"
| > This will rewrite the code portion of the Master Boot Record,
| > leaving the Partition Table untouched, except it may muss the
partition
| > table, if there is a missing End-Of-Sector marker (55AA), per
| > http://support.microsoft.com/?kbid=149877
| > Boot Record Signature AA55 Not Found
| >
| > Here are the warnings against it...
| >
| > (a) If you have a boot sector virus, you may lose access to all
| > partitions. Then
| > http://www.terabyteunlimited.com/utilities.html MBRWork "might" help
to
| > recover them.
| >
| > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast,
a
| > boot manager, then that will need to be reestablished afterwards.
| > http://www.aefdisk.com/ FDISK & Boot Manager
| > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
Overlay
| > Utility & FDISK
| >
| > (c) FDISK may be buggy. So? Use MBRWork to do it, or
| > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
| > Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
| > solve the 55AA thing.)
| >
| > (d) If for some reason the "geometry" setting in BIOS does not match
the
| > hard drive, then any write to the drive may be destructive. So, go
into
| > BIOS and have it "automatically detect" the proper setting. (If you
can
| > DIR the drive in DOS, then you have proven the geometry is right.
Well,
| > Blanton says even that may not be true.)
| >
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| >
| > "jt3" > wrote in message
| > ...
| > | I think I recall reading someone posting that the /MBR switch
on
| > FDISK
| > | not only rewrites the master boot record, but also wipes out
partition
| > table
| > | data, so that if you use /MBR on a disk with multiple partitions
on
| > it, you
| > | lose the partition data. Is this true?
| > | I have a problem with a corrupted MBR (I think) and my old
version
| > of
| > | Partition Magic doesn't do the MBR, apparently.
| > | Thanks for your time, as always,
| > | Joe
| > |
| > |
| >
| >
|
|

jt3
June 5th 04, 04:13 AM
That's what I was trying to say: although the PM 'Recovery Disk'
(mainly a
boot disk with PM on it) shows the partitions on both disks as present and
with no problems, the boot disk DOS can't see them--not even C:\--even
though if you don't use the boot disk, it's clearly using the C drive to get
the message: 'Type the name of the Command Interpreter....' as I described
previously.
I think this may go back to a thread back in April, or March, in which
you and cquirke and several other people got involved, but then it was a
question of Restarting in DOS Mode. Although I finally thought that I had
the
answer in the question of the receipt of the Windows shutdown broadcast (and
the answer may still lie there) I was never able to fix it, and other things
(the machine I'm using now) came to the fore. Unfortunately, I only
archived a few of the posts, and I was using the MS support interface at the
time. The server doesn't seem to have retained any posts prior to the
beginning of May, so I can't find the thread there, and it probably wouldn't
do much good, since I doubt I could convince anyone that the two are
related. Would take even longer to explain why I think so, and it's
irrelevant, if the thread's not available.
Obviously, this rambling reflects the state of my understanding, but it
comes down to: If PM can see the disks and the partitions, (1) why can't a
boot disk see any of them, and (2) how does one access anything on the disk
if the boot disk can't see it. Along the way, I might mention that this is
an installation without any older DOS on it, so that it would be deadly to
overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files would have to
come off the W98SE installation disk, and that's a little difficult as it
stands. I certainly don't want to reformat the disk.

Thanks,
Joe
"PCR" > wrote in message
...
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> Err Msg: The Following File Is Missing or Corrupt...
> (187641) - When you start your computer, you may receive the following
> error message: The following file is missing or corrupt: COMMAND.COM.
> Type the name of the Command Interpreter.
>
> It says...
> ......Quote article...................
> RESOLUTION
> To resolve this problem, use the MS-DOS 6.x Upgrade Setup Disk 1 to
> restart your computer, and then use the SYS command on drive C. To do
> so, follow these steps:
>
> 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and then
> restart your computer.
> 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS Setup.
> 3. Type sys c:, and then press ENTER.
> 4. Restart your computer.
> ......End of quote....................
>
> HOWEVER... here are some warnings...
>
> This will copy certain system files (IO.sys, Command.com & perhaps
> MSDOS.sys) from the Startup Diskette to C:\. (It also sets the BPB drive
> number to HD0, so that it is now in the bootstrap. It does so, no matter
> whether it is HD0. To boot it, one must still move it to be HD0,
> however.) You may now be able to boot to Windows, if all folders are
> intact. If not, some further adjustment need be done to "MSDOS.sys",
> that was copied to C:\. The floppy has just a shell of it. Well, remove
> the floppy & boot.
>
> Oh gosh! Here are some warnings from Jeff Richards, MS MVP W95/W98,
> about "SYS C:". DON'T DO IT, he says, if:
>
> (a) "Major errors were reported in Scandisk."
> (b) "A drive is moved from one machine to another", because of the next
> two, maybe.
> (c) "The BIOS setting for a drive is changed (eg, LBA to LARGE)."
> (d) "A drive that uses overlay software is operated without the overlay
> loaded."
>
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> should things get worse after this,
> PCR
>
> "jt3" > wrote in message
> ...
> | Yes that was what I was recalling something about--as I said to
> Curt,
> | all my refs went down with that machine.
> | The problem here is that this is wierd--it's clear that the boot
> code
> | is working to some degree--'Starting Windows 98' comes up first, which
> it
> | normally wouldn't show, then it comes up with 'Type the name of the
> Command
> | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
> there's no
> | disk, boot or otherwise in the floppy drive. Also, putting in the
> startup
> | disk doesn't get me anywhere--after choosing boot without cd-rom, to
> | simplify it, it just hangs with the floppy drive trying to access
> something.
> | But it seems that this must be coming from IO.SYS, since there
> couldn't be
> | much else doing it, if no COMMAND.COM has been loaded (of course..who
> | knows..).
> | I should mention that this started with an *apparent* CMOS
> failure--a
> | little strange since I just replaced it with a new Li cell just a year
> and a
> | month ago. Nothing very strange seemed to have happened to it, except
> all
> | the drives (floppies, too) had been lost, and this was on the first
> boot of
> | the day.
> | I reset the boot order for it to boot A: first (had been C: then
> A:) and
> | was able then to boot to DOS from the startup disk, but could not see
> the
> | other drives (just A:). I had previously installed an old version
> (4.0) of
> | Partition Magic and used the PM recovery disk to find out that the
> | partitions were all still there--but this version doesn't do anything
> for
> | MBRs, apparently.
> | In short, the EOS byte could easily be missing, AFAIK, and the
> only
> | thing I can see at the moment is to use Debug to see if it's still
> there.
> | Clearly, I would welcome any thoughts on the subject before I try
> | anything. I'm a little leery of slaving the disk to my other machine,
> if I
> | don't know for sure what caused the problem.
> |
> | Thanks for your time,
> | Joe
> | "PCR" > wrote in message
> | ...
> | > Enter "FDISK /MBR"
> | > This will rewrite the code portion of the Master Boot Record,
> | > leaving the Partition Table untouched, except it may muss the
> partition
> | > table, if there is a missing End-Of-Sector marker (55AA), per
> | > http://support.microsoft.com/?kbid=149877
> | > Boot Record Signature AA55 Not Found
> | >
> | > Here are the warnings against it...
> | >
> | > (a) If you have a boot sector virus, you may lose access to all
> | > partitions. Then
> | > http://www.terabyteunlimited.com/utilities.html MBRWork "might" help
> to
> | > recover them.
> | >
> | > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast,
> a
> | > boot manager, then that will need to be reestablished afterwards.
> | > http://www.aefdisk.com/ FDISK & Boot Manager
> | > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
> Overlay
> | > Utility & FDISK
> | >
> | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> | > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> | > Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
> | > solve the 55AA thing.)
> | >
> | > (d) If for some reason the "geometry" setting in BIOS does not match
> the
> | > hard drive, then any write to the drive may be destructive. So, go
> into
> | > BIOS and have it "automatically detect" the proper setting. (If you
> can
> | > DIR the drive in DOS, then you have proven the geometry is right.
> Well,
> | > Blanton says even that may not be true.)
> | >
> | >
> | > --
> | > Thanks or Good Luck,
> | > There may be humor in this post, and,
> | > Naturally, you will not sue,
> | > should things get worse after this,
> | > PCR
> | >
> | > "jt3" > wrote in message
> | > ...
> | > | I think I recall reading someone posting that the /MBR switch
> on
> | > FDISK
> | > | not only rewrites the master boot record, but also wipes out
> partition
> | > table
> | > | data, so that if you use /MBR on a disk with multiple partitions
> on
> | > it, you
> | > | lose the partition data. Is this true?
> | > | I have a problem with a corrupted MBR (I think) and my old
> version
> | > of
> | > | Partition Magic doesn't do the MBR, apparently.
> | > | Thanks for your time, as always,
> | > | Joe
> | > |
> | > |
> | >
> | >
> |
> |
>
>

Brian A.
June 5th 04, 06:42 AM
Since you mention you can get to DOS with a boot disk, boot with the disk in.

At the prompt type:
cd c: and press Enter
dir c:\ /p and press Enter *Note the spaces after dir and between \ /. The /p switch
will move the window contents one page at a time. Pressing ctrl+c anytime will get
you back to the prompt.

Does it show the files in C:?


--
Brian A.

Jack of all trades, Master of none.
One can never truly be a master as there is always more to learn.


"jt3" > wrote in message
...
> Yes that was what I was recalling something about--as I said to Curt,
> all my refs went down with that machine.
> The problem here is that this is wierd--it's clear that the boot code
> is working to some degree--'Starting Windows 98' comes up first, which it
> normally wouldn't show, then it comes up with 'Type the name of the Command
> Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though there's no
> disk, boot or otherwise in the floppy drive. Also, putting in the startup
> disk doesn't get me anywhere--after choosing boot without cd-rom, to
> simplify it, it just hangs with the floppy drive trying to access something.
> But it seems that this must be coming from IO.SYS, since there couldn't be
> much else doing it, if no COMMAND.COM has been loaded (of course..who
> knows..).
> I should mention that this started with an *apparent* CMOS failure--a
> little strange since I just replaced it with a new Li cell just a year and a
> month ago. Nothing very strange seemed to have happened to it, except all
> the drives (floppies, too) had been lost, and this was on the first boot of
> the day.
> I reset the boot order for it to boot A: first (had been C: then A:) and
> was able then to boot to DOS from the startup disk, but could not see the
> other drives (just A:). I had previously installed an old version (4.0) of
> Partition Magic and used the PM recovery disk to find out that the
> partitions were all still there--but this version doesn't do anything for
> MBRs, apparently.
> In short, the EOS byte could easily be missing, AFAIK, and the only
> thing I can see at the moment is to use Debug to see if it's still there.
> Clearly, I would welcome any thoughts on the subject before I try
> anything. I'm a little leery of slaving the disk to my other machine, if I
> don't know for sure what caused the problem.
>
> Thanks for your time,
> Joe
> "PCR" > wrote in message
> ...
> > Enter "FDISK /MBR"
> > This will rewrite the code portion of the Master Boot Record,
> > leaving the Partition Table untouched, except it may muss the partition
> > table, if there is a missing End-Of-Sector marker (55AA), per
> > http://support.microsoft.com/?kbid=149877
> > Boot Record Signature AA55 Not Found
> >
> > Here are the warnings against it...
> >
> > (a) If you have a boot sector virus, you may lose access to all
> > partitions. Then
> > http://www.terabyteunlimited.com/utilities.html MBRWork "might" help to
> > recover them.
> >
> > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast, a
> > boot manager, then that will need to be reestablished afterwards.
> > http://www.aefdisk.com/ FDISK & Boot Manager
> > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP Overlay
> > Utility & FDISK
> >
> > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> > Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
> > solve the 55AA thing.)
> >
> > (d) If for some reason the "geometry" setting in BIOS does not match the
> > hard drive, then any write to the drive may be destructive. So, go into
> > BIOS and have it "automatically detect" the proper setting. (If you can
> > DIR the drive in DOS, then you have proven the geometry is right. Well,
> > Blanton says even that may not be true.)
> >
> >
> > --
> > Thanks or Good Luck,
> > There may be humor in this post, and,
> > Naturally, you will not sue,
> > should things get worse after this,
> > PCR
> >
> > "jt3" > wrote in message
> > ...
> > | I think I recall reading someone posting that the /MBR switch on
> > FDISK
> > | not only rewrites the master boot record, but also wipes out partition
> > table
> > | data, so that if you use /MBR on a disk with multiple partitions on
> > it, you
> > | lose the partition data. Is this true?
> > | I have a problem with a corrupted MBR (I think) and my old version
> > of
> > | Partition Magic doesn't do the MBR, apparently.
> > | Thanks for your time, as always,
> > | Joe
> > |
> > |
> >
> >
>
>

Lee
June 5th 04, 09:38 AM
I am suspect of the 'new' battery, perhaps it was on the shelf for
several years before you bought it 'new'? I'd replace it and
clear the CMOS with the jumper for that if so equipped. Manually
short the battery terminals for at least 20 seconds if not equipped
with a clear CMOS jumper. Then redetect the drive, etc.

Blanton is right, some drive geometries are so close as to find the
proper boot sector for several different drives and then fail to
find the next sectors correctly which would result in missing
command.com messages/prompts.

If two new batteries don't get you going again right away, I'd
suspect the mobo is failing.

"jt3" > wrote in message >...
> Yes that was what I was recalling something about--as I said to Curt,
> all my refs went down with that machine.
> The problem here is that this is wierd--it's clear that the boot code
> is working to some degree--'Starting Windows 98' comes up first, which it
> normally wouldn't show, then it comes up with 'Type the name of the Command
> Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though there's no
> disk, boot or otherwise in the floppy drive. Also, putting in the startup
> disk doesn't get me anywhere--after choosing boot without cd-rom, to
> simplify it, it just hangs with the floppy drive trying to access something.
> But it seems that this must be coming from IO.SYS, since there couldn't be
> much else doing it, if no COMMAND.COM has been loaded (of course..who
> knows..).
> I should mention that this started with an *apparent* CMOS failure--a
> little strange since I just replaced it with a new Li cell just a year and a
> month ago. Nothing very strange seemed to have happened to it, except all
> the drives (floppies, too) had been lost, and this was on the first boot of
> the day.
> I reset the boot order for it to boot A: first (had been C: then A:) and
> was able then to boot to DOS from the startup disk, but could not see the
> other drives (just A:). I had previously installed an old version (4.0) of
> Partition Magic and used the PM recovery disk to find out that the
> partitions were all still there--but this version doesn't do anything for
> MBRs, apparently.
> In short, the EOS byte could easily be missing, AFAIK, and the only
> thing I can see at the moment is to use Debug to see if it's still there.
> Clearly, I would welcome any thoughts on the subject before I try
> anything. I'm a little leery of slaving the disk to my other machine, if I
> don't know for sure what caused the problem.
>
> Thanks for your time,
> Joe
> "PCR" > wrote in message
> ...
> > Enter "FDISK /MBR"
> > This will rewrite the code portion of the Master Boot Record,
> > leaving the Partition Table untouched, except it may muss the partition
> > table, if there is a missing End-Of-Sector marker (55AA), per
> > http://support.microsoft.com/?kbid=149877
> > Boot Record Signature AA55 Not Found
> >
> > Here are the warnings against it...
> >
> > (a) If you have a boot sector virus, you may lose access to all
> > partitions. Then
> > http://www.terabyteunlimited.com/utilities.html MBRWork "might" help to
> > recover them.
> >
> > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast, a
> > boot manager, then that will need to be reestablished afterwards.
> > http://www.aefdisk.com/ FDISK & Boot Manager
> > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP Overlay
> > Utility & FDISK
> >
> > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> > Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
> > solve the 55AA thing.)
> >
> > (d) If for some reason the "geometry" setting in BIOS does not match the
> > hard drive, then any write to the drive may be destructive. So, go into
> > BIOS and have it "automatically detect" the proper setting. (If you can
> > DIR the drive in DOS, then you have proven the geometry is right. Well,
> > Blanton says even that may not be true.)
> >
> >
> > --
> > Thanks or Good Luck,
> > There may be humor in this post, and,
> > Naturally, you will not sue,
> > should things get worse after this,
> > PCR
> >
> > "jt3" > wrote in message
> > ...
> > | I think I recall reading someone posting that the /MBR switch on
> FDISK
> > | not only rewrites the master boot record, but also wipes out partition
> table
> > | data, so that if you use /MBR on a disk with multiple partitions on
> it, you
> > | lose the partition data. Is this true?
> > | I have a problem with a corrupted MBR (I think) and my old version
> of
> > | Partition Magic doesn't do the MBR, apparently.
> > | Thanks for your time, as always,
> > | Joe
> > |
> > |
> >
> >

PCR
June 5th 04, 08:42 PM
Oops. I was too quick to post that quote of...
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
....It wouldn't be a "MS-DOS 6.x Upgrade Setup Disk 1" for you, but JUST
a regular Startup Diskette.

(1) Perhaps yours is bad, if it will not see partitions. Then...
Get a Startup Diskette from
http://www.bootdisk.com/ , if you don't already have one from "Control
Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
Diskette. Boot it, put in a CD and "DIR" the CD. It will say which
letter is the CD. (Otherwise, it is likely one letter higher than
normal.)

(2) Perhaps your partition are not the "type" that are recognizable by
DOS. Then, you must wait for Blanton to arrive. (I still haven't
assimilated it.) Does Partition Magic allow you to change the partition
"type". NATURALLY, all one may safely do is to change it from a hidden
type to it's proper unhidden form. One may NOT simply convert an NTFS to
a FAT32, for example, by changing type!


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"jt3" > wrote in message
...
| That's what I was trying to say: although the PM 'Recovery Disk'
| (mainly a
| boot disk with PM on it) shows the partitions on both disks as present
and
| with no problems, the boot disk DOS can't see them--not even C:\--even
| though if you don't use the boot disk, it's clearly using the C drive
to get
| the message: 'Type the name of the Command Interpreter....' as I
described
| previously.
| I think this may go back to a thread back in April, or March, in
which
| you and cquirke and several other people got involved, but then it was
a
| question of Restarting in DOS Mode. Although I finally thought that I
had
| the
| answer in the question of the receipt of the Windows shutdown
broadcast (and
| the answer may still lie there) I was never able to fix it, and other
things
| (the machine I'm using now) came to the fore. Unfortunately, I only
| archived a few of the posts, and I was using the MS support interface
at the
| time. The server doesn't seem to have retained any posts prior to the
| beginning of May, so I can't find the thread there, and it probably
wouldn't
| do much good, since I doubt I could convince anyone that the two are
| related. Would take even longer to explain why I think so, and it's
| irrelevant, if the thread's not available.
| Obviously, this rambling reflects the state of my understanding,
but it
| comes down to: If PM can see the disks and the partitions, (1) why
can't a
| boot disk see any of them, and (2) how does one access anything on the
disk
| if the boot disk can't see it. Along the way, I might mention that
this is
| an installation without any older DOS on it, so that it would be
deadly to
| overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files would have
to
| come off the W98SE installation disk, and that's a little difficult as
it
| stands. I certainly don't want to reformat the disk.
|
| Thanks,
| Joe
| "PCR" > wrote in message
| ...
| >
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
| > Err Msg: The Following File Is Missing or Corrupt...
| > (187641) - When you start your computer, you may receive the
following
| > error message: The following file is missing or corrupt:
COMMAND.COM.
| > Type the name of the Command Interpreter.
| >
| > It says...
| > ......Quote article...................
| > RESOLUTION
| > To resolve this problem, use the MS-DOS 6.x Upgrade Setup Disk 1 to
| > restart your computer, and then use the SYS command on drive C. To
do
| > so, follow these steps:
| >
| > 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and then
| > restart your computer.
| > 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS Setup.
| > 3. Type sys c:, and then press ENTER.
| > 4. Restart your computer.
| > ......End of quote....................
| >
| > HOWEVER... here are some warnings...
| >
| > This will copy certain system files (IO.sys, Command.com & perhaps
| > MSDOS.sys) from the Startup Diskette to C:\. (It also sets the BPB
drive
| > number to HD0, so that it is now in the bootstrap. It does so, no
matter
| > whether it is HD0. To boot it, one must still move it to be HD0,
| > however.) You may now be able to boot to Windows, if all folders are
| > intact. If not, some further adjustment need be done to "MSDOS.sys",
| > that was copied to C:\. The floppy has just a shell of it. Well,
remove
| > the floppy & boot.
| >
| > Oh gosh! Here are some warnings from Jeff Richards, MS MVP W95/W98,
| > about "SYS C:". DON'T DO IT, he says, if:
| >
| > (a) "Major errors were reported in Scandisk."
| > (b) "A drive is moved from one machine to another", because of the
next
| > two, maybe.
| > (c) "The BIOS setting for a drive is changed (eg, LBA to LARGE)."
| > (d) "A drive that uses overlay software is operated without the
overlay
| > loaded."
| >
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| >
| > "jt3" > wrote in message
| > ...
| > | Yes that was what I was recalling something about--as I said
to
| > Curt,
| > | all my refs went down with that machine.
| > | The problem here is that this is wierd--it's clear that the
boot
| > code
| > | is working to some degree--'Starting Windows 98' comes up first,
which
| > it
| > | normally wouldn't show, then it comes up with 'Type the name of
the
| > Command
| > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
| > there's no
| > | disk, boot or otherwise in the floppy drive. Also, putting in the
| > startup
| > | disk doesn't get me anywhere--after choosing boot without cd-rom,
to
| > | simplify it, it just hangs with the floppy drive trying to access
| > something.
| > | But it seems that this must be coming from IO.SYS, since there
| > couldn't be
| > | much else doing it, if no COMMAND.COM has been loaded (of
course..who
| > | knows..).
| > | I should mention that this started with an *apparent* CMOS
| > failure--a
| > | little strange since I just replaced it with a new Li cell just a
year
| > and a
| > | month ago. Nothing very strange seemed to have happened to it,
except
| > all
| > | the drives (floppies, too) had been lost, and this was on the
first
| > boot of
| > | the day.
| > | I reset the boot order for it to boot A: first (had been C:
then
| > A:) and
| > | was able then to boot to DOS from the startup disk, but could not
see
| > the
| > | other drives (just A:). I had previously installed an old version
| > (4.0) of
| > | Partition Magic and used the PM recovery disk to find out that the
| > | partitions were all still there--but this version doesn't do
anything
| > for
| > | MBRs, apparently.
| > | In short, the EOS byte could easily be missing, AFAIK, and the
| > only
| > | thing I can see at the moment is to use Debug to see if it's still
| > there.
| > | Clearly, I would welcome any thoughts on the subject before I
try
| > | anything. I'm a little leery of slaving the disk to my other
machine,
| > if I
| > | don't know for sure what caused the problem.
| > |
| > | Thanks for your time,
| > | Joe
| > | "PCR" > wrote in message
| > | ...
| > | > Enter "FDISK /MBR"
| > | > This will rewrite the code portion of the Master Boot
Record,
| > | > leaving the Partition Table untouched, except it may muss the
| > partition
| > | > table, if there is a missing End-Of-Sector marker (55AA), per
| > | > http://support.microsoft.com/?kbid=149877
| > | > Boot Record Signature AA55 Not Found
| > | >
| > | > Here are the warnings against it...
| > | >
| > | > (a) If you have a boot sector virus, you may lose access to all
| > | > partitions. Then
| > | > http://www.terabyteunlimited.com/utilities.html MBRWork "might"
help
| > to
| > | > recover them.
| > | >
| > | > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS,
Maxblast,
| > a
| > | > boot manager, then that will need to be reestablished
afterwards.
| > | > http://www.aefdisk.com/ FDISK & Boot Manager
| > | > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
| > Overlay
| > | > Utility & FDISK
| > | >
| > | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
| > | > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
| > | > Latest FDISK, hoping this one doesn't have any bugs. (But it
doesn't
| > | > solve the 55AA thing.)
| > | >
| > | > (d) If for some reason the "geometry" setting in BIOS does not
match
| > the
| > | > hard drive, then any write to the drive may be destructive. So,
go
| > into
| > | > BIOS and have it "automatically detect" the proper setting. (If
you
| > can
| > | > DIR the drive in DOS, then you have proven the geometry is
right.
| > Well,
| > | > Blanton says even that may not be true.)
| > | >
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | >
| > | > "jt3" > wrote in message
| > | > ...
| > | > | I think I recall reading someone posting that the /MBR
switch
| > on
| > | > FDISK
| > | > | not only rewrites the master boot record, but also wipes out
| > partition
| > | > table
| > | > | data, so that if you use /MBR on a disk with multiple
partitions
| > on
| > | > it, you
| > | > | lose the partition data. Is this true?
| > | > | I have a problem with a corrupted MBR (I think) and my old
| > version
| > | > of
| > | > | Partition Magic doesn't do the MBR, apparently.
| > | > | Thanks for your time, as always,
| > | > | Joe
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|
|

jt3
June 6th 04, 04:14 AM
I actually tried three different boot disks I have, all for W98SE, two
made on that machine, and one on this. They all did the same thing, and
although I haven't tried them on this one lately, I suspect that it would
net nothing new. The drives don't have any esoteric type of partitions on
them, just standard DOS primary and extended on the 80 drive, FAT 32, the C
partition about 750 MB and the E partition is the balance of the 8 GB
Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
partitioned into 4 partitions, 1 primary, 3 in the extended.
At one time, I was using a WD Caviar 850 MB as the C drive, and I had
W95SR2.1 on it, with the Quantum providing the same as it provides now.
When this happened once before, about 4 years ago, after much thrashing
about I gave up finally, not knowing about the newsgroup as a resource, and
bought the Seagate to replace the WD, installed W98SE, and when not only
everything seemed to work, but I had less trouble installing and setting up
than in any of the previous installs, I thought I had made a fortunate,
move, however blindly.
Now I should mention that which was discussed ad nauseam in the
'Restart...' thread, namely that the hardware is built on an Eteq mbd, VL
bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller, which has
its own BIOS, enabling it to do several things not particularly germane to
the problem, except for the fact that it allows me to use a drive as large
as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
Thus, for the previous setup in which I used just the WD and Quantum
(same partns), the partitions for the WD were C and E (using FAT16 and
trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for the
disk setup. Now it's been some while ago, but as memory serves, it was a
*very* similar sort of failure, made worse by some other complications that
I would rather not go into here. I wouldn't stake my life on it being the
same, but I have my suspicions.
Anyhow, when I went to use the Seagate, it wouldn't handle it--make a
long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
controller BIOS, I discovered, could handle it, so that caused me to start
using it. This requires, as you may expect, not setting it in the mbd BIOS,
and activating the Promise BIOS which is done through an on-board program,
and everything came up roses.
Now, this time when things went south, the Promise BIOS program still
had all the correct parameters in it, and I should mention that it is all
automated, and so there isn't much possiblity of getting it messed up. The
fact that the PM reading of the partitions came up with all the right data,
suggests that the problem is not with the hard drive, controller, or any
such thing. Since it must still be operating with IO.SYS, it's my bet that
there's something rotten there, but I don't see how to get to it, short of
trying to slave it to another machine.
My reluctance there is based on the fact that I didn't have firewall
protection on that machine, and since I have started perforce using this one
(which has the EZ-Armor on it) I have been astounded by the number of times
it has blocked some sort of invasion (not all of which are ISP pings). This
makes me a little less secure in any assumptions regarding what caused all
this. If I slave it to this machine, I suppose it should be secure enough
until I attempt to access something on it. Question is, does simply reading
the FAT pose a risk? If not, I could do a scan of the drive, once this
machine booted. I'd still have the question of the MBR, but I expect I
could look at it with Debug (if I can find it) and see of the EOS byte is
there. I'd have to deactivate the primary partition, I guess. What happens
if you have a slaved disk which also has a prmary active partition? Surely
DOS 7 wouldn't like that.

Thanks again, I appreciate your efforts and advice,
Joe
"PCR" > wrote in message
...
> Oops. I was too quick to post that quote of...
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> ...It wouldn't be a "MS-DOS 6.x Upgrade Setup Disk 1" for you, but JUST
> a regular Startup Diskette.
>
> (1) Perhaps yours is bad, if it will not see partitions. Then...
> Get a Startup Diskette from
> http://www.bootdisk.com/ , if you don't already have one from "Control
> Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
> Diskette. Boot it, put in a CD and "DIR" the CD. It will say which
> letter is the CD. (Otherwise, it is likely one letter higher than
> normal.)
>
> (2) Perhaps your partition are not the "type" that are recognizable by
> DOS. Then, you must wait for Blanton to arrive. (I still haven't
> assimilated it.) Does Partition Magic allow you to change the partition
> "type". NATURALLY, all one may safely do is to change it from a hidden
> type to it's proper unhidden form. One may NOT simply convert an NTFS to
> a FAT32, for example, by changing type!
>
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> should things get worse after this,
> PCR
>
> "jt3" > wrote in message
> ...
> | That's what I was trying to say: although the PM 'Recovery Disk'
> | (mainly a
> | boot disk with PM on it) shows the partitions on both disks as present
> and
> | with no problems, the boot disk DOS can't see them--not even C:\--even
> | though if you don't use the boot disk, it's clearly using the C drive
> to get
> | the message: 'Type the name of the Command Interpreter....' as I
> described
> | previously.
> | I think this may go back to a thread back in April, or March, in
> which
> | you and cquirke and several other people got involved, but then it was
> a
> | question of Restarting in DOS Mode. Although I finally thought that I
> had
> | the
> | answer in the question of the receipt of the Windows shutdown
> broadcast (and
> | the answer may still lie there) I was never able to fix it, and other
> things
> | (the machine I'm using now) came to the fore. Unfortunately, I only
> | archived a few of the posts, and I was using the MS support interface
> at the
> | time. The server doesn't seem to have retained any posts prior to the
> | beginning of May, so I can't find the thread there, and it probably
> wouldn't
> | do much good, since I doubt I could convince anyone that the two are
> | related. Would take even longer to explain why I think so, and it's
> | irrelevant, if the thread's not available.
> | Obviously, this rambling reflects the state of my understanding,
> but it
> | comes down to: If PM can see the disks and the partitions, (1) why
> can't a
> | boot disk see any of them, and (2) how does one access anything on the
> disk
> | if the boot disk can't see it. Along the way, I might mention that
> this is
> | an installation without any older DOS on it, so that it would be
> deadly to
> | overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files would have
> to
> | come off the W98SE installation disk, and that's a little difficult as
> it
> | stands. I certainly don't want to reformat the disk.
> |
> | Thanks,
> | Joe
> | "PCR" > wrote in message
> | ...
> | >
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> | > Err Msg: The Following File Is Missing or Corrupt...
> | > (187641) - When you start your computer, you may receive the
> following
> | > error message: The following file is missing or corrupt:
> COMMAND.COM.
> | > Type the name of the Command Interpreter.
> | >
> | > It says...
> | > ......Quote article...................
> | > RESOLUTION
> | > To resolve this problem, use the MS-DOS 6.x Upgrade Setup Disk 1 to
> | > restart your computer, and then use the SYS command on drive C. To
> do
> | > so, follow these steps:
> | >
> | > 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and then
> | > restart your computer.
> | > 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS Setup.
> | > 3. Type sys c:, and then press ENTER.
> | > 4. Restart your computer.
> | > ......End of quote....................
> | >
> | > HOWEVER... here are some warnings...
> | >
> | > This will copy certain system files (IO.sys, Command.com & perhaps
> | > MSDOS.sys) from the Startup Diskette to C:\. (It also sets the BPB
> drive
> | > number to HD0, so that it is now in the bootstrap. It does so, no
> matter
> | > whether it is HD0. To boot it, one must still move it to be HD0,
> | > however.) You may now be able to boot to Windows, if all folders are
> | > intact. If not, some further adjustment need be done to "MSDOS.sys",
> | > that was copied to C:\. The floppy has just a shell of it. Well,
> remove
> | > the floppy & boot.
> | >
> | > Oh gosh! Here are some warnings from Jeff Richards, MS MVP W95/W98,
> | > about "SYS C:". DON'T DO IT, he says, if:
> | >
> | > (a) "Major errors were reported in Scandisk."
> | > (b) "A drive is moved from one machine to another", because of the
> next
> | > two, maybe.
> | > (c) "The BIOS setting for a drive is changed (eg, LBA to LARGE)."
> | > (d) "A drive that uses overlay software is operated without the
> overlay
> | > loaded."
> | >
> | >
> | > --
> | > Thanks or Good Luck,
> | > There may be humor in this post, and,
> | > Naturally, you will not sue,
> | > should things get worse after this,
> | > PCR
> | >
> | > "jt3" > wrote in message
> | > ...
> | > | Yes that was what I was recalling something about--as I said
> to
> | > Curt,
> | > | all my refs went down with that machine.
> | > | The problem here is that this is wierd--it's clear that the
> boot
> | > code
> | > | is working to some degree--'Starting Windows 98' comes up first,
> which
> | > it
> | > | normally wouldn't show, then it comes up with 'Type the name of
> the
> | > Command
> | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
> | > there's no
> | > | disk, boot or otherwise in the floppy drive. Also, putting in the
> | > startup
> | > | disk doesn't get me anywhere--after choosing boot without cd-rom,
> to
> | > | simplify it, it just hangs with the floppy drive trying to access
> | > something.
> | > | But it seems that this must be coming from IO.SYS, since there
> | > couldn't be
> | > | much else doing it, if no COMMAND.COM has been loaded (of
> course..who
> | > | knows..).
> | > | I should mention that this started with an *apparent* CMOS
> | > failure--a
> | > | little strange since I just replaced it with a new Li cell just a
> year
> | > and a
> | > | month ago. Nothing very strange seemed to have happened to it,
> except
> | > all
> | > | the drives (floppies, too) had been lost, and this was on the
> first
> | > boot of
> | > | the day.
> | > | I reset the boot order for it to boot A: first (had been C:
> then
> | > A:) and
> | > | was able then to boot to DOS from the startup disk, but could not
> see
> | > the
> | > | other drives (just A:). I had previously installed an old version
> | > (4.0) of
> | > | Partition Magic and used the PM recovery disk to find out that the
> | > | partitions were all still there--but this version doesn't do
> anything
> | > for
> | > | MBRs, apparently.
> | > | In short, the EOS byte could easily be missing, AFAIK, and the
> | > only
> | > | thing I can see at the moment is to use Debug to see if it's still
> | > there.
> | > | Clearly, I would welcome any thoughts on the subject before I
> try
> | > | anything. I'm a little leery of slaving the disk to my other
> machine,
> | > if I
> | > | don't know for sure what caused the problem.
> | > |
> | > | Thanks for your time,
> | > | Joe
> | > | "PCR" > wrote in message
> | > | ...
> | > | > Enter "FDISK /MBR"
> | > | > This will rewrite the code portion of the Master Boot
> Record,
> | > | > leaving the Partition Table untouched, except it may muss the
> | > partition
> | > | > table, if there is a missing End-Of-Sector marker (55AA), per
> | > | > http://support.microsoft.com/?kbid=149877
> | > | > Boot Record Signature AA55 Not Found
> | > | >
> | > | > Here are the warnings against it...
> | > | >
> | > | > (a) If you have a boot sector virus, you may lose access to all
> | > | > partitions. Then
> | > | > http://www.terabyteunlimited.com/utilities.html MBRWork "might"
> help
> | > to
> | > | > recover them.
> | > | >
> | > | > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS,
> Maxblast,
> | > a
> | > | > boot manager, then that will need to be reestablished
> afterwards.
> | > | > http://www.aefdisk.com/ FDISK & Boot Manager
> | > | > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
> | > Overlay
> | > | > Utility & FDISK
> | > | >
> | > | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> | > | > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> | > | > Latest FDISK, hoping this one doesn't have any bugs. (But it
> doesn't
> | > | > solve the 55AA thing.)
> | > | >
> | > | > (d) If for some reason the "geometry" setting in BIOS does not
> match
> | > the
> | > | > hard drive, then any write to the drive may be destructive. So,
> go
> | > into
> | > | > BIOS and have it "automatically detect" the proper setting. (If
> you
> | > can
> | > | > DIR the drive in DOS, then you have proven the geometry is
> right.
> | > Well,
> | > | > Blanton says even that may not be true.)
> | > | >
> | > | >
> | > | > --
> | > | > Thanks or Good Luck,
> | > | > There may be humor in this post, and,
> | > | > Naturally, you will not sue,
> | > | > should things get worse after this,
> | > | > PCR
> | > | >
> | > | > "jt3" > wrote in message
> | > | > ...
> | > | > | I think I recall reading someone posting that the /MBR
> switch
> | > on
> | > | > FDISK
> | > | > | not only rewrites the master boot record, but also wipes out
> | > partition
> | > | > table
> | > | > | data, so that if you use /MBR on a disk with multiple
> partitions
> | > on
> | > | > it, you
> | > | > | lose the partition data. Is this true?
> | > | > | I have a problem with a corrupted MBR (I think) and my old
> | > version
> | > | > of
> | > | > | Partition Magic doesn't do the MBR, apparently.
> | > | > | Thanks for your time, as always,
> | > | > | Joe
> | > | > |
> | > | > |
> | > | >
> | > | >
> | > |
> | > |
> | >
> | >
> |
> |
> |
>
>

jt3
June 6th 04, 04:20 AM
The trouble was, that It *wouldn't* recognize the presence of the C:
drive, or any of the other partitions, on either of the two disk drives.
Just insisted it was DOS on an A: stick all by itself. That was, of course
the first thing I hoped for, and in fact, (see my reply to PCR's last post)
as I now recall, the previous failure (4 years ago with W95SR2.1) did see
the other disks, but there was another complication in that case. Probably
the two are not that parallel, just a lot of similarity.
So my problem is now as stated in the other post.
Thanks,
Joe
"Brian A." <GoneFishn@aFarAwayLake> wrote in message
...
> Since you mention you can get to DOS with a boot disk, boot with the disk
in.
>
> At the prompt type:
> cd c: and press Enter
> dir c:\ /p and press Enter *Note the spaces after dir and between \ /.
The /p switch
> will move the window contents one page at a time. Pressing ctrl+c anytime
will get
> you back to the prompt.
>
> Does it show the files in C:?
>
>
> --
> Brian A.
>
> Jack of all trades, Master of none.
> One can never truly be a master as there is always more to learn.
>
>
> "jt3" > wrote in message
> ...
> > Yes that was what I was recalling something about--as I said to
Curt,
> > all my refs went down with that machine.
> > The problem here is that this is wierd--it's clear that the boot
code
> > is working to some degree--'Starting Windows 98' comes up first, which
it
> > normally wouldn't show, then it comes up with 'Type the name of the
Command
> > Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though there's
no
> > disk, boot or otherwise in the floppy drive. Also, putting in the
startup
> > disk doesn't get me anywhere--after choosing boot without cd-rom, to
> > simplify it, it just hangs with the floppy drive trying to access
something.
> > But it seems that this must be coming from IO.SYS, since there couldn't
be
> > much else doing it, if no COMMAND.COM has been loaded (of course..who
> > knows..).
> > I should mention that this started with an *apparent* CMOS
failure--a
> > little strange since I just replaced it with a new Li cell just a year
and a
> > month ago. Nothing very strange seemed to have happened to it, except
all
> > the drives (floppies, too) had been lost, and this was on the first boot
of
> > the day.
> > I reset the boot order for it to boot A: first (had been C: then A:)
and
> > was able then to boot to DOS from the startup disk, but could not see
the
> > other drives (just A:). I had previously installed an old version (4.0)
of
> > Partition Magic and used the PM recovery disk to find out that the
> > partitions were all still there--but this version doesn't do anything
for
> > MBRs, apparently.
> > In short, the EOS byte could easily be missing, AFAIK, and the only
> > thing I can see at the moment is to use Debug to see if it's still
there.
> > Clearly, I would welcome any thoughts on the subject before I try
> > anything. I'm a little leery of slaving the disk to my other machine,
if I
> > don't know for sure what caused the problem.
> >
> > Thanks for your time,
> > Joe
> > "PCR" > wrote in message
> > ...
> > > Enter "FDISK /MBR"
> > > This will rewrite the code portion of the Master Boot Record,
> > > leaving the Partition Table untouched, except it may muss the
partition
> > > table, if there is a missing End-Of-Sector marker (55AA), per
> > > http://support.microsoft.com/?kbid=149877
> > > Boot Record Signature AA55 Not Found
> > >
> > > Here are the warnings against it...
> > >
> > > (a) If you have a boot sector virus, you may lose access to all
> > > partitions. Then
> > > http://www.terabyteunlimited.com/utilities.html MBRWork "might" help
to
> > > recover them.
> > >
> > > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast, a
> > > boot manager, then that will need to be reestablished afterwards.
> > > http://www.aefdisk.com/ FDISK & Boot Manager
> > > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP Overlay
> > > Utility & FDISK
> > >
> > > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> > > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> > > Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
> > > solve the 55AA thing.)
> > >
> > > (d) If for some reason the "geometry" setting in BIOS does not match
the
> > > hard drive, then any write to the drive may be destructive. So, go
into
> > > BIOS and have it "automatically detect" the proper setting. (If you
can
> > > DIR the drive in DOS, then you have proven the geometry is right.
Well,
> > > Blanton says even that may not be true.)
> > >
> > >
> > > --
> > > Thanks or Good Luck,
> > > There may be humor in this post, and,
> > > Naturally, you will not sue,
> > > should things get worse after this,
> > > PCR
> > >
> > > "jt3" > wrote in message
> > > ...
> > > | I think I recall reading someone posting that the /MBR switch on
> > > FDISK
> > > | not only rewrites the master boot record, but also wipes out
partition
> > > table
> > > | data, so that if you use /MBR on a disk with multiple partitions on
> > > it, you
> > > | lose the partition data. Is this true?
> > > | I have a problem with a corrupted MBR (I think) and my old
version
> > > of
> > > | Partition Magic doesn't do the MBR, apparently.
> > > | Thanks for your time, as always,
> > > | Joe
> > > |
> > > |
> > >
> > >
> >
> >
>

jt3
June 6th 04, 04:33 AM
You may well be right about the quality of the Li cell, it wouldn't be
the first time I've ended up with a bad cell. A little less likely with a
Li cell, though, and I got it at a high volume place to avoid long shelf
time. Nevertheless, replacement seems indicated.
I don't know that it would affect what's in the disk parameter table,
since that would be written after the Promise adapter (see my reply post to
PCR, previously) had been scanned during POST and its subsequent
initialization. Perhaps, but only if it had written some non-zero type to
the disk type table.

Thanks for your time,
Joe
"Lee" > wrote in message
om...
> I am suspect of the 'new' battery, perhaps it was on the shelf for
> several years before you bought it 'new'? I'd replace it and
> clear the CMOS with the jumper for that if so equipped. Manually
> short the battery terminals for at least 20 seconds if not equipped
> with a clear CMOS jumper. Then redetect the drive, etc.
>
> Blanton is right, some drive geometries are so close as to find the
> proper boot sector for several different drives and then fail to
> find the next sectors correctly which would result in missing
> command.com messages/prompts.
>
> If two new batteries don't get you going again right away, I'd
> suspect the mobo is failing.
>
> "jt3" > wrote in message
>...
> > Yes that was what I was recalling something about--as I said to Curt,
> > all my refs went down with that machine.
> > The problem here is that this is wierd--it's clear that the boot
code
> > is working to some degree--'Starting Windows 98' comes up first, which
it
> > normally wouldn't show, then it comes up with 'Type the name of the
Command
> > Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though there's
no
> > disk, boot or otherwise in the floppy drive. Also, putting in the
startup
> > disk doesn't get me anywhere--after choosing boot without cd-rom, to
> > simplify it, it just hangs with the floppy drive trying to access
something.
> > But it seems that this must be coming from IO.SYS, since there couldn't
be
> > much else doing it, if no COMMAND.COM has been loaded (of course..who
> > knows..).
> > I should mention that this started with an *apparent* CMOS
failure--a
> > little strange since I just replaced it with a new Li cell just a year
and a
> > month ago. Nothing very strange seemed to have happened to it, except
all
> > the drives (floppies, too) had been lost, and this was on the first boot
of
> > the day.
> > I reset the boot order for it to boot A: first (had been C: then A:)
and
> > was able then to boot to DOS from the startup disk, but could not see
the
> > other drives (just A:). I had previously installed an old version (4.0)
of
> > Partition Magic and used the PM recovery disk to find out that the
> > partitions were all still there--but this version doesn't do anything
for
> > MBRs, apparently.
> > In short, the EOS byte could easily be missing, AFAIK, and the only
> > thing I can see at the moment is to use Debug to see if it's still
there.
> > Clearly, I would welcome any thoughts on the subject before I try
> > anything. I'm a little leery of slaving the disk to my other machine,
if I
> > don't know for sure what caused the problem.
> >
> > Thanks for your time,
> > Joe
> > "PCR" > wrote in message
> > ...
> > > Enter "FDISK /MBR"
> > > This will rewrite the code portion of the Master Boot Record,
> > > leaving the Partition Table untouched, except it may muss the
partition
> > > table, if there is a missing End-Of-Sector marker (55AA), per
> > > http://support.microsoft.com/?kbid=149877
> > > Boot Record Signature AA55 Not Found
> > >
> > > Here are the warnings against it...
> > >
> > > (a) If you have a boot sector virus, you may lose access to all
> > > partitions. Then
> > > http://www.terabyteunlimited.com/utilities.html MBRWork "might" help
to
> > > recover them.
> > >
> > > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS, Maxblast, a
> > > boot manager, then that will need to be reestablished afterwards.
> > > http://www.aefdisk.com/ FDISK & Boot Manager
> > > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP Overlay
> > > Utility & FDISK
> > >
> > > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> > > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> > > Latest FDISK, hoping this one doesn't have any bugs. (But it doesn't
> > > solve the 55AA thing.)
> > >
> > > (d) If for some reason the "geometry" setting in BIOS does not match
the
> > > hard drive, then any write to the drive may be destructive. So, go
into
> > > BIOS and have it "automatically detect" the proper setting. (If you
can
> > > DIR the drive in DOS, then you have proven the geometry is right.
Well,
> > > Blanton says even that may not be true.)
> > >
> > >
> > > --
> > > Thanks or Good Luck,
> > > There may be humor in this post, and,
> > > Naturally, you will not sue,
> > > should things get worse after this,
> > > PCR
> > >
> > > "jt3" > wrote in message
> > > ...
> > > | I think I recall reading someone posting that the /MBR switch on
> > FDISK
> > > | not only rewrites the master boot record, but also wipes out
partition
> > table
> > > | data, so that if you use /MBR on a disk with multiple partitions on
> > it, you
> > > | lose the partition data. Is this true?
> > > | I have a problem with a corrupted MBR (I think) and my old
version
> > of
> > > | Partition Magic doesn't do the MBR, apparently.
> > > | Thanks for your time, as always,
> > > | Joe
> > > |
> > > |
> > >
> > >

PCR
June 6th 04, 08:12 PM
(1) I guess the Startup Diskettes are OK, except for one possibility. If
EZ-BIOS or such has been installed to an HDD, then it must (a) also be
installed to the floppy, or (b) present an option during boot to boot
the floppy. Otherwise, a floppy will fail to read the HDD. This is
because EZ-BIOS (or the Maxtor equivalent) has altered the HDD
"geometry".

(2) I don't know how you could check it (not able to boot to DOS), but
each HDD must have one & only one partition marked as Active. (That is
unless your Maxtor BIOS gets around it somehow.) Otherwise, you cannot
boot.

(3) I don't know what could happen, if you are mixing WD's EZ-BIOS with
Maxtor's equivalent.

(4)
| this. If I slave it to this machine, I suppose it should be secure
enough
| until I attempt to access something on it. Question is, does simply
reading
| the FAT pose a risk? If not, I could do a scan of the drive, once
this

I'm not sure of the risks. I know when EZ-BIOS or such is installed to
an HDD, it gets into the MBR. Therefore, moving the HDD to another
machine brings it along. HOWEVER, it that all there is to it? I think
not in the case of Maxtor anyway, which got into the BIOS. Moving an HDD
in that case leaves the BIOS behind. So, how can one get the "geometry"
right?


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"jt3" > wrote in message
...
| I actually tried three different boot disks I have, all for W98SE,
two
| made on that machine, and one on this. They all did the same thing,
and
| although I haven't tried them on this one lately, I suspect that it
would
| net nothing new. The drives don't have any esoteric type of
partitions on
| them, just standard DOS primary and extended on the 80 drive, FAT 32,
the C
| partition about 750 MB and the E partition is the balance of the 8 GB
| Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
| partitioned into 4 partitions, 1 primary, 3 in the extended.
| At one time, I was using a WD Caviar 850 MB as the C drive, and I
had
| W95SR2.1 on it, with the Quantum providing the same as it provides
now.
| When this happened once before, about 4 years ago, after much
thrashing
| about I gave up finally, not knowing about the newsgroup as a
resource, and
| bought the Seagate to replace the WD, installed W98SE, and when not
only
| everything seemed to work, but I had less trouble installing and
setting up
| than in any of the previous installs, I thought I had made a
fortunate,
| move, however blindly.
| Now I should mention that which was discussed ad nauseam in the
| 'Restart...' thread, namely that the hardware is built on an Eteq mbd,
VL
| bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller,
which has
| its own BIOS, enabling it to do several things not particularly
germane to
| the problem, except for the fact that it allows me to use a drive as
large
| as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
| Thus, for the previous setup in which I used just the WD and
Quantum
| (same partns), the partitions for the WD were C and E (using FAT16 and
| trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for
the
| disk setup. Now it's been some while ago, but as memory serves, it
was a
| *very* similar sort of failure, made worse by some other complications
that
| I would rather not go into here. I wouldn't stake my life on it being
the
| same, but I have my suspicions.
| Anyhow, when I went to use the Seagate, it wouldn't handle
it--make a
| long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
| controller BIOS, I discovered, could handle it, so that caused me to
start
| using it. This requires, as you may expect, not setting it in the mbd
BIOS,
| and activating the Promise BIOS which is done through an on-board
program,
| and everything came up roses.
| Now, this time when things went south, the Promise BIOS program
still
| had all the correct parameters in it, and I should mention that it is
all
| automated, and so there isn't much possiblity of getting it messed up.
The
| fact that the PM reading of the partitions came up with all the right
data,
| suggests that the problem is not with the hard drive, controller, or
any
| such thing. Since it must still be operating with IO.SYS, it's my bet
that
| there's something rotten there, but I don't see how to get to it,
short of
| trying to slave it to another machine.
| My reluctance there is based on the fact that I didn't have
firewall
| protection on that machine, and since I have started perforce using
this one
| (which has the EZ-Armor on it) I have been astounded by the number of
times
| it has blocked some sort of invasion (not all of which are ISP pings).
This
| makes me a little less secure in any assumptions regarding what caused
all
| this. If I slave it to this machine, I suppose it should be secure
enough
| until I attempt to access something on it. Question is, does simply
reading
| the FAT pose a risk? If not, I could do a scan of the drive, once
this
| machine booted. I'd still have the question of the MBR, but I expect
I
| could look at it with Debug (if I can find it) and see of the EOS byte
is
| there. I'd have to deactivate the primary partition, I guess. What
happens
| if you have a slaved disk which also has a prmary active partition?
Surely
| DOS 7 wouldn't like that.
|
| Thanks again, I appreciate your efforts and advice,
| Joe
| "PCR" > wrote in message
| ...
| > Oops. I was too quick to post that quote of...
| >
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
| > ...It wouldn't be a "MS-DOS 6.x Upgrade Setup Disk 1" for you, but
JUST
| > a regular Startup Diskette.
| >
| > (1) Perhaps yours is bad, if it will not see partitions. Then...
| > Get a Startup Diskette from
| > http://www.bootdisk.com/ , if you don't already have one from
"Control
| > Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
| > Diskette. Boot it, put in a CD and "DIR" the CD. It will say which
| > letter is the CD. (Otherwise, it is likely one letter higher than
| > normal.)
| >
| > (2) Perhaps your partition are not the "type" that are recognizable
by
| > DOS. Then, you must wait for Blanton to arrive. (I still haven't
| > assimilated it.) Does Partition Magic allow you to change the
partition
| > "type". NATURALLY, all one may safely do is to change it from a
hidden
| > type to it's proper unhidden form. One may NOT simply convert an
NTFS to
| > a FAT32, for example, by changing type!
| >
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| >
| > "jt3" > wrote in message
| > ...
| > | That's what I was trying to say: although the PM 'Recovery
Disk'
| > | (mainly a
| > | boot disk with PM on it) shows the partitions on both disks as
present
| > and
| > | with no problems, the boot disk DOS can't see them--not even
C:\--even
| > | though if you don't use the boot disk, it's clearly using the C
drive
| > to get
| > | the message: 'Type the name of the Command Interpreter....' as I
| > described
| > | previously.
| > | I think this may go back to a thread back in April, or March,
in
| > which
| > | you and cquirke and several other people got involved, but then it
was
| > a
| > | question of Restarting in DOS Mode. Although I finally thought
that I
| > had
| > | the
| > | answer in the question of the receipt of the Windows shutdown
| > broadcast (and
| > | the answer may still lie there) I was never able to fix it, and
other
| > things
| > | (the machine I'm using now) came to the fore. Unfortunately, I
only
| > | archived a few of the posts, and I was using the MS support
interface
| > at the
| > | time. The server doesn't seem to have retained any posts prior to
the
| > | beginning of May, so I can't find the thread there, and it
probably
| > wouldn't
| > | do much good, since I doubt I could convince anyone that the two
are
| > | related. Would take even longer to explain why I think so, and
it's
| > | irrelevant, if the thread's not available.
| > | Obviously, this rambling reflects the state of my
understanding,
| > but it
| > | comes down to: If PM can see the disks and the partitions, (1)
why
| > can't a
| > | boot disk see any of them, and (2) how does one access anything on
the
| > disk
| > | if the boot disk can't see it. Along the way, I might mention
that
| > this is
| > | an installation without any older DOS on it, so that it would be
| > deadly to
| > | overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files would
have
| > to
| > | come off the W98SE installation disk, and that's a little
difficult as
| > it
| > | stands. I certainly don't want to reformat the disk.
| > |
| > | Thanks,
| > | Joe
| > | "PCR" > wrote in message
| > | ...
| > | >
| >
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
| > | > Err Msg: The Following File Is Missing or Corrupt...
| > | > (187641) - When you start your computer, you may receive the
| > following
| > | > error message: The following file is missing or corrupt:
| > COMMAND.COM.
| > | > Type the name of the Command Interpreter.
| > | >
| > | > It says...
| > | > ......Quote article...................
| > | > RESOLUTION
| > | > To resolve this problem, use the MS-DOS 6.x Upgrade Setup Disk 1
to
| > | > restart your computer, and then use the SYS command on drive C.
To
| > do
| > | > so, follow these steps:
| > | >
| > | > 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and
then
| > | > restart your computer.
| > | > 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS
Setup.
| > | > 3. Type sys c:, and then press ENTER.
| > | > 4. Restart your computer.
| > | > ......End of quote....................
| > | >
| > | > HOWEVER... here are some warnings...
| > | >
| > | > This will copy certain system files (IO.sys, Command.com &
perhaps
| > | > MSDOS.sys) from the Startup Diskette to C:\. (It also sets the
BPB
| > drive
| > | > number to HD0, so that it is now in the bootstrap. It does so,
no
| > matter
| > | > whether it is HD0. To boot it, one must still move it to be HD0,
| > | > however.) You may now be able to boot to Windows, if all folders
are
| > | > intact. If not, some further adjustment need be done to
"MSDOS.sys",
| > | > that was copied to C:\. The floppy has just a shell of it. Well,
| > remove
| > | > the floppy & boot.
| > | >
| > | > Oh gosh! Here are some warnings from Jeff Richards, MS MVP
W95/W98,
| > | > about "SYS C:". DON'T DO IT, he says, if:
| > | >
| > | > (a) "Major errors were reported in Scandisk."
| > | > (b) "A drive is moved from one machine to another", because of
the
| > next
| > | > two, maybe.
| > | > (c) "The BIOS setting for a drive is changed (eg, LBA to
LARGE)."
| > | > (d) "A drive that uses overlay software is operated without the
| > overlay
| > | > loaded."
| > | >
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | >
| > | > "jt3" > wrote in message
| > | > ...
| > | > | Yes that was what I was recalling something about--as I
said
| > to
| > | > Curt,
| > | > | all my refs went down with that machine.
| > | > | The problem here is that this is wierd--it's clear that
the
| > boot
| > | > code
| > | > | is working to some degree--'Starting Windows 98' comes up
first,
| > which
| > | > it
| > | > | normally wouldn't show, then it comes up with 'Type the name
of
| > the
| > | > Command
| > | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even
though
| > | > there's no
| > | > | disk, boot or otherwise in the floppy drive. Also, putting in
the
| > | > startup
| > | > | disk doesn't get me anywhere--after choosing boot without
cd-rom,
| > to
| > | > | simplify it, it just hangs with the floppy drive trying to
access
| > | > something.
| > | > | But it seems that this must be coming from IO.SYS, since there
| > | > couldn't be
| > | > | much else doing it, if no COMMAND.COM has been loaded (of
| > course..who
| > | > | knows..).
| > | > | I should mention that this started with an *apparent* CMOS
| > | > failure--a
| > | > | little strange since I just replaced it with a new Li cell
just a
| > year
| > | > and a
| > | > | month ago. Nothing very strange seemed to have happened to
it,
| > except
| > | > all
| > | > | the drives (floppies, too) had been lost, and this was on the
| > first
| > | > boot of
| > | > | the day.
| > | > | I reset the boot order for it to boot A: first (had been
C:
| > then
| > | > A:) and
| > | > | was able then to boot to DOS from the startup disk, but could
not
| > see
| > | > the
| > | > | other drives (just A:). I had previously installed an old
version
| > | > (4.0) of
| > | > | Partition Magic and used the PM recovery disk to find out that
the
| > | > | partitions were all still there--but this version doesn't do
| > anything
| > | > for
| > | > | MBRs, apparently.
| > | > | In short, the EOS byte could easily be missing, AFAIK, and
the
| > | > only
| > | > | thing I can see at the moment is to use Debug to see if it's
still
| > | > there.
| > | > | Clearly, I would welcome any thoughts on the subject
before I
| > try
| > | > | anything. I'm a little leery of slaving the disk to my other
| > machine,
| > | > if I
| > | > | don't know for sure what caused the problem.
| > | > |
| > | > | Thanks for your time,
| > | > | Joe
| > | > | "PCR" > wrote in message
| > | > | ...
| > | > | > Enter "FDISK /MBR"
| > | > | > This will rewrite the code portion of the Master Boot
| > Record,
| > | > | > leaving the Partition Table untouched, except it may muss
the
| > | > partition
| > | > | > table, if there is a missing End-Of-Sector marker (55AA),
per
| > | > | > http://support.microsoft.com/?kbid=149877
| > | > | > Boot Record Signature AA55 Not Found
| > | > | >
| > | > | > Here are the warnings against it...
| > | > | >
| > | > | > (a) If you have a boot sector virus, you may lose access to
all
| > | > | > partitions. Then
| > | > | > http://www.terabyteunlimited.com/utilities.html MBRWork
"might"
| > help
| > | > to
| > | > | > recover them.
| > | > | >
| > | > | > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS,
| > Maxblast,
| > | > a
| > | > | > boot manager, then that will need to be reestablished
| > afterwards.
| > | > | > http://www.aefdisk.com/ FDISK & Boot Manager
| > | > | >
http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
| > | > Overlay
| > | > | > Utility & FDISK
| > | > | >
| > | > | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
| > | > | >
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
| > | > | > Latest FDISK, hoping this one doesn't have any bugs. (But it
| > doesn't
| > | > | > solve the 55AA thing.)
| > | > | >
| > | > | > (d) If for some reason the "geometry" setting in BIOS does
not
| > match
| > | > the
| > | > | > hard drive, then any write to the drive may be destructive.
So,
| > go
| > | > into
| > | > | > BIOS and have it "automatically detect" the proper setting.
(If
| > you
| > | > can
| > | > | > DIR the drive in DOS, then you have proven the geometry is
| > right.
| > | > Well,
| > | > | > Blanton says even that may not be true.)
| > | > | >
| > | > | >
| > | > | > --
| > | > | > Thanks or Good Luck,
| > | > | > There may be humor in this post, and,
| > | > | > Naturally, you will not sue,
| > | > | > should things get worse after this,
| > | > | > PCR
| > | > | >
| > | > | > "jt3" > wrote in message
| > | > | > ...
| > | > | > | I think I recall reading someone posting that the /MBR
| > switch
| > | > on
| > | > | > FDISK
| > | > | > | not only rewrites the master boot record, but also wipes
out
| > | > partition
| > | > | > table
| > | > | > | data, so that if you use /MBR on a disk with multiple
| > partitions
| > | > on
| > | > | > it, you
| > | > | > | lose the partition data. Is this true?
| > | > | > | I have a problem with a corrupted MBR (I think) and my
old
| > | > version
| > | > | > of
| > | > | > | Partition Magic doesn't do the MBR, apparently.
| > | > | > | Thanks for your time, as always,
| > | > | > | Joe
| > | > | > |
| > | > | > |
| > | > | >
| > | > | >
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| > |
| >
| >
|
|
|

jt3
June 7th 04, 02:58 AM
*Never* installed *any* disk overlay software on this or any other
machine. These hds were blank when I installed them. This is a machine I
built from scratch some years ago (1995, to be more precise) and I know all
the stuff that ever went into it.
Not sure if you took the output string as proof of the existence of a
drive overlay. PM refers to Partition Magic, version 4.0, which I used to
check and see if the drives and partitions were still as they should be.
All I did with it is 'look'--I made no changes
with PM.
As it happens the Quantum Bigfoot predates their acquisition by Maxtor
(so it may have been more than 4 years ago that the earlier problem
occurred--when you get to my age time seems to pass a good deal faster than
it once did). There was some disk overlay program offered by Quantum at the
time, I think it was OnTrack, which I read is the basis for MaxBlast, and I
*do* have a Maxtor on the FIC K6 machine I'm using at the moment, but I have
always avoided overlay programs because they are so problematic when using
any kind of disk software. So it is fairly certain that there is no Maxtor
or WD,
or any other hd mfgr proprietary disk overlay program on either disk; if one
got there, it had to have been put there by the Promise BIOS, and don't
think that likely.
I must admit, however, that the Promise adapter is supposed to support
*four* IDE hds on the primary channel, in addition to providing the
secondary channel for use with CD-R/OM/RWs (two max).
As it happens I was not using it that way, though I once tried it and
found that it worked pretty much as they said. I have no idea how they
achieve this, and they gave no clue in the documentation, but since ATA is
fairly close to SCSI, they must all be daisy chained together in a similar
manner; all SCSI cards I know of (including the one on this machine) use
onboard BIOSes to do this, and I never heard of one surreptitiously
installing a disk overlay.
The documentation instructs the user to use Promise's version of FDISK,
which sounds suspicious, but in fact when I tried using the extra disk
drive, I *did_not* use their FDISK version to format the disk (for several
reasons), and in fact just hooked up three previously formatted and occupied
disks; for the short space of time that I tried using it that way (about
three months) it gave no particular trouble (other than that detailed
below), but I cannot say that the previously mentioned crash of about 4
years ago was totally independent (since that wipe-out happened only a few
months later)-- but I don't think so. The problems then seemed more to
result from the use of the WD drive (I had another just like it) and
disappeared when I took the WDs off. Since they were so small (856M), I
stayed with the Quantum. This was because I found Promise docs online which
said to beware of WD drives, as they often wouldn't work right with it,
especially when used with another brand of disk. I've not experienced any
similar problems with the Seagate and the Quantum together, however.
Please note:
(1) The Seagate (8 GB) FAT32 is partitioned to C and E, the Quantum
(2GB) is FAT16 partitioned to D, F, G, and H. Neither has any disk overlay
applied--I used FDISK straight from the box to set them up. The fact that
the string output when trying to change to C: is that given in KB 245162
doesn't tell me that it necessarily has a disk overlay (except as mentioned
in the caveat above, and I have used a boot disk before without problem,
though it was, it's true, on W95SR2.1) and the rest of the symptomatology
suggests that there's more than a disk overlay in the works.
(2) The message displayed on the screen when one attempts to boot the
machine (without boot disk) is letter perfect out of IO.SYS, in the literals
near the 'Starting Windows 98' string (which normally never appears, but
*does* in this case). This of course only means that IO.SYS is executing in
some way, if not the correct one.
(3) (2) implies that it got out of the MBR, though not necessarily in
the correct fashion, but it *doesn't* imply that the EOS byte is there.
Probably, but not with any certainty. Since IO.SYS no longer has to reside
first on the disk, and since there is a partition table between we can
assume that it got there by some kind of jump, I think.
Thus if I acted on a pure guess, it seems fairly likely that the MBR is
probably still OK, and it's IO.SYS that's most likely in need of aid.
Trouble is, I don't have a lot of confidence in this--way too much I don't
know anything about here..
(4) KB149877 says that it applies to Win2K, NT(various flavors), WfW,
and W95, but *doesn't* mention W98 or SE or ME. The fact that it skips
right over W98 and ME causes me a little concern when strictly interpreting
some of it's suggestions, viz. using FDISK/mbr and partition table info
safety.

All in all, I'm still nowhere, and hope you or someone else can point a
way that looks a little less hazardous.

Thanks for your time and effort,
Joe
"PCR" > wrote in message
...
> (1) I guess the Startup Diskettes are OK, except for one possibility. If
> EZ-BIOS or such has been installed to an HDD, then it must (a) also be
> installed to the floppy, or (b) present an option during boot to boot
> the floppy. Otherwise, a floppy will fail to read the HDD. This is
> because EZ-BIOS (or the Maxtor equivalent) has altered the HDD
> "geometry".
>
> (2) I don't know how you could check it (not able to boot to DOS), but
> each HDD must have one & only one partition marked as Active. (That is
> unless your Maxtor BIOS gets around it somehow.) Otherwise, you cannot
> boot.
>
> (3) I don't know what could happen, if you are mixing WD's EZ-BIOS with
> Maxtor's equivalent.
>
> (4)
> | this. If I slave it to this machine, I suppose it should be secure
> enough
> | until I attempt to access something on it. Question is, does simply
> reading
> | the FAT pose a risk? If not, I could do a scan of the drive, once
> this
>
> I'm not sure of the risks. I know when EZ-BIOS or such is installed to
> an HDD, it gets into the MBR. Therefore, moving the HDD to another
> machine brings it along. HOWEVER, it that all there is to it? I think
> not in the case of Maxtor anyway, which got into the BIOS. Moving an HDD
> in that case leaves the BIOS behind. So, how can one get the "geometry"
> right?
>
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> should things get worse after this,
> PCR
>
> "jt3" > wrote in message
> ...
> | I actually tried three different boot disks I have, all for W98SE,
> two
> | made on that machine, and one on this. They all did the same thing,
> and
> | although I haven't tried them on this one lately, I suspect that it
> would
> | net nothing new. The drives don't have any esoteric type of
> partitions on
> | them, just standard DOS primary and extended on the 80 drive, FAT 32,
> the C
> | partition about 750 MB and the E partition is the balance of the 8 GB
> | Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> | partitioned into 4 partitions, 1 primary, 3 in the extended.
> | At one time, I was using a WD Caviar 850 MB as the C drive, and I
> had
> | W95SR2.1 on it, with the Quantum providing the same as it provides
> now.
> | When this happened once before, about 4 years ago, after much
> thrashing
> | about I gave up finally, not knowing about the newsgroup as a
> resource, and
> | bought the Seagate to replace the WD, installed W98SE, and when not
> only
> | everything seemed to work, but I had less trouble installing and
> setting up
> | than in any of the previous installs, I thought I had made a
> fortunate,
> | move, however blindly.
> | Now I should mention that which was discussed ad nauseam in the
> | 'Restart...' thread, namely that the hardware is built on an Eteq mbd,
> VL
> | bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller,
> which has
> | its own BIOS, enabling it to do several things not particularly
> germane to
> | the problem, except for the fact that it allows me to use a drive as
> large
> | as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> | Thus, for the previous setup in which I used just the WD and
> Quantum
> | (same partns), the partitions for the WD were C and E (using FAT16 and
> | trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for
> the
> | disk setup. Now it's been some while ago, but as memory serves, it
> was a
> | *very* similar sort of failure, made worse by some other complications
> that
> | I would rather not go into here. I wouldn't stake my life on it being
> the
> | same, but I have my suspicions.
> | Anyhow, when I went to use the Seagate, it wouldn't handle
> it--make a
> | long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> | controller BIOS, I discovered, could handle it, so that caused me to
> start
> | using it. This requires, as you may expect, not setting it in the mbd
> BIOS,
> | and activating the Promise BIOS which is done through an on-board
> program,
> | and everything came up roses.
> | Now, this time when things went south, the Promise BIOS program
> still
> | had all the correct parameters in it, and I should mention that it is
> all
> | automated, and so there isn't much possiblity of getting it messed up.
> The
> | fact that the PM reading of the partitions came up with all the right
> data,
> | suggests that the problem is not with the hard drive, controller, or
> any
> | such thing. Since it must still be operating with IO.SYS, it's my bet
> that
> | there's something rotten there, but I don't see how to get to it,
> short of
> | trying to slave it to another machine.
> | My reluctance there is based on the fact that I didn't have
> firewall
> | protection on that machine, and since I have started perforce using
> this one
> | (which has the EZ-Armor on it) I have been astounded by the number of
> times
> | it has blocked some sort of invasion (not all of which are ISP pings).
> This
> | makes me a little less secure in any assumptions regarding what caused
> all
> | this. If I slave it to this machine, I suppose it should be secure
> enough
> | until I attempt to access something on it. Question is, does simply
> reading
> | the FAT pose a risk? If not, I could do a scan of the drive, once
> this
> | machine booted. I'd still have the question of the MBR, but I expect
> I
> | could look at it with Debug (if I can find it) and see of the EOS byte
> is
> | there. I'd have to deactivate the primary partition, I guess. What
> happens
> | if you have a slaved disk which also has a prmary active partition?
> Surely
> | DOS 7 wouldn't like that.
> |
> | Thanks again, I appreciate your efforts and advice,
> | Joe
> | "PCR" > wrote in message
> | ...
> | > Oops. I was too quick to post that quote of...
> | >
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> | > ...It wouldn't be a "MS-DOS 6.x Upgrade Setup Disk 1" for you, but
> JUST
> | > a regular Startup Diskette.
> | >
> | > (1) Perhaps yours is bad, if it will not see partitions. Then...
> | > Get a Startup Diskette from
> | > http://www.bootdisk.com/ , if you don't already have one from
> "Control
> | > Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
> | > Diskette. Boot it, put in a CD and "DIR" the CD. It will say which
> | > letter is the CD. (Otherwise, it is likely one letter higher than
> | > normal.)
> | >
> | > (2) Perhaps your partition are not the "type" that are recognizable
> by
> | > DOS. Then, you must wait for Blanton to arrive. (I still haven't
> | > assimilated it.) Does Partition Magic allow you to change the
> partition
> | > "type". NATURALLY, all one may safely do is to change it from a
> hidden
> | > type to it's proper unhidden form. One may NOT simply convert an
> NTFS to
> | > a FAT32, for example, by changing type!
> | >
> | >
> | > --
> | > Thanks or Good Luck,
> | > There may be humor in this post, and,
> | > Naturally, you will not sue,
> | > should things get worse after this,
> | > PCR
> | >
> | > "jt3" > wrote in message
> | > ...
> | > | That's what I was trying to say: although the PM 'Recovery
> Disk'
> | > | (mainly a
> | > | boot disk with PM on it) shows the partitions on both disks as
> present
> | > and
> | > | with no problems, the boot disk DOS can't see them--not even
> C:\--even
> | > | though if you don't use the boot disk, it's clearly using the C
> drive
> | > to get
> | > | the message: 'Type the name of the Command Interpreter....' as I
> | > described
> | > | previously.
> | > | I think this may go back to a thread back in April, or March,
> in
> | > which
> | > | you and cquirke and several other people got involved, but then it
> was
> | > a
> | > | question of Restarting in DOS Mode. Although I finally thought
> that I
> | > had
> | > | the
> | > | answer in the question of the receipt of the Windows shutdown
> | > broadcast (and
> | > | the answer may still lie there) I was never able to fix it, and
> other
> | > things
> | > | (the machine I'm using now) came to the fore. Unfortunately, I
> only
> | > | archived a few of the posts, and I was using the MS support
> interface
> | > at the
> | > | time. The server doesn't seem to have retained any posts prior to
> the
> | > | beginning of May, so I can't find the thread there, and it
> probably
> | > wouldn't
> | > | do much good, since I doubt I could convince anyone that the two
> are
> | > | related. Would take even longer to explain why I think so, and
> it's
> | > | irrelevant, if the thread's not available.
> | > | Obviously, this rambling reflects the state of my
> understanding,
> | > but it
> | > | comes down to: If PM can see the disks and the partitions, (1)
> why
> | > can't a
> | > | boot disk see any of them, and (2) how does one access anything on
> the
> | > disk
> | > | if the boot disk can't see it. Along the way, I might mention
> that
> | > this is
> | > | an installation without any older DOS on it, so that it would be
> | > deadly to
> | > | overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files would
> have
> | > to
> | > | come off the W98SE installation disk, and that's a little
> difficult as
> | > it
> | > | stands. I certainly don't want to reformat the disk.
> | > |
> | > | Thanks,
> | > | Joe
> | > | "PCR" > wrote in message
> | > | ...
> | > | >
> | >
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> | > | > Err Msg: The Following File Is Missing or Corrupt...
> | > | > (187641) - When you start your computer, you may receive the
> | > following
> | > | > error message: The following file is missing or corrupt:
> | > COMMAND.COM.
> | > | > Type the name of the Command Interpreter.
> | > | >
> | > | > It says...
> | > | > ......Quote article...................
> | > | > RESOLUTION
> | > | > To resolve this problem, use the MS-DOS 6.x Upgrade Setup Disk 1
> to
> | > | > restart your computer, and then use the SYS command on drive C.
> To
> | > do
> | > | > so, follow these steps:
> | > | >
> | > | > 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and
> then
> | > | > restart your computer.
> | > | > 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS
> Setup.
> | > | > 3. Type sys c:, and then press ENTER.
> | > | > 4. Restart your computer.
> | > | > ......End of quote....................
> | > | >
> | > | > HOWEVER... here are some warnings...
> | > | >
> | > | > This will copy certain system files (IO.sys, Command.com &
> perhaps
> | > | > MSDOS.sys) from the Startup Diskette to C:\. (It also sets the
> BPB
> | > drive
> | > | > number to HD0, so that it is now in the bootstrap. It does so,
> no
> | > matter
> | > | > whether it is HD0. To boot it, one must still move it to be HD0,
> | > | > however.) You may now be able to boot to Windows, if all folders
> are
> | > | > intact. If not, some further adjustment need be done to
> "MSDOS.sys",
> | > | > that was copied to C:\. The floppy has just a shell of it. Well,
> | > remove
> | > | > the floppy & boot.
> | > | >
> | > | > Oh gosh! Here are some warnings from Jeff Richards, MS MVP
> W95/W98,
> | > | > about "SYS C:". DON'T DO IT, he says, if:
> | > | >
> | > | > (a) "Major errors were reported in Scandisk."
> | > | > (b) "A drive is moved from one machine to another", because of
> the
> | > next
> | > | > two, maybe.
> | > | > (c) "The BIOS setting for a drive is changed (eg, LBA to
> LARGE)."
> | > | > (d) "A drive that uses overlay software is operated without the
> | > overlay
> | > | > loaded."
> | > | >
> | > | >
> | > | > --
> | > | > Thanks or Good Luck,
> | > | > There may be humor in this post, and,
> | > | > Naturally, you will not sue,
> | > | > should things get worse after this,
> | > | > PCR
> | > | >
> | > | > "jt3" > wrote in message
> | > | > ...
> | > | > | Yes that was what I was recalling something about--as I
> said
> | > to
> | > | > Curt,
> | > | > | all my refs went down with that machine.
> | > | > | The problem here is that this is wierd--it's clear that
> the
> | > boot
> | > | > code
> | > | > | is working to some degree--'Starting Windows 98' comes up
> first,
> | > which
> | > | > it
> | > | > | normally wouldn't show, then it comes up with 'Type the name
> of
> | > the
> | > | > Command
> | > | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even
> though
> | > | > there's no
> | > | > | disk, boot or otherwise in the floppy drive. Also, putting in
> the
> | > | > startup
> | > | > | disk doesn't get me anywhere--after choosing boot without
> cd-rom,
> | > to
> | > | > | simplify it, it just hangs with the floppy drive trying to
> access
> | > | > something.
> | > | > | But it seems that this must be coming from IO.SYS, since there
> | > | > couldn't be
> | > | > | much else doing it, if no COMMAND.COM has been loaded (of
> | > course..who
> | > | > | knows..).
> | > | > | I should mention that this started with an *apparent* CMOS
> | > | > failure--a
> | > | > | little strange since I just replaced it with a new Li cell
> just a
> | > year
> | > | > and a
> | > | > | month ago. Nothing very strange seemed to have happened to
> it,
> | > except
> | > | > all
> | > | > | the drives (floppies, too) had been lost, and this was on the
> | > first
> | > | > boot of
> | > | > | the day.
> | > | > | I reset the boot order for it to boot A: first (had been
> C:
> | > then
> | > | > A:) and
> | > | > | was able then to boot to DOS from the startup disk, but could
> not
> | > see
> | > | > the
> | > | > | other drives (just A:). I had previously installed an old
> version
> | > | > (4.0) of
> | > | > | Partition Magic and used the PM recovery disk to find out that
> the
> | > | > | partitions were all still there--but this version doesn't do
> | > anything
> | > | > for
> | > | > | MBRs, apparently.
> | > | > | In short, the EOS byte could easily be missing, AFAIK, and
> the
> | > | > only
> | > | > | thing I can see at the moment is to use Debug to see if it's
> still
> | > | > there.
> | > | > | Clearly, I would welcome any thoughts on the subject
> before I
> | > try
> | > | > | anything. I'm a little leery of slaving the disk to my other
> | > machine,
> | > | > if I
> | > | > | don't know for sure what caused the problem.
> | > | > |
> | > | > | Thanks for your time,
> | > | > | Joe
> | > | > | "PCR" > wrote in message
> | > | > | ...
> | > | > | > Enter "FDISK /MBR"
> | > | > | > This will rewrite the code portion of the Master Boot
> | > Record,
> | > | > | > leaving the Partition Table untouched, except it may muss
> the
> | > | > partition
> | > | > | > table, if there is a missing End-Of-Sector marker (55AA),
> per
> | > | > | > http://support.microsoft.com/?kbid=149877
> | > | > | > Boot Record Signature AA55 Not Found
> | > | > | >
> | > | > | > Here are the warnings against it...
> | > | > | >
> | > | > | > (a) If you have a boot sector virus, you may lose access to
> all
> | > | > | > partitions. Then
> | > | > | > http://www.terabyteunlimited.com/utilities.html MBRWork
> "might"
> | > help
> | > | > to
> | > | > | > recover them.
> | > | > | >
> | > | > | > (b) If you have "overlay" code in the MBR, e.g., EZ-BIOS,
> | > Maxblast,
> | > | > a
> | > | > | > boot manager, then that will need to be reestablished
> | > afterwards.
> | > | > | > http://www.aefdisk.com/ FDISK & Boot Manager
> | > | > | >
> http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
> | > | > Overlay
> | > | > | > Utility & FDISK
> | > | > | >
> | > | > | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> | > | > | >
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> | > | > | > Latest FDISK, hoping this one doesn't have any bugs. (But it
> | > doesn't
> | > | > | > solve the 55AA thing.)
> | > | > | >
> | > | > | > (d) If for some reason the "geometry" setting in BIOS does
> not
> | > match
> | > | > the
> | > | > | > hard drive, then any write to the drive may be destructive.
> So,
> | > go
> | > | > into
> | > | > | > BIOS and have it "automatically detect" the proper setting.
> (If
> | > you
> | > | > can
> | > | > | > DIR the drive in DOS, then you have proven the geometry is
> | > right.
> | > | > Well,
> | > | > | > Blanton says even that may not be true.)
> | > | > | >
> | > | > | >
> | > | > | > --
> | > | > | > Thanks or Good Luck,
> | > | > | > There may be humor in this post, and,
> | > | > | > Naturally, you will not sue,
> | > | > | > should things get worse after this,
> | > | > | > PCR
> | > | > | >
> | > | > | > "jt3" > wrote in message
> | > | > | > ...
> | > | > | > | I think I recall reading someone posting that the /MBR
> | > switch
> | > | > on
> | > | > | > FDISK
> | > | > | > | not only rewrites the master boot record, but also wipes
> out
> | > | > partition
> | > | > | > table
> | > | > | > | data, so that if you use /MBR on a disk with multiple
> | > partitions
> | > | > on
> | > | > | > it, you
> | > | > | > | lose the partition data. Is this true?
> | > | > | > | I have a problem with a corrupted MBR (I think) and my
> old
> | > | > version
> | > | > | > of
> | > | > | > | Partition Magic doesn't do the MBR, apparently.
> | > | > | > | Thanks for your time, as always,
> | > | > | > | Joe
> | > | > | > |
> | > | > | > |
> | > | > | >
> | > | > | >
> | > | > |
> | > | > |
> | > | >
> | > | >
> | > |
> | > |
> | > |
> | >
> | >
> |
> |
> |
>
>

Bill Blanton
June 7th 04, 05:05 AM
A fact is that PM doesn't have to mount the volume, only define the
various partitions according to the table(s) information. Win/DOS otoh
has to define the partition structure and then define the OS specific
volumes using the boot sectors' information. And of course, furthur
along it will have to decode the Dir structure and FAT, but corruption
there would probably just show corrupt files, or "file not found".
You should still get a "C:" in that case (if the boot sector was sane).

Simply put, PM doesn't have to worry if a partition's content is
corrupt, only that it exists.

What's strange is that you get the "Starting Win 98..." message when
you boot from HD0. This suggests that the volume was properly mounted
and at least started to boot.

I don't really know, but I would suspect a slightly off geomtry
(except PM apparently isn't having a problem), or a bad boot sector
(except you wouldn't expect IO.SYS to be started, and you wouldn't
expect both drives to become corrupt).

I don't really think it's the MBR, or the tables, or the ending sig,
since the partitions look good to PM and a HD boot is at least loading
IO.SYS.

Until you figure it out you don't want to attempt any writes to the
disks. Including fdisk/mbr. You shouldn't have any problem hooking the
drive up as a slave even with an active partition on the disk, but be
aware that if you hook it up to a system that has System Restore
enabled (such as ME or XP), the system will attempt to write SR
data to the disk. That could be bad if the geometry is skewd.


At this point, I would run PM's partinfo util and see what it has to
say. You'll find it on the CD in the \UTILITY directory. At the prompt
run
partinfo > partinfo.txt
and then open partinfo in a text editor. If you want you can mail it
to me at billblanton<At>earthlink<dot>net Partinfo also displays boot
sector information, so mabey something obvious will turn up. It might
also point to geometry conflict between the disk and the card's BIOS.

As I said before I don't think it's the MBR, but if you want to look
you can run this debug script to dump HD0's 1st sector. Save as
"dump.scr" (or whatever) and run
debug < dump.scr > dump.txt
Then open dump.txt in edit to check the ending sig bytes.

rip
0300
a 0300
mov al,1
mov ch,0
mov cl,1
mov dh,0
mov dl,80
push ds
pop es
xor bx,bx
mov ah,2
int 13

g 312

d es:0000 L200

q
(make sure there is a cr/lf after "q", or it will lock)




"jt3" > wrote in message ...
> I actually tried three different boot disks I have, all for W98SE, two
> made on that machine, and one on this. They all did the same thing, and
> although I haven't tried them on this one lately, I suspect that it would
> net nothing new. The drives don't have any esoteric type of partitions on
> them, just standard DOS primary and extended on the 80 drive, FAT 32, the C
> partition about 750 MB and the E partition is the balance of the 8 GB
> Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> partitioned into 4 partitions, 1 primary, 3 in the extended.
> At one time, I was using a WD Caviar 850 MB as the C drive, and I had
> W95SR2.1 on it, with the Quantum providing the same as it provides now.
> When this happened once before, about 4 years ago, after much thrashing
> about I gave up finally, not knowing about the newsgroup as a resource, and
> bought the Seagate to replace the WD, installed W98SE, and when not only
> everything seemed to work, but I had less trouble installing and setting up
> than in any of the previous installs, I thought I had made a fortunate,
> move, however blindly.
> Now I should mention that which was discussed ad nauseam in the
> 'Restart...' thread, namely that the hardware is built on an Eteq mbd, VL
> bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller, which has
> its own BIOS, enabling it to do several things not particularly germane to
> the problem, except for the fact that it allows me to use a drive as large
> as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> Thus, for the previous setup in which I used just the WD and Quantum
> (same partns), the partitions for the WD were C and E (using FAT16 and
> trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for the
> disk setup. Now it's been some while ago, but as memory serves, it was a
> *very* similar sort of failure, made worse by some other complications that
> I would rather not go into here. I wouldn't stake my life on it being the
> same, but I have my suspicions.
> Anyhow, when I went to use the Seagate, it wouldn't handle it--make a
> long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> controller BIOS, I discovered, could handle it, so that caused me to start
> using it. This requires, as you may expect, not setting it in the mbd BIOS,
> and activating the Promise BIOS which is done through an on-board program,
> and everything came up roses.
> Now, this time when things went south, the Promise BIOS program still
> had all the correct parameters in it, and I should mention that it is all
> automated, and so there isn't much possiblity of getting it messed up. The
> fact that the PM reading of the partitions came up with all the right data,
> suggests that the problem is not with the hard drive, controller, or any
> such thing. Since it must still be operating with IO.SYS, it's my bet that
> there's something rotten there, but I don't see how to get to it, short of
> trying to slave it to another machine.
> My reluctance there is based on the fact that I didn't have firewall
> protection on that machine, and since I have started perforce using this one
> (which has the EZ-Armor on it) I have been astounded by the number of times
> it has blocked some sort of invasion (not all of which are ISP pings). This
> makes me a little less secure in any assumptions regarding what caused all
> this. If I slave it to this machine, I suppose it should be secure enough
> until I attempt to access something on it. Question is, does simply reading
> the FAT pose a risk? If not, I could do a scan of the drive, once this
> machine booted. I'd still have the question of the MBR, but I expect I
> could look at it with Debug (if I can find it) and see of the EOS byte is
> there. I'd have to deactivate the primary partition, I guess. What happens
> if you have a slaved disk which also has a prmary active partition? Surely
> DOS 7 wouldn't like that.
>

jt3
June 7th 04, 07:02 AM
Bill,
I believe that the 'Partition Info' button on the DOS version of PM4.0
that I have on those recovery disks calls up partinfo.exe and that is why I
was told to put in the second disk of the set, which has partinfo.exe on it;
anyhow, that was what I did at the time, and, so far as I could tell with my
brief look at it, it all looked pretty much as I recalled having set it up.
Both drives, tho of course, it has been a while since I did it.
I can do it again but will have to rig up an editor as well as change
the config files that run it from the floppy so that I can get the info that
way. As I said in my last post to PCR, I am pretty sure it's calling that
string out of IO.SYS, which makes me, for the reasons I stated in that post,
think that the problem lies in IO.SYS, but if so, it's rather strange
corruption, sort of the single bit type, rather than the usual sort where
something gets written over.
This computer also runs SE, so there wouldn't be the problem of System
Restore running.
I may run your debug script (thanks) to dump the first sector, though I
suspect that the MBR is probably OK, as I said in the previous post, since
it didn't go too far astray to get to IO.SYS.
Finally, I *think* that a sys.com from the boot floppy ought to replace
IO.SYS on the C drive, but I'm not all that sure I know which floppy I'd
trust the most, and I'm also not sure that all IO.SYSes are the same, i.e.,
from machine to machine, and especially from instance to instance of SE. I
*assume* that all the machine-specific modification is done in the building
of VMM in windows, but it strikes me as possible that some differences could
exist as a result of installation on different machines--I really don't
know, though I'd guess, again, that they're all the same. Some early
versions of DOS had differences, but that was some time ago.
Got to turn in, been burning too much late oil, tackle the problem later
and get back to you as soon as I have something of any interest.

Thanks for all your time and thought on the matter,
Joe.
"Bill Blanton" > wrote in message
...
> A fact is that PM doesn't have to mount the volume, only define the
> various partitions according to the table(s) information. Win/DOS otoh
> has to define the partition structure and then define the OS specific
> volumes using the boot sectors' information. And of course, furthur
> along it will have to decode the Dir structure and FAT, but corruption
> there would probably just show corrupt files, or "file not found".
> You should still get a "C:" in that case (if the boot sector was sane).
>
> Simply put, PM doesn't have to worry if a partition's content is
> corrupt, only that it exists.
>
> What's strange is that you get the "Starting Win 98..." message when
> you boot from HD0. This suggests that the volume was properly mounted
> and at least started to boot.
>
> I don't really know, but I would suspect a slightly off geomtry
> (except PM apparently isn't having a problem), or a bad boot sector
> (except you wouldn't expect IO.SYS to be started, and you wouldn't
> expect both drives to become corrupt).
>
> I don't really think it's the MBR, or the tables, or the ending sig,
> since the partitions look good to PM and a HD boot is at least loading
> IO.SYS.
>
> Until you figure it out you don't want to attempt any writes to the
> disks. Including fdisk/mbr. You shouldn't have any problem hooking the
> drive up as a slave even with an active partition on the disk, but be
> aware that if you hook it up to a system that has System Restore
> enabled (such as ME or XP), the system will attempt to write SR
> data to the disk. That could be bad if the geometry is skewd.
>
>
> At this point, I would run PM's partinfo util and see what it has to
> say. You'll find it on the CD in the \UTILITY directory. At the prompt
> run
> partinfo > partinfo.txt
> and then open partinfo in a text editor. If you want you can mail it
> to me at billblanton<At>earthlink<dot>net Partinfo also displays boot
> sector information, so mabey something obvious will turn up. It might
> also point to geometry conflict between the disk and the card's BIOS.
>
> As I said before I don't think it's the MBR, but if you want to look
> you can run this debug script to dump HD0's 1st sector. Save as
> "dump.scr" (or whatever) and run
> debug < dump.scr > dump.txt
> Then open dump.txt in edit to check the ending sig bytes.
>
> rip
> 0300
> a 0300
> mov al,1
> mov ch,0
> mov cl,1
> mov dh,0
> mov dl,80
> push ds
> pop es
> xor bx,bx
> mov ah,2
> int 13
>
> g 312
>
> d es:0000 L200
>
> q
> (make sure there is a cr/lf after "q", or it will lock)
>
>
>
>
> "jt3" > wrote in message
...
> > I actually tried three different boot disks I have, all for W98SE,
two
> > made on that machine, and one on this. They all did the same thing, and
> > although I haven't tried them on this one lately, I suspect that it
would
> > net nothing new. The drives don't have any esoteric type of partitions
on
> > them, just standard DOS primary and extended on the 80 drive, FAT 32,
the C
> > partition about 750 MB and the E partition is the balance of the 8 GB
> > Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> > partitioned into 4 partitions, 1 primary, 3 in the extended.
> > At one time, I was using a WD Caviar 850 MB as the C drive, and I
had
> > W95SR2.1 on it, with the Quantum providing the same as it provides now.
> > When this happened once before, about 4 years ago, after much thrashing
> > about I gave up finally, not knowing about the newsgroup as a resource,
and
> > bought the Seagate to replace the WD, installed W98SE, and when not only
> > everything seemed to work, but I had less trouble installing and setting
up
> > than in any of the previous installs, I thought I had made a fortunate,
> > move, however blindly.
> > Now I should mention that which was discussed ad nauseam in the
> > 'Restart...' thread, namely that the hardware is built on an Eteq mbd,
VL
> > bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller, which
has
> > its own BIOS, enabling it to do several things not particularly germane
to
> > the problem, except for the fact that it allows me to use a drive as
large
> > as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> > Thus, for the previous setup in which I used just the WD and Quantum
> > (same partns), the partitions for the WD were C and E (using FAT16 and
> > trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for
the
> > disk setup. Now it's been some while ago, but as memory serves, it was
a
> > *very* similar sort of failure, made worse by some other complications
that
> > I would rather not go into here. I wouldn't stake my life on it being
the
> > same, but I have my suspicions.
> > Anyhow, when I went to use the Seagate, it wouldn't handle it--make
a
> > long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> > controller BIOS, I discovered, could handle it, so that caused me to
start
> > using it. This requires, as you may expect, not setting it in the mbd
BIOS,
> > and activating the Promise BIOS which is done through an on-board
program,
> > and everything came up roses.
> > Now, this time when things went south, the Promise BIOS program
still
> > had all the correct parameters in it, and I should mention that it is
all
> > automated, and so there isn't much possiblity of getting it messed up.
The
> > fact that the PM reading of the partitions came up with all the right
data,
> > suggests that the problem is not with the hard drive, controller, or any
> > such thing. Since it must still be operating with IO.SYS, it's my bet
that
> > there's something rotten there, but I don't see how to get to it, short
of
> > trying to slave it to another machine.
> > My reluctance there is based on the fact that I didn't have firewall
> > protection on that machine, and since I have started perforce using this
one
> > (which has the EZ-Armor on it) I have been astounded by the number of
times
> > it has blocked some sort of invasion (not all of which are ISP pings).
This
> > makes me a little less secure in any assumptions regarding what caused
all
> > this. If I slave it to this machine, I suppose it should be secure
enough
> > until I attempt to access something on it. Question is, does simply
reading
> > the FAT pose a risk? If not, I could do a scan of the drive, once this
> > machine booted. I'd still have the question of the MBR, but I expect I
> > could look at it with Debug (if I can find it) and see of the EOS byte
is
> > there. I'd have to deactivate the primary partition, I guess. What
happens
> > if you have a slaved disk which also has a prmary active partition?
Surely
> > DOS 7 wouldn't like that.
> >
>
>

PCR
June 7th 04, 09:24 AM
I see you never did install WD's EZ-BIOS, unless it were four years ago
in a different event. I'm still thinking the failure to boot from a
floppy can have to do with the Maxtor BIOS, though. The floppy will not
go through the HDD's MBR, which may now be Maxtor specific. Not going
that way, the floppy cannot see the geometry change. But that is only a
guess on my part. Why does PM work? Perhaps it knows more than the
floppy. Or it could be as Blanton said: it doesn't need to do as much.
It could be the floppy only has access to the motherboard BIOS. But this
is all theoretical.

The error message you get when booting the HDD is...

| is working to some degree--'Starting Windows 98' comes up first, which
it
| normally wouldn't show, then it comes up with 'Type the name of the
Command
| Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
there's no
| disk, boot or otherwise in the floppy drive.

....which does sound like that article I posted, which calls for a "SYS
C:". But I suppose you'd better send that PM PartInfo to Blanton,
first. Don't forget all those warnings about SYS C:.

Where is that URL he posted that showed native Windows MBR code? No
matter. I suppose the message is coming out of IO.sys, not that code.
I'm still here, but better deal with Blanton first.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"jt3" > wrote in message
...
| *Never* installed *any* disk overlay software on this or any other
| machine. These hds were blank when I installed them. This is a
machine I
| built from scratch some years ago (1995, to be more precise) and I
know all
| the stuff that ever went into it.
| Not sure if you took the output string as proof of the existence
of a
| drive overlay. PM refers to Partition Magic, version 4.0, which I
used to
| check and see if the drives and partitions were still as they should
be.
| All I did with it is 'look'--I made no changes
| with PM.
| As it happens the Quantum Bigfoot predates their acquisition by
Maxtor
| (so it may have been more than 4 years ago that the earlier problem
| occurred--when you get to my age time seems to pass a good deal faster
than
| it once did). There was some disk overlay program offered by Quantum
at the
| time, I think it was OnTrack, which I read is the basis for MaxBlast,
and I
| *do* have a Maxtor on the FIC K6 machine I'm using at the moment, but
I have
| always avoided overlay programs because they are so problematic when
using
| any kind of disk software. So it is fairly certain that there is no
Maxtor
| or WD,
| or any other hd mfgr proprietary disk overlay program on either disk;
if one
| got there, it had to have been put there by the Promise BIOS, and
don't
| think that likely.
| I must admit, however, that the Promise adapter is supposed to
support
| *four* IDE hds on the primary channel, in addition to providing the
| secondary channel for use with CD-R/OM/RWs (two max).
| As it happens I was not using it that way, though I once tried it
and
| found that it worked pretty much as they said. I have no idea how
they
| achieve this, and they gave no clue in the documentation, but since
ATA is
| fairly close to SCSI, they must all be daisy chained together in a
similar
| manner; all SCSI cards I know of (including the one on this machine)
use
| onboard BIOSes to do this, and I never heard of one surreptitiously
| installing a disk overlay.
| The documentation instructs the user to use Promise's version of
FDISK,
| which sounds suspicious, but in fact when I tried using the extra disk
| drive, I *did_not* use their FDISK version to format the disk (for
several
| reasons), and in fact just hooked up three previously formatted and
occupied
| disks; for the short space of time that I tried using it that way
(about
| three months) it gave no particular trouble (other than that detailed
| below), but I cannot say that the previously mentioned crash of about
4
| years ago was totally independent (since that wipe-out happened only a
few
| months later)-- but I don't think so. The problems then seemed more
to
| result from the use of the WD drive (I had another just like it) and
| disappeared when I took the WDs off. Since they were so small (856M),
I
| stayed with the Quantum. This was because I found Promise docs online
which
| said to beware of WD drives, as they often wouldn't work right with
it,
| especially when used with another brand of disk. I've not experienced
any
| similar problems with the Seagate and the Quantum together, however.
| Please note:
| (1) The Seagate (8 GB) FAT32 is partitioned to C and E, the
Quantum
| (2GB) is FAT16 partitioned to D, F, G, and H. Neither has any disk
overlay
| applied--I used FDISK straight from the box to set them up. The fact
that
| the string output when trying to change to C: is that given in KB
245162
| doesn't tell me that it necessarily has a disk overlay (except as
mentioned
| in the caveat above, and I have used a boot disk before without
problem,
| though it was, it's true, on W95SR2.1) and the rest of the
symptomatology
| suggests that there's more than a disk overlay in the works.
| (2) The message displayed on the screen when one attempts to boot
the
| machine (without boot disk) is letter perfect out of IO.SYS, in the
literals
| near the 'Starting Windows 98' string (which normally never appears,
but
| *does* in this case). This of course only means that IO.SYS is
executing in
| some way, if not the correct one.
| (3) (2) implies that it got out of the MBR, though not necessarily
in
| the correct fashion, but it *doesn't* imply that the EOS byte is
there.
| Probably, but not with any certainty. Since IO.SYS no longer has to
reside
| first on the disk, and since there is a partition table between we can
| assume that it got there by some kind of jump, I think.
| Thus if I acted on a pure guess, it seems fairly likely that the
MBR is
| probably still OK, and it's IO.SYS that's most likely in need of aid.
| Trouble is, I don't have a lot of confidence in this--way too much I
don't
| know anything about here..
| (4) KB149877 says that it applies to Win2K, NT(various flavors),
WfW,
| and W95, but *doesn't* mention W98 or SE or ME. The fact that it
skips
| right over W98 and ME causes me a little concern when strictly
interpreting
| some of it's suggestions, viz. using FDISK/mbr and partition table
info
| safety.
|
| All in all, I'm still nowhere, and hope you or someone else can
point a
| way that looks a little less hazardous.
|
| Thanks for your time and effort,
| Joe
| "PCR" > wrote in message
| ...
| > (1) I guess the Startup Diskettes are OK, except for one
possibility. If
| > EZ-BIOS or such has been installed to an HDD, then it must (a) also
be
| > installed to the floppy, or (b) present an option during boot to
boot
| > the floppy. Otherwise, a floppy will fail to read the HDD. This is
| > because EZ-BIOS (or the Maxtor equivalent) has altered the HDD
| > "geometry".
| >
| > (2) I don't know how you could check it (not able to boot to DOS),
but
| > each HDD must have one & only one partition marked as Active. (That
is
| > unless your Maxtor BIOS gets around it somehow.) Otherwise, you
cannot
| > boot.
| >
| > (3) I don't know what could happen, if you are mixing WD's EZ-BIOS
with
| > Maxtor's equivalent.
| >
| > (4)
| > | this. If I slave it to this machine, I suppose it should be
secure
| > enough
| > | until I attempt to access something on it. Question is, does
simply
| > reading
| > | the FAT pose a risk? If not, I could do a scan of the drive, once
| > this
| >
| > I'm not sure of the risks. I know when EZ-BIOS or such is installed
to
| > an HDD, it gets into the MBR. Therefore, moving the HDD to another
| > machine brings it along. HOWEVER, it that all there is to it? I thin
k
| > not in the case of Maxtor anyway, which got into the BIOS. Moving an
HDD
| > in that case leaves the BIOS behind. So, how can one get the
"geometry"
| > right?
| >
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| >
| > "jt3" > wrote in message
| > ...
| > | I actually tried three different boot disks I have, all for
W98SE,
| > two
| > | made on that machine, and one on this. They all did the same
thing,
| > and
| > | although I haven't tried them on this one lately, I suspect that
it
| > would
| > | net nothing new. The drives don't have any esoteric type of
| > partitions on
| > | them, just standard DOS primary and extended on the 80 drive, FAT
32,
| > the C
| > | partition about 750 MB and the E partition is the balance of the 8
GB
| > | Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
| > | partitioned into 4 partitions, 1 primary, 3 in the extended.
| > | At one time, I was using a WD Caviar 850 MB as the C drive,
and I
| > had
| > | W95SR2.1 on it, with the Quantum providing the same as it provides
| > now.
| > | When this happened once before, about 4 years ago, after much
| > thrashing
| > | about I gave up finally, not knowing about the newsgroup as a
| > resource, and
| > | bought the Seagate to replace the WD, installed W98SE, and when
not
| > only
| > | everything seemed to work, but I had less trouble installing and
| > setting up
| > | than in any of the previous installs, I thought I had made a
| > fortunate,
| > | move, however blindly.
| > | Now I should mention that which was discussed ad nauseam in
the
| > | 'Restart...' thread, namely that the hardware is built on an Eteq
mbd,
| > VL
| > | bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller,
| > which has
| > | its own BIOS, enabling it to do several things not particularly
| > germane to
| > | the problem, except for the fact that it allows me to use a drive
as
| > large
| > | as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
| > | Thus, for the previous setup in which I used just the WD and
| > Quantum
| > | (same partns), the partitions for the WD were C and E (using FAT16
and
| > | trying to avoid cluster size inefficiencies) I used the *mbd BIOS*
for
| > the
| > | disk setup. Now it's been some while ago, but as memory serves,
it
| > was a
| > | *very* similar sort of failure, made worse by some other
complications
| > that
| > | I would rather not go into here. I wouldn't stake my life on it
being
| > the
| > | same, but I have my suspicions.
| > | Anyhow, when I went to use the Seagate, it wouldn't handle
| > it--make a
| > | long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
| > | controller BIOS, I discovered, could handle it, so that caused me
to
| > start
| > | using it. This requires, as you may expect, not setting it in the
mbd
| > BIOS,
| > | and activating the Promise BIOS which is done through an on-board
| > program,
| > | and everything came up roses.
| > | Now, this time when things went south, the Promise BIOS
program
| > still
| > | had all the correct parameters in it, and I should mention that it
is
| > all
| > | automated, and so there isn't much possiblity of getting it messed
up.
| > The
| > | fact that the PM reading of the partitions came up with all the
right
| > data,
| > | suggests that the problem is not with the hard drive, controller,
or
| > any
| > | such thing. Since it must still be operating with IO.SYS, it's my
bet
| > that
| > | there's something rotten there, but I don't see how to get to it,
| > short of
| > | trying to slave it to another machine.
| > | My reluctance there is based on the fact that I didn't have
| > firewall
| > | protection on that machine, and since I have started perforce
using
| > this one
| > | (which has the EZ-Armor on it) I have been astounded by the number
of
| > times
| > | it has blocked some sort of invasion (not all of which are ISP
pings).
| > This
| > | makes me a little less secure in any assumptions regarding what
caused
| > all
| > | this. If I slave it to this machine, I suppose it should be
secure
| > enough
| > | until I attempt to access something on it. Question is, does
simply
| > reading
| > | the FAT pose a risk? If not, I could do a scan of the drive, once
| > this
| > | machine booted. I'd still have the question of the MBR, but I
expect
| > I
| > | could look at it with Debug (if I can find it) and see of the EOS
byte
| > is
| > | there. I'd have to deactivate the primary partition, I guess.
What
| > happens
| > | if you have a slaved disk which also has a prmary active
partition?
| > Surely
| > | DOS 7 wouldn't like that.
| > |
| > | Thanks again, I appreciate your efforts and advice,
| > | Joe
| > | "PCR" > wrote in message
| > | ...
| > | > Oops. I was too quick to post that quote of...
| > | >
| >
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
| > | > ...It wouldn't be a "MS-DOS 6.x Upgrade Setup Disk 1" for you,
but
| > JUST
| > | > a regular Startup Diskette.
| > | >
| > | > (1) Perhaps yours is bad, if it will not see partitions. Then...
| > | > Get a Startup Diskette from
| > | > http://www.bootdisk.com/ , if you don't already have one from
| > "Control
| > | > Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
| > | > Diskette. Boot it, put in a CD and "DIR" the CD. It will say
which
| > | > letter is the CD. (Otherwise, it is likely one letter higher
than
| > | > normal.)
| > | >
| > | > (2) Perhaps your partition are not the "type" that are
recognizable
| > by
| > | > DOS. Then, you must wait for Blanton to arrive. (I still haven't
| > | > assimilated it.) Does Partition Magic allow you to change the
| > partition
| > | > "type". NATURALLY, all one may safely do is to change it from a
| > hidden
| > | > type to it's proper unhidden form. One may NOT simply convert an
| > NTFS to
| > | > a FAT32, for example, by changing type!
| > | >
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | >
| > | > "jt3" > wrote in message
| > | > ...
| > | > | That's what I was trying to say: although the PM
'Recovery
| > Disk'
| > | > | (mainly a
| > | > | boot disk with PM on it) shows the partitions on both disks as
| > present
| > | > and
| > | > | with no problems, the boot disk DOS can't see them--not even
| > C:\--even
| > | > | though if you don't use the boot disk, it's clearly using the
C
| > drive
| > | > to get
| > | > | the message: 'Type the name of the Command Interpreter....' as
I
| > | > described
| > | > | previously.
| > | > | I think this may go back to a thread back in April, or
March,
| > in
| > | > which
| > | > | you and cquirke and several other people got involved, but
then it
| > was
| > | > a
| > | > | question of Restarting in DOS Mode. Although I finally
thought
| > that I
| > | > had
| > | > | the
| > | > | answer in the question of the receipt of the Windows shutdown
| > | > broadcast (and
| > | > | the answer may still lie there) I was never able to fix it,
and
| > other
| > | > things
| > | > | (the machine I'm using now) came to the fore. Unfortunately,
I
| > only
| > | > | archived a few of the posts, and I was using the MS support
| > interface
| > | > at the
| > | > | time. The server doesn't seem to have retained any posts
prior to
| > the
| > | > | beginning of May, so I can't find the thread there, and it
| > probably
| > | > wouldn't
| > | > | do much good, since I doubt I could convince anyone that the
two
| > are
| > | > | related. Would take even longer to explain why I think so,
and
| > it's
| > | > | irrelevant, if the thread's not available.
| > | > | Obviously, this rambling reflects the state of my
| > understanding,
| > | > but it
| > | > | comes down to: If PM can see the disks and the partitions,
(1)
| > why
| > | > can't a
| > | > | boot disk see any of them, and (2) how does one access
anything on
| > the
| > | > disk
| > | > | if the boot disk can't see it. Along the way, I might mention
| > that
| > | > this is
| > | > | an installation without any older DOS on it, so that it would
be
| > | > deadly to
| > | > | overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files
would
| > have
| > | > to
| > | > | come off the W98SE installation disk, and that's a little
| > difficult as
| > | > it
| > | > | stands. I certainly don't want to reformat the disk.
| > | > |
| > | > | Thanks,
| > | > | Joe
| > | > | "PCR" > wrote in message
| > | > | ...
| > | > | >
| > | >
| >
http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
| > | > | > Err Msg: The Following File Is Missing or Corrupt...
| > | > | > (187641) - When you start your computer, you may receive the
| > | > following
| > | > | > error message: The following file is missing or corrupt:
| > | > COMMAND.COM.
| > | > | > Type the name of the Command Interpreter.
| > | > | >
| > | > | > It says...
| > | > | > ......Quote article...................
| > | > | > RESOLUTION
| > | > | > To resolve this problem, use the MS-DOS 6.x Upgrade Setup
Disk 1
| > to
| > | > | > restart your computer, and then use the SYS command on drive
C.
| > To
| > | > do
| > | > | > so, follow these steps:
| > | > | >
| > | > | > 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and
| > then
| > | > | > restart your computer.
| > | > | > 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS
| > Setup.
| > | > | > 3. Type sys c:, and then press ENTER.
| > | > | > 4. Restart your computer.
| > | > | > ......End of quote....................
| > | > | >
| > | > | > HOWEVER... here are some warnings...
| > | > | >
| > | > | > This will copy certain system files (IO.sys, Command.com &
| > perhaps
| > | > | > MSDOS.sys) from the Startup Diskette to C:\. (It also sets
the
| > BPB
| > | > drive
| > | > | > number to HD0, so that it is now in the bootstrap. It does
so,
| > no
| > | > matter
| > | > | > whether it is HD0. To boot it, one must still move it to be
HD0,
| > | > | > however.) You may now be able to boot to Windows, if all
folders
| > are
| > | > | > intact. If not, some further adjustment need be done to
| > "MSDOS.sys",
| > | > | > that was copied to C:\. The floppy has just a shell of it.
Well,
| > | > remove
| > | > | > the floppy & boot.
| > | > | >
| > | > | > Oh gosh! Here are some warnings from Jeff Richards, MS MVP
| > W95/W98,
| > | > | > about "SYS C:". DON'T DO IT, he says, if:
| > | > | >
| > | > | > (a) "Major errors were reported in Scandisk."
| > | > | > (b) "A drive is moved from one machine to another", because
of
| > the
| > | > next
| > | > | > two, maybe.
| > | > | > (c) "The BIOS setting for a drive is changed (eg, LBA to
| > LARGE)."
| > | > | > (d) "A drive that uses overlay software is operated without
the
| > | > overlay
| > | > | > loaded."
| > | > | >
| > | > | >
| > | > | > --
| > | > | > Thanks or Good Luck,
| > | > | > There may be humor in this post, and,
| > | > | > Naturally, you will not sue,
| > | > | > should things get worse after this,
| > | > | > PCR
| > | > | >
| > | > | > "jt3" > wrote in message
| > | > | > ...
| > | > | > | Yes that was what I was recalling something about--as
I
| > said
| > | > to
| > | > | > Curt,
| > | > | > | all my refs went down with that machine.
| > | > | > | The problem here is that this is wierd--it's clear
that
| > the
| > | > boot
| > | > | > code
| > | > | > | is working to some degree--'Starting Windows 98' comes up
| > first,
| > | > which
| > | > | > it
| > | > | > | normally wouldn't show, then it comes up with 'Type the
name
| > of
| > | > the
| > | > | > Command
| > | > | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even
| > though
| > | > | > there's no
| > | > | > | disk, boot or otherwise in the floppy drive. Also,
putting in
| > the
| > | > | > startup
| > | > | > | disk doesn't get me anywhere--after choosing boot without
| > cd-rom,
| > | > to
| > | > | > | simplify it, it just hangs with the floppy drive trying to
| > access
| > | > | > something.
| > | > | > | But it seems that this must be coming from IO.SYS, since
there
| > | > | > couldn't be
| > | > | > | much else doing it, if no COMMAND.COM has been loaded (of
| > | > course..who
| > | > | > | knows..).
| > | > | > | I should mention that this started with an *apparent*
CMOS
| > | > | > failure--a
| > | > | > | little strange since I just replaced it with a new Li cell
| > just a
| > | > year
| > | > | > and a
| > | > | > | month ago. Nothing very strange seemed to have happened
to
| > it,
| > | > except
| > | > | > all
| > | > | > | the drives (floppies, too) had been lost, and this was on
the
| > | > first
| > | > | > boot of
| > | > | > | the day.
| > | > | > | I reset the boot order for it to boot A: first (had
been
| > C:
| > | > then
| > | > | > A:) and
| > | > | > | was able then to boot to DOS from the startup disk, but
could
| > not
| > | > see
| > | > | > the
| > | > | > | other drives (just A:). I had previously installed an old
| > version
| > | > | > (4.0) of
| > | > | > | Partition Magic and used the PM recovery disk to find out
that
| > the
| > | > | > | partitions were all still there--but this version doesn't
do
| > | > anything
| > | > | > for
| > | > | > | MBRs, apparently.
| > | > | > | In short, the EOS byte could easily be missing, AFAIK,
and
| > the
| > | > | > only
| > | > | > | thing I can see at the moment is to use Debug to see if
it's
| > still
| > | > | > there.
| > | > | > | Clearly, I would welcome any thoughts on the subject
| > before I
| > | > try
| > | > | > | anything. I'm a little leery of slaving the disk to my
other
| > | > machine,
| > | > | > if I
| > | > | > | don't know for sure what caused the problem.
| > | > | > |
| > | > | > | Thanks for your time,
| > | > | > | Joe
| > | > | > | "PCR" > wrote in message
| > | > | > | ...
| > | > | > | > Enter "FDISK /MBR"
| > | > | > | > This will rewrite the code portion of the Master
Boot
| > | > Record,
| > | > | > | > leaving the Partition Table untouched, except it may
muss
| > the
| > | > | > partition
| > | > | > | > table, if there is a missing End-Of-Sector marker
(55AA),
| > per
| > | > | > | > http://support.microsoft.com/?kbid=149877
| > | > | > | > Boot Record Signature AA55 Not Found
| > | > | > | >
| > | > | > | > Here are the warnings against it...
| > | > | > | >
| > | > | > | > (a) If you have a boot sector virus, you may lose access
to
| > all
| > | > | > | > partitions. Then
| > | > | > | > http://www.terabyteunlimited.com/utilities.html MBRWork
| > "might"
| > | > help
| > | > | > to
| > | > | > | > recover them.
| > | > | > | >
| > | > | > | > (b) If you have "overlay" code in the MBR, e.g.,
EZ-BIOS,
| > | > Maxblast,
| > | > | > a
| > | > | > | > boot manager, then that will need to be reestablished
| > | > afterwards.
| > | > | > | > http://www.aefdisk.com/ FDISK & Boot Manager
| > | > | > | >
| > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
| > | > | > Overlay
| > | > | > | > Utility & FDISK
| > | > | > | >
| > | > | > | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
| > | > | > | >
| > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
| > | > | > | > Latest FDISK, hoping this one doesn't have any bugs.
(But it
| > | > doesn't
| > | > | > | > solve the 55AA thing.)
| > | > | > | >
| > | > | > | > (d) If for some reason the "geometry" setting in BIOS
does
| > not
| > | > match
| > | > | > the
| > | > | > | > hard drive, then any write to the drive may be
destructive.
| > So,
| > | > go
| > | > | > into
| > | > | > | > BIOS and have it "automatically detect" the proper
setting.
| > (If
| > | > you
| > | > | > can
| > | > | > | > DIR the drive in DOS, then you have proven the geometry
is
| > | > right.
| > | > | > Well,
| > | > | > | > Blanton says even that may not be true.)
| > | > | > | >
| > | > | > | >
| > | > | > | > --
| > | > | > | > Thanks or Good Luck,
| > | > | > | > There may be humor in this post, and,
| > | > | > | > Naturally, you will not sue,
| > | > | > | > should things get worse after this,
| > | > | > | > PCR
| > | > | > | >
| > | > | > | > "jt3" > wrote in message
| > | > | > | > ...
| > | > | > | > | I think I recall reading someone posting that the
/MBR
| > | > switch
| > | > | > on
| > | > | > | > FDISK
| > | > | > | > | not only rewrites the master boot record, but also
wipes
| > out
| > | > | > partition
| > | > | > | > table
| > | > | > | > | data, so that if you use /MBR on a disk with multiple
| > | > partitions
| > | > | > on
| > | > | > | > it, you
| > | > | > | > | lose the partition data. Is this true?
| > | > | > | > | I have a problem with a corrupted MBR (I think)
and my
| > old
| > | > | > version
| > | > | > | > of
| > | > | > | > | Partition Magic doesn't do the MBR, apparently.
| > | > | > | > | Thanks for your time, as always,
| > | > | > | > | Joe
| > | > | > | > |
| > | > | > | > |
| > | > | > | >
| > | > | > | >
| > | > | > |
| > | > | > |
| > | > | >
| > | > | >
| > | > |
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| > |
| >
| >
|
|
|
|

Bill Blanton
June 7th 04, 03:28 PM
Even if IO.SYS is missing you would still be able to see the
drive when booting from A:. And if you can't see the drive anyway,
a SYS or COPY isn't going to work. But again, I wouldn't try to write to
the drive until you determine what the problem is. (btw. You do
want to use an OS compatible boot disk. If you don't happen to
have a good one go to bootdisk.com)

How does the card define the disks? In terms of CHS? "Auto"?

As far as reading partinfo's output, just load edit. Switch floppys
and open the file. When you get ready to exit edit, switch 'em back.



"jt3" > wrote in message ...
> Bill,
> I believe that the 'Partition Info' button on the DOS version of PM4.0
> that I have on those recovery disks calls up partinfo.exe and that is why I
> was told to put in the second disk of the set, which has partinfo.exe on it;
> anyhow, that was what I did at the time, and, so far as I could tell with my
> brief look at it, it all looked pretty much as I recalled having set it up.
> Both drives, tho of course, it has been a while since I did it.
> I can do it again but will have to rig up an editor as well as change
> the config files that run it from the floppy so that I can get the info that
> way. As I said in my last post to PCR, I am pretty sure it's calling that
> string out of IO.SYS, which makes me, for the reasons I stated in that post,
> think that the problem lies in IO.SYS, but if so, it's rather strange
> corruption, sort of the single bit type, rather than the usual sort where
> something gets written over.
> This computer also runs SE, so there wouldn't be the problem of System
> Restore running.
> I may run your debug script (thanks) to dump the first sector, though I
> suspect that the MBR is probably OK, as I said in the previous post, since
> it didn't go too far astray to get to IO.SYS.
> Finally, I *think* that a sys.com from the boot floppy ought to replace
> IO.SYS on the C drive, but I'm not all that sure I know which floppy I'd
> trust the most, and I'm also not sure that all IO.SYSes are the same, i.e.,
> from machine to machine, and especially from instance to instance of SE. I
> *assume* that all the machine-specific modification is done in the building
> of VMM in windows, but it strikes me as possible that some differences could
> exist as a result of installation on different machines--I really don't
> know, though I'd guess, again, that they're all the same. Some early
> versions of DOS had differences, but that was some time ago.
> Got to turn in, been burning too much late oil, tackle the problem later
> and get back to you as soon as I have something of any interest.
>
> Thanks for all your time and thought on the matter,
> Joe.
> "Bill Blanton" > wrote in message
> ...
> > A fact is that PM doesn't have to mount the volume, only define the
> > various partitions according to the table(s) information. Win/DOS otoh
> > has to define the partition structure and then define the OS specific
> > volumes using the boot sectors' information. And of course, furthur
> > along it will have to decode the Dir structure and FAT, but corruption
> > there would probably just show corrupt files, or "file not found".
> > You should still get a "C:" in that case (if the boot sector was sane).
> >
> > Simply put, PM doesn't have to worry if a partition's content is
> > corrupt, only that it exists.
> >
> > What's strange is that you get the "Starting Win 98..." message when
> > you boot from HD0. This suggests that the volume was properly mounted
> > and at least started to boot.
> >
> > I don't really know, but I would suspect a slightly off geomtry
> > (except PM apparently isn't having a problem), or a bad boot sector
> > (except you wouldn't expect IO.SYS to be started, and you wouldn't
> > expect both drives to become corrupt).
> >
> > I don't really think it's the MBR, or the tables, or the ending sig,
> > since the partitions look good to PM and a HD boot is at least loading
> > IO.SYS.
> >
> > Until you figure it out you don't want to attempt any writes to the
> > disks. Including fdisk/mbr. You shouldn't have any problem hooking the
> > drive up as a slave even with an active partition on the disk, but be
> > aware that if you hook it up to a system that has System Restore
> > enabled (such as ME or XP), the system will attempt to write SR
> > data to the disk. That could be bad if the geometry is skewd.
> >
> >
> > At this point, I would run PM's partinfo util and see what it has to
> > say. You'll find it on the CD in the \UTILITY directory. At the prompt
> > run
> > partinfo > partinfo.txt
> > and then open partinfo in a text editor. If you want you can mail it
> > to me at billblanton<At>earthlink<dot>net Partinfo also displays boot
> > sector information, so mabey something obvious will turn up. It might
> > also point to geometry conflict between the disk and the card's BIOS.
> >
> > As I said before I don't think it's the MBR, but if you want to look
> > you can run this debug script to dump HD0's 1st sector. Save as
> > "dump.scr" (or whatever) and run
> > debug < dump.scr > dump.txt
> > Then open dump.txt in edit to check the ending sig bytes.
> >
> > rip
> > 0300
> > a 0300
> > mov al,1
> > mov ch,0
> > mov cl,1
> > mov dh,0
> > mov dl,80
> > push ds
> > pop es
> > xor bx,bx
> > mov ah,2
> > int 13
> >
> > g 312
> >
> > d es:0000 L200
> >
> > q
> > (make sure there is a cr/lf after "q", or it will lock)
> >
> >
> >
> >
> > "jt3" > wrote in message
> ...
> > > I actually tried three different boot disks I have, all for W98SE,
> two
> > > made on that machine, and one on this. They all did the same thing, and
> > > although I haven't tried them on this one lately, I suspect that it
> would
> > > net nothing new. The drives don't have any esoteric type of partitions
> on
> > > them, just standard DOS primary and extended on the 80 drive, FAT 32,
> the C
> > > partition about 750 MB and the E partition is the balance of the 8 GB
> > > Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> > > partitioned into 4 partitions, 1 primary, 3 in the extended.
> > > At one time, I was using a WD Caviar 850 MB as the C drive, and I
> had
> > > W95SR2.1 on it, with the Quantum providing the same as it provides now.
> > > When this happened once before, about 4 years ago, after much thrashing
> > > about I gave up finally, not knowing about the newsgroup as a resource,
> and
> > > bought the Seagate to replace the WD, installed W98SE, and when not only
> > > everything seemed to work, but I had less trouble installing and setting
> up
> > > than in any of the previous installs, I thought I had made a fortunate,
> > > move, however blindly.
> > > Now I should mention that which was discussed ad nauseam in the
> > > 'Restart...' thread, namely that the hardware is built on an Eteq mbd,
> VL
> > > bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller, which
> has
> > > its own BIOS, enabling it to do several things not particularly germane
> to
> > > the problem, except for the fact that it allows me to use a drive as
> large
> > > as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> > > Thus, for the previous setup in which I used just the WD and Quantum
> > > (same partns), the partitions for the WD were C and E (using FAT16 and
> > > trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for
> the
> > > disk setup. Now it's been some while ago, but as memory serves, it was
> a
> > > *very* similar sort of failure, made worse by some other complications
> that
> > > I would rather not go into here. I wouldn't stake my life on it being
> the
> > > same, but I have my suspicions.
> > > Anyhow, when I went to use the Seagate, it wouldn't handle it--make
> a
> > > long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> > > controller BIOS, I discovered, could handle it, so that caused me to
> start
> > > using it. This requires, as you may expect, not setting it in the mbd
> BIOS,
> > > and activating the Promise BIOS which is done through an on-board
> program,
> > > and everything came up roses.
> > > Now, this time when things went south, the Promise BIOS program
> still
> > > had all the correct parameters in it, and I should mention that it is
> all
> > > automated, and so there isn't much possiblity of getting it messed up.
> The
> > > fact that the PM reading of the partitions came up with all the right
> data,
> > > suggests that the problem is not with the hard drive, controller, or any
> > > such thing. Since it must still be operating with IO.SYS, it's my bet
> that
> > > there's something rotten there, but I don't see how to get to it, short
> of
> > > trying to slave it to another machine.
> > > My reluctance there is based on the fact that I didn't have firewall
> > > protection on that machine, and since I have started perforce using this
> one
> > > (which has the EZ-Armor on it) I have been astounded by the number of
> times
> > > it has blocked some sort of invasion (not all of which are ISP pings).
> This
> > > makes me a little less secure in any assumptions regarding what caused
> all
> > > this. If I slave it to this machine, I suppose it should be secure
> enough
> > > until I attempt to access something on it. Question is, does simply
> reading
> > > the FAT pose a risk? If not, I could do a scan of the drive, once this
> > > machine booted. I'd still have the question of the MBR, but I expect I
> > > could look at it with Debug (if I can find it) and see of the EOS byte
> is
> > > there. I'd have to deactivate the primary partition, I guess. What
> happens
> > > if you have a slaved disk which also has a prmary active partition?
> Surely
> > > DOS 7 wouldn't like that.
> > >
> >
> >
>
>

jt3
June 16th 04, 08:39 PM
Hi Bill,

Don't know if you're still monitoring this thread, but I haven't dropped
the problem, it's just that I'm also having trouble with EZArmor on the AMD
machine (another thread), and since that threatens to put me off-line
altogether, I've been devoting more time to it. But I did pursue the
problem a little along the lines of your suggestion. I don't know why PM
had wanted me to insert the second disk of the recovery set. I had thought
that the main routine (it's a DOS app, though not command-line) on the first
floppy simply called the second when I clicked on the 'Partition Info' tab,
but now I don't know what the skinny on that is, because, when I tried it
again, it didn't ask for the second disk, and when I checked the contents of
the floppies, most everything is on the first, with mainly PARTINFO.EXE on
the second. I'll give you the output of PM with regards to disk geometry in
a moment, but what I found was that the version of PARTINFO on this vers. 4
is apparently only good through FAT16, even though PM itself handles FAT32
completely, including conversions, etc.
I then tried TeraByte's freebie PARTINFO and found it wouldn't run from
a floppy--apparently has to be on the disk being checked. I'm pursuing
other possibilities for that, but the disk geometry, so far as PM reports it
is 1,023 cyls, 255 hds, 63 sects, no big surprize; it lists the partition
type as 0Bh, FAT32, gives serial #, first physical sector: 63 (cyl 0, hd1,
sect 1), last physical sector: 63 (cyl101, hd254, sect63); total physical
sectors 1,638,567 (800.1 MB), which is how the disk is partitioned: 800.1
MB in C: and 7224.5MB in the extended partn, containing just one vol: E:
also FAT32. The other drive, the 2G Quantum is partitioned into one primary
and 3 vols. in an extended, all FAT16.
I don't expect you were interested in the bytes free, used, wasted,
cluster size, etc., but it all looks just fine to me. What's so strange is
how PM manages to access the disk using standard BIOS functions (I have the
disk out, all breadboarded up, and can see the active disk light on the
drive chassis, while IO.SYS seems totally unable to. I still can't see how
it could be anything but IO.SYS being corrupted but it's such a strange sort
of corruption, unless there's more of it waiting to be discovered.
I had that happen once--it was an application that 'shotgunned' the
whole disk, and though I salvaged files from it, I never trusted anything
from it again. In that case I had obvious signs of what happened when it
initially malfunctioned; it was just that I thought I had cleaned it up, and
found it to be too pervasive to do anything but start fresh. This case
didn't seem like that--being just fine one day and refusing to boot the
next.
I will pursue the other apps and get back to you.

Thanks,
Joe
"jt3" > wrote in message
...
> Bill,
> I believe that the 'Partition Info' button on the DOS version of PM4.0
> that I have on those recovery disks calls up partinfo.exe and that is why
I
> was told to put in the second disk of the set, which has partinfo.exe on
it;
> anyhow, that was what I did at the time, and, so far as I could tell with
my
> brief look at it, it all looked pretty much as I recalled having set it
up.
> Both drives, tho of course, it has been a while since I did it.
> I can do it again but will have to rig up an editor as well as change
> the config files that run it from the floppy so that I can get the info
that
> way. As I said in my last post to PCR, I am pretty sure it's calling that
> string out of IO.SYS, which makes me, for the reasons I stated in that
post,
> think that the problem lies in IO.SYS, but if so, it's rather strange
> corruption, sort of the single bit type, rather than the usual sort where
> something gets written over.
> This computer also runs SE, so there wouldn't be the problem of System
> Restore running.
> I may run your debug script (thanks) to dump the first sector, though
I
> suspect that the MBR is probably OK, as I said in the previous post, since
> it didn't go too far astray to get to IO.SYS.
> Finally, I *think* that a sys.com from the boot floppy ought to
replace
> IO.SYS on the C drive, but I'm not all that sure I know which floppy I'd
> trust the most, and I'm also not sure that all IO.SYSes are the same,
i.e.,
> from machine to machine, and especially from instance to instance of SE.
I
> *assume* that all the machine-specific modification is done in the
building
> of VMM in windows, but it strikes me as possible that some differences
could
> exist as a result of installation on different machines--I really don't
> know, though I'd guess, again, that they're all the same. Some early
> versions of DOS had differences, but that was some time ago.
> Got to turn in, been burning too much late oil, tackle the problem
later
> and get back to you as soon as I have something of any interest.
>
> Thanks for all your time and thought on the matter,
> Joe.
> "Bill Blanton" > wrote in message
> ...
> > A fact is that PM doesn't have to mount the volume, only define the
> > various partitions according to the table(s) information. Win/DOS otoh
> > has to define the partition structure and then define the OS specific
> > volumes using the boot sectors' information. And of course, furthur
> > along it will have to decode the Dir structure and FAT, but corruption
> > there would probably just show corrupt files, or "file not found".
> > You should still get a "C:" in that case (if the boot sector was sane).
> >
> > Simply put, PM doesn't have to worry if a partition's content is
> > corrupt, only that it exists.
> >
> > What's strange is that you get the "Starting Win 98..." message when
> > you boot from HD0. This suggests that the volume was properly mounted
> > and at least started to boot.
> >
> > I don't really know, but I would suspect a slightly off geomtry
> > (except PM apparently isn't having a problem), or a bad boot sector
> > (except you wouldn't expect IO.SYS to be started, and you wouldn't
> > expect both drives to become corrupt).
> >
> > I don't really think it's the MBR, or the tables, or the ending sig,
> > since the partitions look good to PM and a HD boot is at least loading
> > IO.SYS.
> >
> > Until you figure it out you don't want to attempt any writes to the
> > disks. Including fdisk/mbr. You shouldn't have any problem hooking the
> > drive up as a slave even with an active partition on the disk, but be
> > aware that if you hook it up to a system that has System Restore
> > enabled (such as ME or XP), the system will attempt to write SR
> > data to the disk. That could be bad if the geometry is skewd.
> >
> >
> > At this point, I would run PM's partinfo util and see what it has to
> > say. You'll find it on the CD in the \UTILITY directory. At the prompt
> > run
> > partinfo > partinfo.txt
> > and then open partinfo in a text editor. If you want you can mail it
> > to me at billblanton<At>earthlink<dot>net Partinfo also displays boot
> > sector information, so mabey something obvious will turn up. It might
> > also point to geometry conflict between the disk and the card's BIOS.
> >
> > As I said before I don't think it's the MBR, but if you want to look
> > you can run this debug script to dump HD0's 1st sector. Save as
> > "dump.scr" (or whatever) and run
> > debug < dump.scr > dump.txt
> > Then open dump.txt in edit to check the ending sig bytes.
> >
> > rip
> > 0300
> > a 0300
> > mov al,1
> > mov ch,0
> > mov cl,1
> > mov dh,0
> > mov dl,80
> > push ds
> > pop es
> > xor bx,bx
> > mov ah,2
> > int 13
> >
> > g 312
> >
> > d es:0000 L200
> >
> > q
> > (make sure there is a cr/lf after "q", or it will lock)
> >
> >
> >
> >
> > "jt3" > wrote in message
> ...
> > > I actually tried three different boot disks I have, all for W98SE,
> two
> > > made on that machine, and one on this. They all did the same thing,
and
> > > although I haven't tried them on this one lately, I suspect that it
> would
> > > net nothing new. The drives don't have any esoteric type of
partitions
> on
> > > them, just standard DOS primary and extended on the 80 drive, FAT 32,
> the C
> > > partition about 750 MB and the E partition is the balance of the 8 GB
> > > Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> > > partitioned into 4 partitions, 1 primary, 3 in the extended.
> > > At one time, I was using a WD Caviar 850 MB as the C drive, and I
> had
> > > W95SR2.1 on it, with the Quantum providing the same as it provides
now.
> > > When this happened once before, about 4 years ago, after much
thrashing
> > > about I gave up finally, not knowing about the newsgroup as a
resource,
> and
> > > bought the Seagate to replace the WD, installed W98SE, and when not
only
> > > everything seemed to work, but I had less trouble installing and
setting
> up
> > > than in any of the previous installs, I thought I had made a
fortunate,
> > > move, however blindly.
> > > Now I should mention that which was discussed ad nauseam in the
> > > 'Restart...' thread, namely that the hardware is built on an Eteq mbd,
> VL
> > > bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller,
which
> has
> > > its own BIOS, enabling it to do several things not particularly
germane
> to
> > > the problem, except for the fact that it allows me to use a drive as
> large
> > > as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> > > Thus, for the previous setup in which I used just the WD and
Quantum
> > > (same partns), the partitions for the WD were C and E (using FAT16 and
> > > trying to avoid cluster size inefficiencies) I used the *mbd BIOS* for
> the
> > > disk setup. Now it's been some while ago, but as memory serves, it
was
> a
> > > *very* similar sort of failure, made worse by some other complications
> that
> > > I would rather not go into here. I wouldn't stake my life on it being
> the
> > > same, but I have my suspicions.
> > > Anyhow, when I went to use the Seagate, it wouldn't handle
it--make
> a
> > > long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> > > controller BIOS, I discovered, could handle it, so that caused me to
> start
> > > using it. This requires, as you may expect, not setting it in the mbd
> BIOS,
> > > and activating the Promise BIOS which is done through an on-board
> program,
> > > and everything came up roses.
> > > Now, this time when things went south, the Promise BIOS program
> still
> > > had all the correct parameters in it, and I should mention that it is
> all
> > > automated, and so there isn't much possiblity of getting it messed up.
> The
> > > fact that the PM reading of the partitions came up with all the right
> data,
> > > suggests that the problem is not with the hard drive, controller, or
any
> > > such thing. Since it must still be operating with IO.SYS, it's my bet
> that
> > > there's something rotten there, but I don't see how to get to it,
short
> of
> > > trying to slave it to another machine.
> > > My reluctance there is based on the fact that I didn't have
firewall
> > > protection on that machine, and since I have started perforce using
this
> one
> > > (which has the EZ-Armor on it) I have been astounded by the number of
> times
> > > it has blocked some sort of invasion (not all of which are ISP pings).
> This
> > > makes me a little less secure in any assumptions regarding what caused
> all
> > > this. If I slave it to this machine, I suppose it should be secure
> enough
> > > until I attempt to access something on it. Question is, does simply
> reading
> > > the FAT pose a risk? If not, I could do a scan of the drive, once
this
> > > machine booted. I'd still have the question of the MBR, but I expect
I
> > > could look at it with Debug (if I can find it) and see of the EOS byte
> is
> > > there. I'd have to deactivate the primary partition, I guess. What
> happens
> > > if you have a slaved disk which also has a prmary active partition?
> Surely
> > > DOS 7 wouldn't like that.
> > >
> >
> >
>
>

jt3
June 16th 04, 10:38 PM
PCR,
Sorry if I didn't reply--I don't know why, but your post never showed in my
headers until today. For the record--never used the Maxtor overlay.
Thanks,
Joe
"PCR" > wrote in message
...
> I see you never did install WD's EZ-BIOS, unless it were four years ago
> in a different event. I'm still thinking the failure to boot from a
> floppy can have to do with the Maxtor BIOS, though. The floppy will not
> go through the HDD's MBR, which may now be Maxtor specific. Not going
> that way, the floppy cannot see the geometry change. But that is only a
> guess on my part. Why does PM work? Perhaps it knows more than the
> floppy. Or it could be as Blanton said: it doesn't need to do as much.
> It could be the floppy only has access to the motherboard BIOS. But this
> is all theoretical.
>
> The error message you get when booting the HDD is...
>
> | is working to some degree--'Starting Windows 98' comes up first, which
> it
> | normally wouldn't show, then it comes up with 'Type the name of the
> Command
> | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
> there's no
> | disk, boot or otherwise in the floppy drive.
>
> ...which does sound like that article I posted, which calls for a "SYS
> C:". But I suppose you'd better send that PM PartInfo to Blanton,
> first. Don't forget all those warnings about SYS C:.
>
> Where is that URL he posted that showed native Windows MBR code? No
> matter. I suppose the message is coming out of IO.sys, not that code.
> I'm still here, but better deal with Blanton first.
>
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> should things get worse after this,
> PCR
>
> "jt3" > wrote in message
> ...
> | *Never* installed *any* disk overlay software on this or any other
> | machine. These hds were blank when I installed them. This is a
> machine I
> | built from scratch some years ago (1995, to be more precise) and I
> know all
> | the stuff that ever went into it.
> | Not sure if you took the output string as proof of the existence
> of a
> | drive overlay. PM refers to Partition Magic, version 4.0, which I
> used to
> | check and see if the drives and partitions were still as they should
> be.
> | All I did with it is 'look'--I made no changes
> | with PM.
> | As it happens the Quantum Bigfoot predates their acquisition by
> Maxtor
> | (so it may have been more than 4 years ago that the earlier problem
> | occurred--when you get to my age time seems to pass a good deal faster
> than
> | it once did). There was some disk overlay program offered by Quantum
> at the
> | time, I think it was OnTrack, which I read is the basis for MaxBlast,
> and I
> | *do* have a Maxtor on the FIC K6 machine I'm using at the moment, but
> I have
> | always avoided overlay programs because they are so problematic when
> using
> | any kind of disk software. So it is fairly certain that there is no
> Maxtor
> | or WD,
> | or any other hd mfgr proprietary disk overlay program on either disk;
> if one
> | got there, it had to have been put there by the Promise BIOS, and
> don't
> | think that likely.
> | I must admit, however, that the Promise adapter is supposed to
> support
> | *four* IDE hds on the primary channel, in addition to providing the
> | secondary channel for use with CD-R/OM/RWs (two max).
> | As it happens I was not using it that way, though I once tried it
> and
> | found that it worked pretty much as they said. I have no idea how
> they
> | achieve this, and they gave no clue in the documentation, but since
> ATA is
> | fairly close to SCSI, they must all be daisy chained together in a
> similar
> | manner; all SCSI cards I know of (including the one on this machine)
> use
> | onboard BIOSes to do this, and I never heard of one surreptitiously
> | installing a disk overlay.
> | The documentation instructs the user to use Promise's version of
> FDISK,
> | which sounds suspicious, but in fact when I tried using the extra disk
> | drive, I *did_not* use their FDISK version to format the disk (for
> several
> | reasons), and in fact just hooked up three previously formatted and
> occupied
> | disks; for the short space of time that I tried using it that way
> (about
> | three months) it gave no particular trouble (other than that detailed
> | below), but I cannot say that the previously mentioned crash of about
> 4
> | years ago was totally independent (since that wipe-out happened only a
> few
> | months later)-- but I don't think so. The problems then seemed more
> to
> | result from the use of the WD drive (I had another just like it) and
> | disappeared when I took the WDs off. Since they were so small (856M),
> I
> | stayed with the Quantum. This was because I found Promise docs online
> which
> | said to beware of WD drives, as they often wouldn't work right with
> it,
> | especially when used with another brand of disk. I've not experienced
> any
> | similar problems with the Seagate and the Quantum together, however.
> | Please note:
> | (1) The Seagate (8 GB) FAT32 is partitioned to C and E, the
> Quantum
> | (2GB) is FAT16 partitioned to D, F, G, and H. Neither has any disk
> overlay
> | applied--I used FDISK straight from the box to set them up. The fact
> that
> | the string output when trying to change to C: is that given in KB
> 245162
> | doesn't tell me that it necessarily has a disk overlay (except as
> mentioned
> | in the caveat above, and I have used a boot disk before without
> problem,
> | though it was, it's true, on W95SR2.1) and the rest of the
> symptomatology
> | suggests that there's more than a disk overlay in the works.
> | (2) The message displayed on the screen when one attempts to boot
> the
> | machine (without boot disk) is letter perfect out of IO.SYS, in the
> literals
> | near the 'Starting Windows 98' string (which normally never appears,
> but
> | *does* in this case). This of course only means that IO.SYS is
> executing in
> | some way, if not the correct one.
> | (3) (2) implies that it got out of the MBR, though not necessarily
> in
> | the correct fashion, but it *doesn't* imply that the EOS byte is
> there.
> | Probably, but not with any certainty. Since IO.SYS no longer has to
> reside
> | first on the disk, and since there is a partition table between we can
> | assume that it got there by some kind of jump, I think.
> | Thus if I acted on a pure guess, it seems fairly likely that the
> MBR is
> | probably still OK, and it's IO.SYS that's most likely in need of aid.
> | Trouble is, I don't have a lot of confidence in this--way too much I
> don't
> | know anything about here..
> | (4) KB149877 says that it applies to Win2K, NT(various flavors),
> WfW,
> | and W95, but *doesn't* mention W98 or SE or ME. The fact that it
> skips
> | right over W98 and ME causes me a little concern when strictly
> interpreting
> | some of it's suggestions, viz. using FDISK/mbr and partition table
> info
> | safety.
> |
> | All in all, I'm still nowhere, and hope you or someone else can
> point a
> | way that looks a little less hazardous.
> |
> | Thanks for your time and effort,
> | Joe
> | "PCR" > wrote in message
> | ...
> | > (1) I guess the Startup Diskettes are OK, except for one
> possibility. If
> | > EZ-BIOS or such has been installed to an HDD, then it must (a) also
> be
> | > installed to the floppy, or (b) present an option during boot to
> boot
> | > the floppy. Otherwise, a floppy will fail to read the HDD. This is
> | > because EZ-BIOS (or the Maxtor equivalent) has altered the HDD
> | > "geometry".
> | >
> | > (2) I don't know how you could check it (not able to boot to DOS),
> but
> | > each HDD must have one & only one partition marked as Active. (That
> is
> | > unless your Maxtor BIOS gets around it somehow.) Otherwise, you
> cannot
> | > boot.
> | >
> | > (3) I don't know what could happen, if you are mixing WD's EZ-BIOS
> with
> | > Maxtor's equivalent.
> | >
> | > (4)
> | > | this. If I slave it to this machine, I suppose it should be
> secure
> | > enough
> | > | until I attempt to access something on it. Question is, does
> simply
> | > reading
> | > | the FAT pose a risk? If not, I could do a scan of the drive, once
> | > this
> | >
> | > I'm not sure of the risks. I know when EZ-BIOS or such is installed
> to
> | > an HDD, it gets into the MBR. Therefore, moving the HDD to another
> | > machine brings it along. HOWEVER, it that all there is to it? I thin
> k
> | > not in the case of Maxtor anyway, which got into the BIOS. Moving an
> HDD
> | > in that case leaves the BIOS behind. So, how can one get the
> "geometry"
> | > right?
> | >
> | >
> | > --
> | > Thanks or Good Luck,
> | > There may be humor in this post, and,
> | > Naturally, you will not sue,
> | > should things get worse after this,
> | > PCR
> | >
> | > "jt3" > wrote in message
> | > ...
> | > | I actually tried three different boot disks I have, all for
> W98SE,
> | > two
> | > | made on that machine, and one on this. They all did the same
> thing,
> | > and
> | > | although I haven't tried them on this one lately, I suspect that
> it
> | > would
> | > | net nothing new. The drives don't have any esoteric type of
> | > partitions on
> | > | them, just standard DOS primary and extended on the 80 drive, FAT
> 32,
> | > the C
> | > | partition about 750 MB and the E partition is the balance of the 8
> GB
> | > | Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> | > | partitioned into 4 partitions, 1 primary, 3 in the extended.
> | > | At one time, I was using a WD Caviar 850 MB as the C drive,
> and I
> | > had
> | > | W95SR2.1 on it, with the Quantum providing the same as it provides
> | > now.
> | > | When this happened once before, about 4 years ago, after much
> | > thrashing
> | > | about I gave up finally, not knowing about the newsgroup as a
> | > resource, and
> | > | bought the Seagate to replace the WD, installed W98SE, and when
> not
> | > only
> | > | everything seemed to work, but I had less trouble installing and
> | > setting up
> | > | than in any of the previous installs, I thought I had made a
> | > fortunate,
> | > | move, however blindly.
> | > | Now I should mention that which was discussed ad nauseam in
> the
> | > | 'Restart...' thread, namely that the hardware is built on an Eteq
> mbd,
> | > VL
> | > | bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller,
> | > which has
> | > | its own BIOS, enabling it to do several things not particularly
> | > germane to
> | > | the problem, except for the fact that it allows me to use a drive
> as
> | > large
> | > | as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> | > | Thus, for the previous setup in which I used just the WD and
> | > Quantum
> | > | (same partns), the partitions for the WD were C and E (using FAT16
> and
> | > | trying to avoid cluster size inefficiencies) I used the *mbd BIOS*
> for
> | > the
> | > | disk setup. Now it's been some while ago, but as memory serves,
> it
> | > was a
> | > | *very* similar sort of failure, made worse by some other
> complications
> | > that
> | > | I would rather not go into here. I wouldn't stake my life on it
> being
> | > the
> | > | same, but I have my suspicions.
> | > | Anyhow, when I went to use the Seagate, it wouldn't handle
> | > it--make a
> | > | long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> | > | controller BIOS, I discovered, could handle it, so that caused me
> to
> | > start
> | > | using it. This requires, as you may expect, not setting it in the
> mbd
> | > BIOS,
> | > | and activating the Promise BIOS which is done through an on-board
> | > program,
> | > | and everything came up roses.
> | > | Now, this time when things went south, the Promise BIOS
> program
> | > still
> | > | had all the correct parameters in it, and I should mention that it
> is
> | > all
> | > | automated, and so there isn't much possiblity of getting it messed
> up.
> | > The
> | > | fact that the PM reading of the partitions came up with all the
> right
> | > data,
> | > | suggests that the problem is not with the hard drive, controller,
> or
> | > any
> | > | such thing. Since it must still be operating with IO.SYS, it's my
> bet
> | > that
> | > | there's something rotten there, but I don't see how to get to it,
> | > short of
> | > | trying to slave it to another machine.
> | > | My reluctance there is based on the fact that I didn't have
> | > firewall
> | > | protection on that machine, and since I have started perforce
> using
> | > this one
> | > | (which has the EZ-Armor on it) I have been astounded by the number
> of
> | > times
> | > | it has blocked some sort of invasion (not all of which are ISP
> pings).
> | > This
> | > | makes me a little less secure in any assumptions regarding what
> caused
> | > all
> | > | this. If I slave it to this machine, I suppose it should be
> secure
> | > enough
> | > | until I attempt to access something on it. Question is, does
> simply
> | > reading
> | > | the FAT pose a risk? If not, I could do a scan of the drive, once
> | > this
> | > | machine booted. I'd still have the question of the MBR, but I
> expect
> | > I
> | > | could look at it with Debug (if I can find it) and see of the EOS
> byte
> | > is
> | > | there. I'd have to deactivate the primary partition, I guess.
> What
> | > happens
> | > | if you have a slaved disk which also has a prmary active
> partition?
> | > Surely
> | > | DOS 7 wouldn't like that.
> | > |
> | > | Thanks again, I appreciate your efforts and advice,
> | > | Joe
> | > | "PCR" > wrote in message
> | > | ...
> | > | > Oops. I was too quick to post that quote of...
> | > | >
> | >
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> | > | > ...It wouldn't be a "MS-DOS 6.x Upgrade Setup Disk 1" for you,
> but
> | > JUST
> | > | > a regular Startup Diskette.
> | > | >
> | > | > (1) Perhaps yours is bad, if it will not see partitions. Then...
> | > | > Get a Startup Diskette from
> | > | > http://www.bootdisk.com/ , if you don't already have one from
> | > "Control
> | > | > Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
> | > | > Diskette. Boot it, put in a CD and "DIR" the CD. It will say
> which
> | > | > letter is the CD. (Otherwise, it is likely one letter higher
> than
> | > | > normal.)
> | > | >
> | > | > (2) Perhaps your partition are not the "type" that are
> recognizable
> | > by
> | > | > DOS. Then, you must wait for Blanton to arrive. (I still haven't
> | > | > assimilated it.) Does Partition Magic allow you to change the
> | > partition
> | > | > "type". NATURALLY, all one may safely do is to change it from a
> | > hidden
> | > | > type to it's proper unhidden form. One may NOT simply convert an
> | > NTFS to
> | > | > a FAT32, for example, by changing type!
> | > | >
> | > | >
> | > | > --
> | > | > Thanks or Good Luck,
> | > | > There may be humor in this post, and,
> | > | > Naturally, you will not sue,
> | > | > should things get worse after this,
> | > | > PCR
> | > | >
> | > | > "jt3" > wrote in message
> | > | > ...
> | > | > | That's what I was trying to say: although the PM
> 'Recovery
> | > Disk'
> | > | > | (mainly a
> | > | > | boot disk with PM on it) shows the partitions on both disks as
> | > present
> | > | > and
> | > | > | with no problems, the boot disk DOS can't see them--not even
> | > C:\--even
> | > | > | though if you don't use the boot disk, it's clearly using the
> C
> | > drive
> | > | > to get
> | > | > | the message: 'Type the name of the Command Interpreter....' as
> I
> | > | > described
> | > | > | previously.
> | > | > | I think this may go back to a thread back in April, or
> March,
> | > in
> | > | > which
> | > | > | you and cquirke and several other people got involved, but
> then it
> | > was
> | > | > a
> | > | > | question of Restarting in DOS Mode. Although I finally
> thought
> | > that I
> | > | > had
> | > | > | the
> | > | > | answer in the question of the receipt of the Windows shutdown
> | > | > broadcast (and
> | > | > | the answer may still lie there) I was never able to fix it,
> and
> | > other
> | > | > things
> | > | > | (the machine I'm using now) came to the fore. Unfortunately,
> I
> | > only
> | > | > | archived a few of the posts, and I was using the MS support
> | > interface
> | > | > at the
> | > | > | time. The server doesn't seem to have retained any posts
> prior to
> | > the
> | > | > | beginning of May, so I can't find the thread there, and it
> | > probably
> | > | > wouldn't
> | > | > | do much good, since I doubt I could convince anyone that the
> two
> | > are
> | > | > | related. Would take even longer to explain why I think so,
> and
> | > it's
> | > | > | irrelevant, if the thread's not available.
> | > | > | Obviously, this rambling reflects the state of my
> | > understanding,
> | > | > but it
> | > | > | comes down to: If PM can see the disks and the partitions,
> (1)
> | > why
> | > | > can't a
> | > | > | boot disk see any of them, and (2) how does one access
> anything on
> | > the
> | > | > disk
> | > | > | if the boot disk can't see it. Along the way, I might mention
> | > that
> | > | > this is
> | > | > | an installation without any older DOS on it, so that it would
> be
> | > | > deadly to
> | > | > | overwrite IO.SYS with a DOS 6.22 IO.SYS. Any of the files
> would
> | > have
> | > | > to
> | > | > | come off the W98SE installation disk, and that's a little
> | > difficult as
> | > | > it
> | > | > | stands. I certainly don't want to reformat the disk.
> | > | > |
> | > | > | Thanks,
> | > | > | Joe
> | > | > | "PCR" > wrote in message
> | > | > | ...
> | > | > | >
> | > | >
> | >
> http://support.microsoft.com/default.aspx?scid=kb;en-us;187641&Product=w98
> | > | > | > Err Msg: The Following File Is Missing or Corrupt...
> | > | > | > (187641) - When you start your computer, you may receive the
> | > | > following
> | > | > | > error message: The following file is missing or corrupt:
> | > | > COMMAND.COM.
> | > | > | > Type the name of the Command Interpreter.
> | > | > | >
> | > | > | > It says...
> | > | > | > ......Quote article...................
> | > | > | > RESOLUTION
> | > | > | > To resolve this problem, use the MS-DOS 6.x Upgrade Setup
> Disk 1
> | > to
> | > | > | > restart your computer, and then use the SYS command on drive
> C.
> | > To
> | > | > do
> | > | > | > so, follow these steps:
> | > | > | >
> | > | > | > 1. Place the MS-DOS 6.x Upgrade Setup Disk 1 in drive A, and
> | > then
> | > | > | > restart your computer.
> | > | > | > 2. Press the F3 key when MS-DOS Setup starts to exit MS-DOS
> | > Setup.
> | > | > | > 3. Type sys c:, and then press ENTER.
> | > | > | > 4. Restart your computer.
> | > | > | > ......End of quote....................
> | > | > | >
> | > | > | > HOWEVER... here are some warnings...
> | > | > | >
> | > | > | > This will copy certain system files (IO.sys, Command.com &
> | > perhaps
> | > | > | > MSDOS.sys) from the Startup Diskette to C:\. (It also sets
> the
> | > BPB
> | > | > drive
> | > | > | > number to HD0, so that it is now in the bootstrap. It does
> so,
> | > no
> | > | > matter
> | > | > | > whether it is HD0. To boot it, one must still move it to be
> HD0,
> | > | > | > however.) You may now be able to boot to Windows, if all
> folders
> | > are
> | > | > | > intact. If not, some further adjustment need be done to
> | > "MSDOS.sys",
> | > | > | > that was copied to C:\. The floppy has just a shell of it.
> Well,
> | > | > remove
> | > | > | > the floppy & boot.
> | > | > | >
> | > | > | > Oh gosh! Here are some warnings from Jeff Richards, MS MVP
> | > W95/W98,
> | > | > | > about "SYS C:". DON'T DO IT, he says, if:
> | > | > | >
> | > | > | > (a) "Major errors were reported in Scandisk."
> | > | > | > (b) "A drive is moved from one machine to another", because
> of
> | > the
> | > | > next
> | > | > | > two, maybe.
> | > | > | > (c) "The BIOS setting for a drive is changed (eg, LBA to
> | > LARGE)."
> | > | > | > (d) "A drive that uses overlay software is operated without
> the
> | > | > overlay
> | > | > | > loaded."
> | > | > | >
> | > | > | >
> | > | > | > --
> | > | > | > Thanks or Good Luck,
> | > | > | > There may be humor in this post, and,
> | > | > | > Naturally, you will not sue,
> | > | > | > should things get worse after this,
> | > | > | > PCR
> | > | > | >
> | > | > | > "jt3" > wrote in message
> | > | > | > ...
> | > | > | > | Yes that was what I was recalling something about--as
> I
> | > said
> | > | > to
> | > | > | > Curt,
> | > | > | > | all my refs went down with that machine.
> | > | > | > | The problem here is that this is wierd--it's clear
> that
> | > the
> | > | > boot
> | > | > | > code
> | > | > | > | is working to some degree--'Starting Windows 98' comes up
> | > first,
> | > | > which
> | > | > | > it
> | > | > | > | normally wouldn't show, then it comes up with 'Type the
> name
> | > of
> | > | > the
> | > | > | > Command
> | > | > | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even
> | > though
> | > | > | > there's no
> | > | > | > | disk, boot or otherwise in the floppy drive. Also,
> putting in
> | > the
> | > | > | > startup
> | > | > | > | disk doesn't get me anywhere--after choosing boot without
> | > cd-rom,
> | > | > to
> | > | > | > | simplify it, it just hangs with the floppy drive trying to
> | > access
> | > | > | > something.
> | > | > | > | But it seems that this must be coming from IO.SYS, since
> there
> | > | > | > couldn't be
> | > | > | > | much else doing it, if no COMMAND.COM has been loaded (of
> | > | > course..who
> | > | > | > | knows..).
> | > | > | > | I should mention that this started with an *apparent*
> CMOS
> | > | > | > failure--a
> | > | > | > | little strange since I just replaced it with a new Li cell
> | > just a
> | > | > year
> | > | > | > and a
> | > | > | > | month ago. Nothing very strange seemed to have happened
> to
> | > it,
> | > | > except
> | > | > | > all
> | > | > | > | the drives (floppies, too) had been lost, and this was on
> the
> | > | > first
> | > | > | > boot of
> | > | > | > | the day.
> | > | > | > | I reset the boot order for it to boot A: first (had
> been
> | > C:
> | > | > then
> | > | > | > A:) and
> | > | > | > | was able then to boot to DOS from the startup disk, but
> could
> | > not
> | > | > see
> | > | > | > the
> | > | > | > | other drives (just A:). I had previously installed an old
> | > version
> | > | > | > (4.0) of
> | > | > | > | Partition Magic and used the PM recovery disk to find out
> that
> | > the
> | > | > | > | partitions were all still there--but this version doesn't
> do
> | > | > anything
> | > | > | > for
> | > | > | > | MBRs, apparently.
> | > | > | > | In short, the EOS byte could easily be missing, AFAIK,
> and
> | > the
> | > | > | > only
> | > | > | > | thing I can see at the moment is to use Debug to see if
> it's
> | > still
> | > | > | > there.
> | > | > | > | Clearly, I would welcome any thoughts on the subject
> | > before I
> | > | > try
> | > | > | > | anything. I'm a little leery of slaving the disk to my
> other
> | > | > machine,
> | > | > | > if I
> | > | > | > | don't know for sure what caused the problem.
> | > | > | > |
> | > | > | > | Thanks for your time,
> | > | > | > | Joe
> | > | > | > | "PCR" > wrote in message
> | > | > | > | ...
> | > | > | > | > Enter "FDISK /MBR"
> | > | > | > | > This will rewrite the code portion of the Master
> Boot
> | > | > Record,
> | > | > | > | > leaving the Partition Table untouched, except it may
> muss
> | > the
> | > | > | > partition
> | > | > | > | > table, if there is a missing End-Of-Sector marker
> (55AA),
> | > per
> | > | > | > | > http://support.microsoft.com/?kbid=149877
> | > | > | > | > Boot Record Signature AA55 Not Found
> | > | > | > | >
> | > | > | > | > Here are the warnings against it...
> | > | > | > | >
> | > | > | > | > (a) If you have a boot sector virus, you may lose access
> to
> | > all
> | > | > | > | > partitions. Then
> | > | > | > | > http://www.terabyteunlimited.com/utilities.html MBRWork
> | > "might"
> | > | > help
> | > | > | > to
> | > | > | > | > recover them.
> | > | > | > | >
> | > | > | > | > (b) If you have "overlay" code in the MBR, e.g.,
> EZ-BIOS,
> | > | > Maxblast,
> | > | > | > a
> | > | > | > | > boot manager, then that will need to be reestablished
> | > | > afterwards.
> | > | > | > | > http://www.aefdisk.com/ FDISK & Boot Manager
> | > | > | > | >
> | > http://support.microsoft.com/support/kb/articles/Q245/1/62.ASP
> | > | > | > Overlay
> | > | > | > | > Utility & FDISK
> | > | > | > | >
> | > | > | > | > (c) FDISK may be buggy. So? Use MBRWork to do it, or
> | > | > | > | >
> | > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q263044
> | > | > | > | > Latest FDISK, hoping this one doesn't have any bugs.
> (But it
> | > | > doesn't
> | > | > | > | > solve the 55AA thing.)
> | > | > | > | >
> | > | > | > | > (d) If for some reason the "geometry" setting in BIOS
> does
> | > not
> | > | > match
> | > | > | > the
> | > | > | > | > hard drive, then any write to the drive may be
> destructive.
> | > So,
> | > | > go
> | > | > | > into
> | > | > | > | > BIOS and have it "automatically detect" the proper
> setting.
> | > (If
> | > | > you
> | > | > | > can
> | > | > | > | > DIR the drive in DOS, then you have proven the geometry
> is
> | > | > right.
> | > | > | > Well,
> | > | > | > | > Blanton says even that may not be true.)
> | > | > | > | >
> | > | > | > | >
> | > | > | > | > --
> | > | > | > | > Thanks or Good Luck,
> | > | > | > | > There may be humor in this post, and,
> | > | > | > | > Naturally, you will not sue,
> | > | > | > | > should things get worse after this,
> | > | > | > | > PCR
> | > | > | > | >
> | > | > | > | > "jt3" > wrote in message
> | > | > | > | > ...
> | > | > | > | > | I think I recall reading someone posting that the
> /MBR
> | > | > switch
> | > | > | > on
> | > | > | > | > FDISK
> | > | > | > | > | not only rewrites the master boot record, but also
> wipes
> | > out
> | > | > | > partition
> | > | > | > | > table
> | > | > | > | > | data, so that if you use /MBR on a disk with multiple
> | > | > partitions
> | > | > | > on
> | > | > | > | > it, you
> | > | > | > | > | lose the partition data. Is this true?
> | > | > | > | > | I have a problem with a corrupted MBR (I think)
> and my
> | > old
> | > | > | > version
> | > | > | > | > of
> | > | > | > | > | Partition Magic doesn't do the MBR, apparently.
> | > | > | > | > | Thanks for your time, as always,
> | > | > | > | > | Joe
> | > | > | > | > |
> | > | > | > | > |
> | > | > | > | >
> | > | > | > | >
> | > | > | > |
> | > | > | > |
> | > | > | >
> | > | > | >
> | > | > |
> | > | > |
> | > | > |
> | > | >
> | > | >
> | > |
> | > |
> | > |
> | >
> | >
> |
> |
> |
> |
>
>

jt3
June 16th 04, 10:43 PM
Bill,
Just as with PCR, sorry I didn't reply to your post, but it didn't show
up in my headers until today??? this is very strange, but I've been seein
post strangeness somewhat like this for a while; I mentioned it to GST in a
post just the other day, but he said the server was 'hiccuping'--didn't know
they did that. Anyhow, see the post to this same thread just a couple of
hours earlier today wrt geometry.
That is, if you're still following the thread.
Thanks,
Joe
"Bill Blanton" > wrote in message
...
> Even if IO.SYS is missing you would still be able to see the
> drive when booting from A:. And if you can't see the drive anyway,
> a SYS or COPY isn't going to work. But again, I wouldn't try to write to
> the drive until you determine what the problem is. (btw. You do
> want to use an OS compatible boot disk. If you don't happen to
> have a good one go to bootdisk.com)
>
> How does the card define the disks? In terms of CHS? "Auto"?
>
> As far as reading partinfo's output, just load edit. Switch floppys
> and open the file. When you get ready to exit edit, switch 'em back.
>
>
>
> "jt3" > wrote in message
...
> > Bill,
> > I believe that the 'Partition Info' button on the DOS version of
PM4.0
> > that I have on those recovery disks calls up partinfo.exe and that is
why I
> > was told to put in the second disk of the set, which has partinfo.exe on
it;
> > anyhow, that was what I did at the time, and, so far as I could tell
with my
> > brief look at it, it all looked pretty much as I recalled having set it
up.
> > Both drives, tho of course, it has been a while since I did it.
> > I can do it again but will have to rig up an editor as well as
change
> > the config files that run it from the floppy so that I can get the info
that
> > way. As I said in my last post to PCR, I am pretty sure it's calling
that
> > string out of IO.SYS, which makes me, for the reasons I stated in that
post,
> > think that the problem lies in IO.SYS, but if so, it's rather strange
> > corruption, sort of the single bit type, rather than the usual sort
where
> > something gets written over.
> > This computer also runs SE, so there wouldn't be the problem of
System
> > Restore running.
> > I may run your debug script (thanks) to dump the first sector,
though I
> > suspect that the MBR is probably OK, as I said in the previous post,
since
> > it didn't go too far astray to get to IO.SYS.
> > Finally, I *think* that a sys.com from the boot floppy ought to
replace
> > IO.SYS on the C drive, but I'm not all that sure I know which floppy I'd
> > trust the most, and I'm also not sure that all IO.SYSes are the same,
i.e.,
> > from machine to machine, and especially from instance to instance of SE.
I
> > *assume* that all the machine-specific modification is done in the
building
> > of VMM in windows, but it strikes me as possible that some differences
could
> > exist as a result of installation on different machines--I really don't
> > know, though I'd guess, again, that they're all the same. Some early
> > versions of DOS had differences, but that was some time ago.
> > Got to turn in, been burning too much late oil, tackle the problem
later
> > and get back to you as soon as I have something of any interest.
> >
> > Thanks for all your time and thought on the matter,
> > Joe.
> > "Bill Blanton" > wrote in message
> > ...
> > > A fact is that PM doesn't have to mount the volume, only define the
> > > various partitions according to the table(s) information. Win/DOS otoh
> > > has to define the partition structure and then define the OS specific
> > > volumes using the boot sectors' information. And of course, furthur
> > > along it will have to decode the Dir structure and FAT, but corruption
> > > there would probably just show corrupt files, or "file not found".
> > > You should still get a "C:" in that case (if the boot sector was
sane).
> > >
> > > Simply put, PM doesn't have to worry if a partition's content is
> > > corrupt, only that it exists.
> > >
> > > What's strange is that you get the "Starting Win 98..." message when
> > > you boot from HD0. This suggests that the volume was properly mounted
> > > and at least started to boot.
> > >
> > > I don't really know, but I would suspect a slightly off geomtry
> > > (except PM apparently isn't having a problem), or a bad boot sector
> > > (except you wouldn't expect IO.SYS to be started, and you wouldn't
> > > expect both drives to become corrupt).
> > >
> > > I don't really think it's the MBR, or the tables, or the ending sig,
> > > since the partitions look good to PM and a HD boot is at least loading
> > > IO.SYS.
> > >
> > > Until you figure it out you don't want to attempt any writes to the
> > > disks. Including fdisk/mbr. You shouldn't have any problem hooking the
> > > drive up as a slave even with an active partition on the disk, but be
> > > aware that if you hook it up to a system that has System Restore
> > > enabled (such as ME or XP), the system will attempt to write SR
> > > data to the disk. That could be bad if the geometry is skewd.
> > >
> > >
> > > At this point, I would run PM's partinfo util and see what it has to
> > > say. You'll find it on the CD in the \UTILITY directory. At the prompt
> > > run
> > > partinfo > partinfo.txt
> > > and then open partinfo in a text editor. If you want you can mail it
> > > to me at billblanton<At>earthlink<dot>net Partinfo also displays boot
> > > sector information, so mabey something obvious will turn up. It might
> > > also point to geometry conflict between the disk and the card's BIOS.
> > >
> > > As I said before I don't think it's the MBR, but if you want to look
> > > you can run this debug script to dump HD0's 1st sector. Save as
> > > "dump.scr" (or whatever) and run
> > > debug < dump.scr > dump.txt
> > > Then open dump.txt in edit to check the ending sig bytes.
> > >
> > > rip
> > > 0300
> > > a 0300
> > > mov al,1
> > > mov ch,0
> > > mov cl,1
> > > mov dh,0
> > > mov dl,80
> > > push ds
> > > pop es
> > > xor bx,bx
> > > mov ah,2
> > > int 13
> > >
> > > g 312
> > >
> > > d es:0000 L200
> > >
> > > q
> > > (make sure there is a cr/lf after "q", or it will lock)
> > >
> > >
> > >
> > >
> > > "jt3" > wrote in message
> > ...
> > > > I actually tried three different boot disks I have, all for
W98SE,
> > two
> > > > made on that machine, and one on this. They all did the same thing,
and
> > > > although I haven't tried them on this one lately, I suspect that it
> > would
> > > > net nothing new. The drives don't have any esoteric type of
partitions
> > on
> > > > them, just standard DOS primary and extended on the 80 drive, FAT
32,
> > the C
> > > > partition about 750 MB and the E partition is the balance of the 8
GB
> > > > Seagate drive, and the other is a 2 GB Quantum Bigfoot, FAT 16 and
> > > > partitioned into 4 partitions, 1 primary, 3 in the extended.
> > > > At one time, I was using a WD Caviar 850 MB as the C drive, and
I
> > had
> > > > W95SR2.1 on it, with the Quantum providing the same as it provides
now.
> > > > When this happened once before, about 4 years ago, after much
thrashing
> > > > about I gave up finally, not knowing about the newsgroup as a
resource,
> > and
> > > > bought the Seagate to replace the WD, installed W98SE, and when not
only
> > > > everything seemed to work, but I had less trouble installing and
setting
> > up
> > > > than in any of the previous installs, I thought I had made a
fortunate,
> > > > move, however blindly.
> > > > Now I should mention that which was discussed ad nauseam in the
> > > > 'Restart...' thread, namely that the hardware is built on an Eteq
mbd,
> > VL
> > > > bus, 486 DX4-100, and uses a Promise EIDE 4030+ VL Bus controller,
which
> > has
> > > > its own BIOS, enabling it to do several things not particularly
germane
> > to
> > > > the problem, except for the fact that it allows me to use a drive as
> > large
> > > > as 8GB, while the mbd AMI BIOS (1995) limits it to 2GB.
> > > > Thus, for the previous setup in which I used just the WD and
Quantum
> > > > (same partns), the partitions for the WD were C and E (using FAT16
and
> > > > trying to avoid cluster size inefficiencies) I used the *mbd BIOS*
for
> > the
> > > > disk setup. Now it's been some while ago, but as memory serves, it
was
> > a
> > > > *very* similar sort of failure, made worse by some other
complications
> > that
> > > > I would rather not go into here. I wouldn't stake my life on it
being
> > the
> > > > same, but I have my suspicions.
> > > > Anyhow, when I went to use the Seagate, it wouldn't handle
it--make
> > a
> > > > long story short, the AMI BIOS maxes out at 2.1 G, but the Promise
> > > > controller BIOS, I discovered, could handle it, so that caused me to
> > start
> > > > using it. This requires, as you may expect, not setting it in the
mbd
> > BIOS,
> > > > and activating the Promise BIOS which is done through an on-board
> > program,
> > > > and everything came up roses.
> > > > Now, this time when things went south, the Promise BIOS program
> > still
> > > > had all the correct parameters in it, and I should mention that it
is
> > all
> > > > automated, and so there isn't much possiblity of getting it messed
up.
> > The
> > > > fact that the PM reading of the partitions came up with all the
right
> > data,
> > > > suggests that the problem is not with the hard drive, controller, or
any
> > > > such thing. Since it must still be operating with IO.SYS, it's my
bet
> > that
> > > > there's something rotten there, but I don't see how to get to it,
short
> > of
> > > > trying to slave it to another machine.
> > > > My reluctance there is based on the fact that I didn't have
firewall
> > > > protection on that machine, and since I have started perforce using
this
> > one
> > > > (which has the EZ-Armor on it) I have been astounded by the number
of
> > times
> > > > it has blocked some sort of invasion (not all of which are ISP
pings).
> > This
> > > > makes me a little less secure in any assumptions regarding what
caused
> > all
> > > > this. If I slave it to this machine, I suppose it should be secure
> > enough
> > > > until I attempt to access something on it. Question is, does simply
> > reading
> > > > the FAT pose a risk? If not, I could do a scan of the drive, once
this
> > > > machine booted. I'd still have the question of the MBR, but I
expect I
> > > > could look at it with Debug (if I can find it) and see of the EOS
byte
> > is
> > > > there. I'd have to deactivate the primary partition, I guess. What
> > happens
> > > > if you have a slaved disk which also has a prmary active partition?
> > Surely
> > > > DOS 7 wouldn't like that.
> > > >
> > >
> > >
> >
> >
>
>

Bill Blanton
June 17th 04, 01:45 AM
"jt3" > wrote in message ...


> Don't know if you're still monitoring this thread, but I haven't dropped
> the problem, it's just that I'm also having trouble with EZArmor on the AMD
> machine (another thread), and since that threatens to put me off-line
> altogether, I've been devoting more time to it.

As they say.. "Hay tiempo..."
:-)

> But I did pursue the
> problem a little along the lines of your suggestion. I don't know why PM
> had wanted me to insert the second disk of the recovery set. I had thought
> that the main routine (it's a DOS app, though not command-line) on the first
> floppy simply called the second when I clicked on the 'Partition Info' tab,
> but now I don't know what the skinny on that is, because, when I tried it
> again, it didn't ask for the second disk, and when I checked the contents of
> the floppies, most everything is on the first, with mainly PARTINFO.EXE on
> the second. I'll give you the output of PM with regards to disk geometry in
> a moment, but what I found was that the version of PARTINFO on this vers. 4
> is apparently only good through FAT16, even though PM itself handles FAT32
> completely, including conversions, etc.

Didn't know that. Get the latest version anyway. Older versions got
buggy when disks got bigger. Grab it before Synmantec pulls it..
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/
(partinfo.zip)


> I then tried TeraByte's freebie PARTINFO and found it wouldn't run from
> a floppy--apparently has to be on the disk being checked. I'm pursuing
> other possibilities for that, but the disk geometry, so far as PM reports it
> is 1,023 cyls, 255 hds, 63 sects, no big surprize; it lists the partition
> type as 0Bh, FAT32, gives serial #, first physical sector: 63 (cyl 0, hd1,
> sect 1), last physical sector: 63 (cyl101, hd254, sect63); total physical
> sectors 1,638,567 (800.1 MB), which is how the disk is partitioned: 800.1
> MB in C: and 7224.5MB in the extended partn, containing just one vol: E:
> also FAT32. The other drive, the 2G Quantum is partitioned into one primary
> and 3 vols. in an extended, all FAT16.

Yes, that all adds up.


> I don't expect you were interested in the bytes free, used, wasted,
> cluster size, etc., but it all looks just fine to me.

Well.. actually, you need to look at, at least bytes/sector,
sectors/cluster, sectors/track and number of heads for the afflicted
volume. The partition table seems to be okay, so make sure the volume
boot sector doesn't contain any anomolies.


> What's so strange is
> how PM manages to access the disk using standard BIOS functions (I have the
> disk out, all breadboarded up, and can see the active disk light on the
> drive chassis, while IO.SYS seems totally unable to.

As I said earlier, PM doesn't have to mount the volume, just show
the partition. IO.SYS has to make sense of the boot sector too.
If everything looks good, I'd suspect the controller card. Mabey you
can slave the drive to your other system.


> I still can't see how
> it could be anything but IO.SYS being corrupted but it's such a strange sort
> of corruption, unless there's more of it waiting to be discovered.

But again, it is strange that IO.SYS did (or does) try to start..

PCR
June 17th 04, 01:50 AM
BUT you are using the Maxtor BIOS, no/yes? I only speculate that a
normal Startup Diskette may not have access to it, & therefore cannot
see the Maxtor drive. I see you posted figures to Blanton, & I shall tag
off to him for a bit.

To be sure you get all posts...

(1) At "OE, Tools menu, Message Rules, News", create a Message Rule to
delete posts older than, say, 30 days. Also check "stop processing more
rules".
(2) At "Tools, Options, Read tab", uncheck "Get xxx headers at a time".
(3) R-Clk the NG in the left pane, Synchronize Settings, set to All
Messages.
(4) Click "Tools, Synchronize Newsgroup"

(Now, it is a bit tricky. When I click one of those things, it gets
right to it. One really need stop it & get that rule in. I do believe,
it will then not download older than the rule specifies.)

Posts older than 30 days will not download. Posts that age on your
machine after the download are your responsibility to delete, by
occasionally going to that rule & clicking "Apply Now". After that,
compact: "OE, File menu, Folder, Compact all folders".

Colorado disagrees, but there is a cave-dwelling MVP around, who says...

(1) "OE, Tools, Options, Maintenance tab".
(2) Uncheck "Delete news messages x days after being downloaded".
(3) Uncheck "Compact messages in the background".

http://insideoe.tomsterdam.com/resources.htm#setupmsnews
Manual Instructions to connect
http://users.westelcom.com/rogersr/setupoe.htm Read this about it too
http://www.dts-l.org/ This too


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"jt3" > wrote in message
...
| PCR,
| Sorry if I didn't reply--I don't know why, but your post never showed
in my
| headers until today. For the record--never used the Maxtor overlay.
| Thanks,
| Joe
| "PCR" > wrote in message
| ...
| > I see you never did install WD's EZ-BIOS, unless it were four years
ago
| > in a different event. I'm still thinking the failure to boot from a
| > floppy can have to do with the Maxtor BIOS, though. The floppy will
not
| > go through the HDD's MBR, which may now be Maxtor specific. Not
going
| > that way, the floppy cannot see the geometry change. But that is
only a
| > guess on my part. Why does PM work? Perhaps it knows more than the
| > floppy. Or it could be as Blanton said: it doesn't need to do as
much.
| > It could be the floppy only has access to the motherboard BIOS. But
this
| > is all theoretical.
| >
| > The error message you get when booting the HDD is...
| >
| > | is working to some degree--'Starting Windows 98' comes up first,
which
| > it
| > | normally wouldn't show, then it comes up with 'Type the name of
the
| > Command
| > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
| > there's no
| > | disk, boot or otherwise in the floppy drive.
| >
| > ...which does sound like that article I posted, which calls for a
"SYS
| > C:". But I suppose you'd better send that PM PartInfo to Blanton,
| > first. Don't forget all those warnings about SYS C:.
| >
| > Where is that URL he posted that showed native Windows MBR code? No
| > matter. I suppose the message is coming out of IO.sys, not that
code.
| > I'm still here, but better deal with Blanton first.
| >
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| >
....snip

jt3
June 17th 04, 05:47 AM
Thanks, but I got a new copy of PM, and tried the PARTINFO.exe and found it
acted just as the program from TeraByte, which suggests that whatever is up
(as you say, perhaps the controller) both programs are similarly affected.
Right now, I'm at a loss except to slave it to the other machine, which I'll
try as soon as I am more secure with the problems from the AV that I've had
lately--doesn't do to handle too many variables at one time.

Thanks again,
Joe
"Bill Blanton" > wrote in message
...
>
> "jt3" > wrote in message
...
>
>
> > Don't know if you're still monitoring this thread, but I haven't
dropped
> > the problem, it's just that I'm also having trouble with EZArmor on the
AMD
> > machine (another thread), and since that threatens to put me off-line
> > altogether, I've been devoting more time to it.
>
> As they say.. "Hay tiempo..."
> :-)
>
> > But I did pursue the
> > problem a little along the lines of your suggestion. I don't know why
PM
> > had wanted me to insert the second disk of the recovery set. I had
thought
> > that the main routine (it's a DOS app, though not command-line) on the
first
> > floppy simply called the second when I clicked on the 'Partition Info'
tab,
> > but now I don't know what the skinny on that is, because, when I tried
it
> > again, it didn't ask for the second disk, and when I checked the
contents of
> > the floppies, most everything is on the first, with mainly PARTINFO.EXE
on
> > the second. I'll give you the output of PM with regards to disk
geometry in
> > a moment, but what I found was that the version of PARTINFO on this
vers. 4
> > is apparently only good through FAT16, even though PM itself handles
FAT32
> > completely, including conversions, etc.
>
> Didn't know that. Get the latest version anyway. Older versions got
> buggy when disks got bigger. Grab it before Synmantec pulls it..
> ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/
> (partinfo.zip)
>
>
> > I then tried TeraByte's freebie PARTINFO and found it wouldn't run
from
> > a floppy--apparently has to be on the disk being checked. I'm pursuing
> > other possibilities for that, but the disk geometry, so far as PM
reports it
> > is 1,023 cyls, 255 hds, 63 sects, no big surprize; it lists the
partition
> > type as 0Bh, FAT32, gives serial #, first physical sector: 63 (cyl 0,
hd1,
> > sect 1), last physical sector: 63 (cyl101, hd254, sect63); total
physical
> > sectors 1,638,567 (800.1 MB), which is how the disk is partitioned:
800.1
> > MB in C: and 7224.5MB in the extended partn, containing just one vol: E:
> > also FAT32. The other drive, the 2G Quantum is partitioned into one
primary
> > and 3 vols. in an extended, all FAT16.
>
> Yes, that all adds up.
>
>
> > I don't expect you were interested in the bytes free, used, wasted,
> > cluster size, etc., but it all looks just fine to me.
>
> Well.. actually, you need to look at, at least bytes/sector,
> sectors/cluster, sectors/track and number of heads for the afflicted
> volume. The partition table seems to be okay, so make sure the volume
> boot sector doesn't contain any anomolies.
>
>
> > What's so strange is
> > how PM manages to access the disk using standard BIOS functions (I have
the
> > disk out, all breadboarded up, and can see the active disk light on the
> > drive chassis, while IO.SYS seems totally unable to.
>
> As I said earlier, PM doesn't have to mount the volume, just show
> the partition. IO.SYS has to make sense of the boot sector too.
> If everything looks good, I'd suspect the controller card. Mabey you
> can slave the drive to your other system.
>
>
> > I still can't see how
> > it could be anything but IO.SYS being corrupted but it's such a strange
sort
> > of corruption, unless there's more of it waiting to be discovered.
>
> But again, it is strange that IO.SYS did (or does) try to start..
>
>
>
>

jt3
June 17th 04, 07:44 AM
No. Not using the Maxtor overlay. This is a Promise EIDE 4030+ VL bus
caching disk controller with its own onboard BIOS that is read in during
POST and has its own setup routine. I don't use the caching part, though it
has a couple of SIMMs in place since they are required for operation. The
BIOS provides for the use of four IDE hard drives on the primary VESA
channel, IRQ 14, (requiring the installation of two instances of the
proprietary .mpd driver if you have more than two drives) AND two CD-ROM/RW
drives on the secondary (IRQ 15) channel, which can use the proprietary .mpd
(for a total of three drivers) but usually uses the default MS one, as it
works better for the CD-ROMs. I have only used three hds on it once, and
that only for a short while, and I have only one CD-R/RW on the secondary
channel. If you are to use the extra drives and want DOS access, they
provided a special driver for access to the other two, but since this was
before FAT32, I'd never try that driver. The PTICACHE.MPD has worked just
fine, though, in fact better than it did in W95SR2.1.
The BIOS is read in in the standard fashion of optional BIOSes during
POST, and then one has the option of entering the setup program to setup the
disks, all of which is done virtually automatically, with one simply making
choices as to whether one uses the cache, the optional BIOS replacements for
the disk reading routines of the normal (mbd) BIOS (faster) and also
providing LBA assist, if that's not redundant, if one chooses it. I don't
use the cache, and haven't recently used the extra drive options, simply
because with the two G Quantum and the 8G Seagate, (that's all) I have
enough disk storage for a machine of limited speed (100MHz 486 DX4) and
memory-the mbd only takes a maximum of 64 M. The primary point of using the
card is that it supplies the BIOS replacement of the mbd BIOS and allows me
to configure up to 8G, but no more, where the mbd Award BIOS is limited to
2G. But this is an onboard BIOS chip, not an overlay.

Thanks for the advice on OE. I currently use a 15 days message rule.
The posts missed were inside that. I must admit that I subscribed to those
troglodytic ideas and had unchecked automatic compaction. I've never liked
the idea of being compacted, anyhow.... or is it im..., well, anyway, I will
take what you say into consideration and make adjustments and see what
happens.

Thanks for your time, it is appreciated,
Joe
"PCR" > wrote in message
...
> BUT you are using the Maxtor BIOS, no/yes? I only speculate that a
> normal Startup Diskette may not have access to it, & therefore cannot
> see the Maxtor drive. I see you posted figures to Blanton, & I shall tag
> off to him for a bit.
>
> To be sure you get all posts...
>
> (1) At "OE, Tools menu, Message Rules, News", create a Message Rule to
> delete posts older than, say, 30 days. Also check "stop processing more
> rules".
> (2) At "Tools, Options, Read tab", uncheck "Get xxx headers at a time".
> (3) R-Clk the NG in the left pane, Synchronize Settings, set to All
> Messages.
> (4) Click "Tools, Synchronize Newsgroup"
>
> (Now, it is a bit tricky. When I click one of those things, it gets
> right to it. One really need stop it & get that rule in. I do believe,
> it will then not download older than the rule specifies.)
>
> Posts older than 30 days will not download. Posts that age on your
> machine after the download are your responsibility to delete, by
> occasionally going to that rule & clicking "Apply Now". After that,
> compact: "OE, File menu, Folder, Compact all folders".
>
> Colorado disagrees, but there is a cave-dwelling MVP around, who says...
>
> (1) "OE, Tools, Options, Maintenance tab".
> (2) Uncheck "Delete news messages x days after being downloaded".
> (3) Uncheck "Compact messages in the background".
>
> http://insideoe.tomsterdam.com/resources.htm#setupmsnews
> Manual Instructions to connect
> http://users.westelcom.com/rogersr/setupoe.htm Read this about it too
> http://www.dts-l.org/ This too
>
>
> --
> Thanks or Good Luck,
> There may be humor in this post, and,
> Naturally, you will not sue,
> should things get worse after this,
> PCR
>
> "jt3" > wrote in message
> ...
> | PCR,
> | Sorry if I didn't reply--I don't know why, but your post never showed
> in my
> | headers until today. For the record--never used the Maxtor overlay.
> | Thanks,
> | Joe
> | "PCR" > wrote in message
> | ...
> | > I see you never did install WD's EZ-BIOS, unless it were four years
> ago
> | > in a different event. I'm still thinking the failure to boot from a
> | > floppy can have to do with the Maxtor BIOS, though. The floppy will
> not
> | > go through the HDD's MBR, which may now be Maxtor specific. Not
> going
> | > that way, the floppy cannot see the geometry change. But that is
> only a
> | > guess on my part. Why does PM work? Perhaps it knows more than the
> | > floppy. Or it could be as Blanton said: it doesn't need to do as
> much.
> | > It could be the floppy only has access to the motherboard BIOS. But
> this
> | > is all theoretical.
> | >
> | > The error message you get when booting the HDD is...
> | >
> | > | is working to some degree--'Starting Windows 98' comes up first,
> which
> | > it
> | > | normally wouldn't show, then it comes up with 'Type the name of
> the
> | > Command
> | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
> | > there's no
> | > | disk, boot or otherwise in the floppy drive.
> | >
> | > ...which does sound like that article I posted, which calls for a
> "SYS
> | > C:". But I suppose you'd better send that PM PartInfo to Blanton,
> | > first. Don't forget all those warnings about SYS C:.
> | >
> | > Where is that URL he posted that showed native Windows MBR code? No
> | > matter. I suppose the message is coming out of IO.sys, not that
> code.
> | > I'm still here, but better deal with Blanton first.
> | >
> | >
> | > --
> | > Thanks or Good Luck,
> | > There may be humor in this post, and,
> | > Naturally, you will not sue,
> | > should things get worse after this,
> | > PCR
> | >
> ...snip
>
>

jt3
June 17th 04, 09:55 PM
I guess I should add, though I think it can be inferred from last P, that it
*isn't* a Maxtor BIOS upgrade adapter, the machine is too old, no PCI slots.
But perhaps I'm missing the point on your interest in the Maxtor
possibility? Please toss any thoughts my way--always prefer a surfeit of
info rather than a paucity.
Thanks,
Joe
"jt3" > wrote in message
...
> No. Not using the Maxtor overlay. This is a Promise EIDE 4030+ VL bus
> caching disk controller with its own onboard BIOS that is read in during
> POST and has its own setup routine. I don't use the caching part, though
it
> has a couple of SIMMs in place since they are required for operation. The
> BIOS provides for the use of four IDE hard drives on the primary VESA
> channel, IRQ 14, (requiring the installation of two instances of the
> proprietary .mpd driver if you have more than two drives) AND two
CD-ROM/RW
> drives on the secondary (IRQ 15) channel, which can use the proprietary
..mpd
> (for a total of three drivers) but usually uses the default MS one, as it
> works better for the CD-ROMs. I have only used three hds on it once, and
> that only for a short while, and I have only one CD-R/RW on the secondary
> channel. If you are to use the extra drives and want DOS access, they
> provided a special driver for access to the other two, but since this was
> before FAT32, I'd never try that driver. The PTICACHE.MPD has worked just
> fine, though, in fact better than it did in W95SR2.1.
> The BIOS is read in in the standard fashion of optional BIOSes during
> POST, and then one has the option of entering the setup program to setup
the
> disks, all of which is done virtually automatically, with one simply
making
> choices as to whether one uses the cache, the optional BIOS replacements
for
> the disk reading routines of the normal (mbd) BIOS (faster) and also
> providing LBA assist, if that's not redundant, if one chooses it. I don't
> use the cache, and haven't recently used the extra drive options, simply
> because with the two G Quantum and the 8G Seagate, (that's all) I have
> enough disk storage for a machine of limited speed (100MHz 486 DX4) and
> memory-the mbd only takes a maximum of 64 M. The primary point of using
the
> card is that it supplies the BIOS replacement of the mbd BIOS and allows
me
> to configure up to 8G, but no more, where the mbd Award BIOS is limited to
> 2G. But this is an onboard BIOS chip, not an overlay.
>
> Thanks for the advice on OE. I currently use a 15 days message rule.
> The posts missed were inside that. I must admit that I subscribed to
those
> troglodytic ideas and had unchecked automatic compaction. I've never
liked
> the idea of being compacted, anyhow.... or is it im..., well, anyway, I
will
> take what you say into consideration and make adjustments and see what
> happens.
>
> Thanks for your time, it is appreciated,
> Joe
> "PCR" > wrote in message
> ...
> > BUT you are using the Maxtor BIOS, no/yes? I only speculate that a
> > normal Startup Diskette may not have access to it, & therefore cannot
> > see the Maxtor drive. I see you posted figures to Blanton, & I shall tag
> > off to him for a bit.
> >
> > To be sure you get all posts...
> >
> > (1) At "OE, Tools menu, Message Rules, News", create a Message Rule to
> > delete posts older than, say, 30 days. Also check "stop processing more
> > rules".
> > (2) At "Tools, Options, Read tab", uncheck "Get xxx headers at a time".
> > (3) R-Clk the NG in the left pane, Synchronize Settings, set to All
> > Messages.
> > (4) Click "Tools, Synchronize Newsgroup"
> >
> > (Now, it is a bit tricky. When I click one of those things, it gets
> > right to it. One really need stop it & get that rule in. I do believe,
> > it will then not download older than the rule specifies.)
> >
> > Posts older than 30 days will not download. Posts that age on your
> > machine after the download are your responsibility to delete, by
> > occasionally going to that rule & clicking "Apply Now". After that,
> > compact: "OE, File menu, Folder, Compact all folders".
> >
> > Colorado disagrees, but there is a cave-dwelling MVP around, who says...
> >
> > (1) "OE, Tools, Options, Maintenance tab".
> > (2) Uncheck "Delete news messages x days after being downloaded".
> > (3) Uncheck "Compact messages in the background".
> >
> > http://insideoe.tomsterdam.com/resources.htm#setupmsnews
> > Manual Instructions to connect
> > http://users.westelcom.com/rogersr/setupoe.htm Read this about it too
> > http://www.dts-l.org/ This too
> >
> >
> > --
> > Thanks or Good Luck,
> > There may be humor in this post, and,
> > Naturally, you will not sue,
> > should things get worse after this,
> > PCR
> >
> > "jt3" > wrote in message
> > ...
> > | PCR,
> > | Sorry if I didn't reply--I don't know why, but your post never showed
> > in my
> > | headers until today. For the record--never used the Maxtor overlay.
> > | Thanks,
> > | Joe
> > | "PCR" > wrote in message
> > | ...
> > | > I see you never did install WD's EZ-BIOS, unless it were four years
> > ago
> > | > in a different event. I'm still thinking the failure to boot from a
> > | > floppy can have to do with the Maxtor BIOS, though. The floppy will
> > not
> > | > go through the HDD's MBR, which may now be Maxtor specific. Not
> > going
> > | > that way, the floppy cannot see the geometry change. But that is
> > only a
> > | > guess on my part. Why does PM work? Perhaps it knows more than the
> > | > floppy. Or it could be as Blanton said: it doesn't need to do as
> > much.
> > | > It could be the floppy only has access to the motherboard BIOS. But
> > this
> > | > is all theoretical.
> > | >
> > | > The error message you get when booting the HDD is...
> > | >
> > | > | is working to some degree--'Starting Windows 98' comes up first,
> > which
> > | > it
> > | > | normally wouldn't show, then it comes up with 'Type the name of
> > the
> > | > Command
> > | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even though
> > | > there's no
> > | > | disk, boot or otherwise in the floppy drive.
> > | >
> > | > ...which does sound like that article I posted, which calls for a
> > "SYS
> > | > C:". But I suppose you'd better send that PM PartInfo to Blanton,
> > | > first. Don't forget all those warnings about SYS C:.
> > | >
> > | > Where is that URL he posted that showed native Windows MBR code? No
> > | > matter. I suppose the message is coming out of IO.sys, not that
> > code.
> > | > I'm still here, but better deal with Blanton first.
> > | >
> > | >
> > | > --
> > | > Thanks or Good Luck,
> > | > There may be humor in this post, and,
> > | > Naturally, you will not sue,
> > | > should things get worse after this,
> > | > PCR
> > | >
> > ...snip
> >
> >
>
>

PCR
June 17th 04, 10:12 PM
Well, the main thing, which I think originated in a PA Bear tip, was...
At "Tools, Options, Read tab", uncheck "Get xxx headers at a time. Then
OE is not limited in what it will read in per synchronization. If you do
not have a rule set, there WILL be an ONSLAUGHT of incoming posts the
first time, though!

Uhhhhh, right, that's what I meant! I speculate your floppy is not
accessing the Promise BIOS, & I don't care that it isn't an overlay.
You, yourself, subsequently said something like...

| If you are to use the extra drives and want DOS access, they
| provided a special driver for access to the other two, but since this
was
| before FAT32, I'd never try that driver.

Anyhow, as Blanton said elsewhere, are you sure you have a floppy that
matches your OS...

Get a Startup Diskette from
http://www.bootdisk.com/ , if you don't already have one from "Control
Panel, Add/Remove Programs, Startup Disk tab". Test the Startup
Diskette. Boot it, put in a CD and "DIR" the CD. It will say which
letter is the CD. (Otherwise, it is likely one letter higher than
normal.)


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"jt3" > wrote in message
...
| No. Not using the Maxtor overlay. This is a Promise EIDE 4030+ VL bus
| caching disk controller with its own onboard BIOS that is read in
during
| POST and has its own setup routine. I don't use the caching part,
though it
| has a couple of SIMMs in place since they are required for operation.
The
| BIOS provides for the use of four IDE hard drives on the primary VESA
| channel, IRQ 14, (requiring the installation of two instances of the
| proprietary .mpd driver if you have more than two drives) AND two
CD-ROM/RW
| drives on the secondary (IRQ 15) channel, which can use the
proprietary .mpd
| (for a total of three drivers) but usually uses the default MS one, as
it
| works better for the CD-ROMs. I have only used three hds on it once,
and
| that only for a short while, and I have only one CD-R/RW on the
secondary
| channel. If you are to use the extra drives and want DOS access, they
| provided a special driver for access to the other two, but since this
was
| before FAT32, I'd never try that driver. The PTICACHE.MPD has worked
just
| fine, though, in fact better than it did in W95SR2.1.
| The BIOS is read in in the standard fashion of optional BIOSes
during
| POST, and then one has the option of entering the setup program to
setup the
| disks, all of which is done virtually automatically, with one simply
making
| choices as to whether one uses the cache, the optional BIOS
replacements for
| the disk reading routines of the normal (mbd) BIOS (faster) and also
| providing LBA assist, if that's not redundant, if one chooses it. I
don't
| use the cache, and haven't recently used the extra drive options,
simply
| because with the two G Quantum and the 8G Seagate, (that's all) I have
| enough disk storage for a machine of limited speed (100MHz 486 DX4)
and
| memory-the mbd only takes a maximum of 64 M. The primary point of
using the
| card is that it supplies the BIOS replacement of the mbd BIOS and
allows me
| to configure up to 8G, but no more, where the mbd Award BIOS is
limited to
| 2G. But this is an onboard BIOS chip, not an overlay.
|
| Thanks for the advice on OE. I currently use a 15 days message
rule.
| The posts missed were inside that. I must admit that I subscribed to
those
| troglodytic ideas and had unchecked automatic compaction. I've never
liked
| the idea of being compacted, anyhow.... or is it im..., well, anyway,
I will
| take what you say into consideration and make adjustments and see what
| happens.
|
| Thanks for your time, it is appreciated,
| Joe
| "PCR" > wrote in message
| ...
| > BUT you are using the Maxtor BIOS, no/yes? I only speculate that a
| > normal Startup Diskette may not have access to it, & therefore
cannot
| > see the Maxtor drive. I see you posted figures to Blanton, & I shall
tag
| > off to him for a bit.
| >
| > To be sure you get all posts...
| >
| > (1) At "OE, Tools menu, Message Rules, News", create a Message Rule
to
| > delete posts older than, say, 30 days. Also check "stop processing
more
| > rules".
| > (2) At "Tools, Options, Read tab", uncheck "Get xxx headers at a
time".
| > (3) R-Clk the NG in the left pane, Synchronize Settings, set to All
| > Messages.
| > (4) Click "Tools, Synchronize Newsgroup"
| >
| > (Now, it is a bit tricky. When I click one of those things, it gets
| > right to it. One really need stop it & get that rule in. I do
believe,
| > it will then not download older than the rule specifies.)
| >
| > Posts older than 30 days will not download. Posts that age on your
| > machine after the download are your responsibility to delete, by
| > occasionally going to that rule & clicking "Apply Now". After that,
| > compact: "OE, File menu, Folder, Compact all folders".
| >
| > Colorado disagrees, but there is a cave-dwelling MVP around, who
says...
| >
| > (1) "OE, Tools, Options, Maintenance tab".
| > (2) Uncheck "Delete news messages x days after being downloaded".
| > (3) Uncheck "Compact messages in the background".
| >
| > http://insideoe.tomsterdam.com/resources.htm#setupmsnews
| > Manual Instructions to connect
| > http://users.westelcom.com/rogersr/setupoe.htm Read this about it
too
| > http://www.dts-l.org/ This too
| >
| >
| > --
| > Thanks or Good Luck,
| > There may be humor in this post, and,
| > Naturally, you will not sue,
| > should things get worse after this,
| > PCR
| >
| > "jt3" > wrote in message
| > ...
| > | PCR,
| > | Sorry if I didn't reply--I don't know why, but your post never
showed
| > in my
| > | headers until today. For the record--never used the Maxtor
overlay.
| > | Thanks,
| > | Joe
| > | "PCR" > wrote in message
| > | ...
| > | > I see you never did install WD's EZ-BIOS, unless it were four
years
| > ago
| > | > in a different event. I'm still thinking the failure to boot
from a
| > | > floppy can have to do with the Maxtor BIOS, though. The floppy
will
| > not
| > | > go through the HDD's MBR, which may now be Maxtor specific. Not
| > going
| > | > that way, the floppy cannot see the geometry change. But that is
| > only a
| > | > guess on my part. Why does PM work? Perhaps it knows more than
the
| > | > floppy. Or it could be as Blanton said: it doesn't need to do as
| > much.
| > | > It could be the floppy only has access to the motherboard BIOS.
But
| > this
| > | > is all theoretical.
| > | >
| > | > The error message you get when booting the HDD is...
| > | >
| > | > | is working to some degree--'Starting Windows 98' comes up
first,
| > which
| > | > it
| > | > | normally wouldn't show, then it comes up with 'Type the name
of
| > the
| > | > Command
| > | > | Interpreter (e.g. C:\WINDOWS\COMMAND.COM)' <cr>'A>' even
though
| > | > there's no
| > | > | disk, boot or otherwise in the floppy drive.
| > | >
| > | > ...which does sound like that article I posted, which calls for
a
| > "SYS
| > | > C:". But I suppose you'd better send that PM PartInfo to
Blanton,
| > | > first. Don't forget all those warnings about SYS C:.
| > | >
| > | > Where is that URL he posted that showed native Windows MBR code?
No
| > | > matter. I suppose the message is coming out of IO.sys, not that
| > code.
| > | > I'm still here, but better deal with Blanton first.
| > | >
| > | >
| > | > --
| > | > Thanks or Good Luck,
| > | > There may be humor in this post, and,
| > | > Naturally, you will not sue,
| > | > should things get worse after this,
| > | > PCR
| > | >
| > ...snip
| >
| >
|
|

jt3
June 17th 04, 10:45 PM
I wanted to apologize for my unthinking persistence in looking for the
problem to be in IO.SYS--clearly it can't be that, and it's highly unlikely
that it would have anything to do with the MBR if the machine acts
essentially the same when a boot is attempted from C: and from two different
floppy boot disks. I wasn't thinking.
However, since it all started with the CMOS going south, I got to
thinking about possible settings. One really bad thing about the Promise
products of that period is that the documentation is very uneven, and
reminiscent of the worst of the early imports from Taiwan, with an overlay
of American-style 'You don't really need to know..' attitude. In
particular, it says nothing about disabling the mbd BIOS and to what extent.
The online additional documentation was often at odds with the printed
version, and with other online docs, so one has to experiment, but one
online note did mention that a particular problem occurred if the mbd BIOS
hd function had not been disabled.
Unfortunately, making a written copy of the BIOS settings was always
something I was going to do when I had a moment... As best as I can recall,
I had it set to 'Not Installed' for hd0, as well as the slave. Seems only
reasonable, anyhow. Now the part of interest is that under the 'Advanced
Settings' (it's an early 1995 AMI WinBios--Win meaning, presumeably that it
uses a mouse, mainly) where it has selections for:

IDE Multi-Sector Transfer (auto,2,4,8)
and:
IDE 32-bit Transfer
IDE Block Mode (these 3 each one of disable, master,
IDE LBA Mode slave, or mas/sla)
for the Primary channel, and:
Secondary IDE Present (none, 1, or 2)
and the above three choices for the secondary as well.
As I didn't remember precisely what I had settled on before, I left the
first at auto, the next 3 at disabled, and I see that I left the secondary
channel at 1, probably because the docs for the card are totally
uninformative about how this is done, but since it is clear that this would
be the secondary, with IRQ 15, and it *does* persist in referring to this
channel as the *ISA* channel meaning the 16-bit bus apparently, while always
referring to the primary channel as the *VESA* channel meaning VL-bus,
32-bit, etc. So I left the 'Secondary IDE Present' at '1' with what I
thought were the appropriate values for the other secondary parameters,
except that now I see that I had them all disabled, rather than enabling the
Block mode.
What I'm asking you is whether you think it possible that either the
card BIOS is supposed to handle this channel independently and therefore
require full disabling, or alternatively, not setting block mode on the
secondary if so required could foul up the ability to read from the primary
(I admit it doesn't seem likely), and also, whether it should be reasonably
safe to play around with these settings--it would seem so, since there
shouldn't be any writing to the disk unless it manages to boot at least to
the point where a new backup of system.dat, etc., would be written. Trouble
is that these machines have both given me enough concentrated trouble over
the last month that I've gotten a little reluctant to take even unrisky
steps for not knowing all possible details.

Thanks for your time,
Joe
"jt3" > wrote in message
...
> Thanks, but I got a new copy of PM, and tried the PARTINFO.exe and found
it
> acted just as the program from TeraByte, which suggests that whatever is
up
> (as you say, perhaps the controller) both programs are similarly affected.
> Right now, I'm at a loss except to slave it to the other machine, which
I'll
> try as soon as I am more secure with the problems from the AV that I've
had
> lately--doesn't do to handle too many variables at one time.
>
> Thanks again,
> Joe
> "Bill Blanton" > wrote in message
> ...
> >
> > "jt3" > wrote in message
> ...
> >
> >
> > > Don't know if you're still monitoring this thread, but I haven't
> dropped
> > > the problem, it's just that I'm also having trouble with EZArmor on
the
> AMD
> > > machine (another thread), and since that threatens to put me off-line
> > > altogether, I've been devoting more time to it.
> >
> > As they say.. "Hay tiempo..."
> > :-)
> >
> > > But I did pursue the
> > > problem a little along the lines of your suggestion. I don't know why
> PM
> > > had wanted me to insert the second disk of the recovery set. I had
> thought
> > > that the main routine (it's a DOS app, though not command-line) on the
> first
> > > floppy simply called the second when I clicked on the 'Partition Info'
> tab,
> > > but now I don't know what the skinny on that is, because, when I tried
> it
> > > again, it didn't ask for the second disk, and when I checked the
> contents of
> > > the floppies, most everything is on the first, with mainly
PARTINFO.EXE
> on
> > > the second. I'll give you the output of PM with regards to disk
> geometry in
> > > a moment, but what I found was that the version of PARTINFO on this
> vers. 4
> > > is apparently only good through FAT16, even though PM itself handles
> FAT32
> > > completely, including conversions, etc.
> >
> > Didn't know that. Get the latest version anyway. Older versions got
> > buggy when disks got bigger. Grab it before Synmantec pulls it..
> > ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/
> > (partinfo.zip)
> >
> >
> > > I then tried TeraByte's freebie PARTINFO and found it wouldn't run
> from
> > > a floppy--apparently has to be on the disk being checked. I'm
pursuing
> > > other possibilities for that, but the disk geometry, so far as PM
> reports it
> > > is 1,023 cyls, 255 hds, 63 sects, no big surprize; it lists the
> partition
> > > type as 0Bh, FAT32, gives serial #, first physical sector: 63 (cyl 0,
> hd1,
> > > sect 1), last physical sector: 63 (cyl101, hd254, sect63); total
> physical
> > > sectors 1,638,567 (800.1 MB), which is how the disk is partitioned:
> 800.1
> > > MB in C: and 7224.5MB in the extended partn, containing just one vol:
E:
> > > also FAT32. The other drive, the 2G Quantum is partitioned into one
> primary
> > > and 3 vols. in an extended, all FAT16.
> >
> > Yes, that all adds up.
> >
> >
> > > I don't expect you were interested in the bytes free, used,
wasted,
> > > cluster size, etc., but it all looks just fine to me.
> >
> > Well.. actually, you need to look at, at least bytes/sector,
> > sectors/cluster, sectors/track and number of heads for the afflicted
> > volume. The partition table seems to be okay, so make sure the volume
> > boot sector doesn't contain any anomolies.
> >
> >
> > > What's so strange is
> > > how PM manages to access the disk using standard BIOS functions (I
have
> the
> > > disk out, all breadboarded up, and can see the active disk light on
the
> > > drive chassis, while IO.SYS seems totally unable to.
> >
> > As I said earlier, PM doesn't have to mount the volume, just show
> > the partition. IO.SYS has to make sense of the boot sector too.
> > If everything looks good, I'd suspect the controller card. Mabey you
> > can slave the drive to your other system.
> >
> >
> > > I still can't see how
> > > it could be anything but IO.SYS being corrupted but it's such a
strange
> sort
> > > of corruption, unless there's more of it waiting to be discovered.
> >
> > But again, it is strange that IO.SYS did (or does) try to start..
> >
> >
> >
> >
>
>

Bill Blanton
June 18th 04, 02:15 AM
"jt3" > wrote in message ...

> However, since it all started with the CMOS going south, I got to
> thinking about possible settings.

> it's an early 1995 AMI WinBios

> IDE Multi-Sector Transfer (auto,2,4,8)
> and:
> IDE 32-bit Transfer
> IDE Block Mode (these 3 each one of disable, master,
> IDE LBA Mode slave, or mas/sla)
> for the Primary channel, and:
> Secondary IDE Present (none, 1, or 2)
> and the above three choices for the secondary as well.

> As I didn't remember precisely what I had settled on before, I left the
> first at auto, the next 3 at disabled, and I see that I left the secondary
> channel at 1, probably because the docs for the card are totally
> uninformative about how this is done, but since it is clear that this would
> be the secondary, with IRQ 15, and it *does* persist in referring to this
> channel as the *ISA* channel meaning the 16-bit bus apparently, while always
> referring to the primary channel as the *VESA* channel meaning VL-bus,
> 32-bit, etc. So I left the 'Secondary IDE Present' at '1' with what I
> thought were the appropriate values for the other secondary parameters,
> except that now I see that I had them all disabled, rather than enabling the
> Block mode.
> What I'm asking you is whether you think it possible that either the
> card BIOS is supposed to handle this channel independently and therefore
> require full disabling,

Don't really know. I would guess that both the primary and secondary
would need to be disabled so the card's BIOS can pick them up without
any conflict of resources.


> or alternatively, not setting block mode on the
> secondary if so required could foul up the ability to read from the primary
> (I admit it doesn't seem likely),

Having block mode disabled shouldn't cause any problems other than
performance. Same with 32-bit transfer. AFAIK.


> and also, whether it should be reasonably
> safe to play around with these settings--it would seem so, since there
> shouldn't be any writing to the disk unless it manages to boot at least to
> the point where a new backup of system.dat, etc., would be written.

I would guess so too, as long as you don't let the HD boot.


> Trouble
> is that these machines have both given me enough concentrated trouble over
> the last month that I've gotten a little reluctant to take even unrisky
> steps for not knowing all possible details.

Sorry, I can't give you a definitive answer. I think it strange that
the primary would be required to be disabled and not the secondary.
Do you have this? http://www.embeddedlogic.com/TH99/c/P-R/20786.htm

I think you're on the right track, but you might try a newsgroup devoted to
hardware, such as-
alt.comp.hardware.pc-homebuilt

jt3
June 18th 04, 06:36 AM
Thanks for the references.. The 'embeddedlogic' page is essentially covered
in the manual, though they've corrected some of the ambiguities. I will
repost when I get it more sorted out, but right now there's even more around
here that I need to get fixed than the computer, so back after a bit. :-)
Thanks again, Bill,
Joe
"Bill Blanton" > wrote in message
...
> "jt3" > wrote in message
...
>
> > However, since it all started with the CMOS going south, I got to
> > thinking about possible settings.
>
> > it's an early 1995 AMI WinBios
>
> > IDE Multi-Sector Transfer (auto,2,4,8)
> > and:
> > IDE 32-bit Transfer
> > IDE Block Mode (these 3 each one of disable, master,
> > IDE LBA Mode slave, or mas/sla)
> > for the Primary channel, and:
> > Secondary IDE Present (none, 1, or 2)
> > and the above three choices for the secondary as well.
>
> > As I didn't remember precisely what I had settled on before, I left
the
> > first at auto, the next 3 at disabled, and I see that I left the
secondary
> > channel at 1, probably because the docs for the card are totally
> > uninformative about how this is done, but since it is clear that this
would
> > be the secondary, with IRQ 15, and it *does* persist in referring to
this
> > channel as the *ISA* channel meaning the 16-bit bus apparently, while
always
> > referring to the primary channel as the *VESA* channel meaning VL-bus,
> > 32-bit, etc. So I left the 'Secondary IDE Present' at '1' with what I
> > thought were the appropriate values for the other secondary parameters,
> > except that now I see that I had them all disabled, rather than enabling
the
> > Block mode.
> > What I'm asking you is whether you think it possible that either the
> > card BIOS is supposed to handle this channel independently and therefore
> > require full disabling,
>
> Don't really know. I would guess that both the primary and secondary
> would need to be disabled so the card's BIOS can pick them up without
> any conflict of resources.
>
>
> > or alternatively, not setting block mode on the
> > secondary if so required could foul up the ability to read from the
primary
> > (I admit it doesn't seem likely),
>
> Having block mode disabled shouldn't cause any problems other than
> performance. Same with 32-bit transfer. AFAIK.
>
>
> > and also, whether it should be reasonably
> > safe to play around with these settings--it would seem so, since there
> > shouldn't be any writing to the disk unless it manages to boot at least
to
> > the point where a new backup of system.dat, etc., would be written.
>
> I would guess so too, as long as you don't let the HD boot.
>
>
> > Trouble
> > is that these machines have both given me enough concentrated trouble
over
> > the last month that I've gotten a little reluctant to take even unrisky
> > steps for not knowing all possible details.
>
> Sorry, I can't give you a definitive answer. I think it strange that
> the primary would be required to be disabled and not the secondary.
> Do you have this? http://www.embeddedlogic.com/TH99/c/P-R/20786.htm
>
> I think you're on the right track, but you might try a newsgroup devoted
to
> hardware, such as-
> alt.comp.hardware.pc-homebuilt
>
>
>
>

cquirke (MVP Win9x)
June 19th 04, 12:47 PM
On Thu, 17 Jun 2004 21:15:39 -0400, "Bill Blanton"

>I think it strange that the primary would be required to be
>disabled and not the secondary.

Just picking up on that: I've seen several PCs that have defective
primary xIDE channels, and have to run everything off the secondary
instead (or add extra cards). I see one of these regularly, and note
it is never able to shut down properly (Win98SE) so this may be a
cause of that issue as well.



>-------------------- ----- ---- --- -- - - - -
No, perfection is not an entrance requirement.
We'll settle for integrity and humility
>-------------------- ----- ---- --- -- - - - -

jt3
June 19th 04, 06:43 PM
Thanks, currently checking that out.
Joe
"cquirke (MVP Win9x)" > wrote in message
...
> On Thu, 17 Jun 2004 21:15:39 -0400, "Bill Blanton"
>
> >I think it strange that the primary would be required to be
> >disabled and not the secondary.
>
> Just picking up on that: I've seen several PCs that have defective
> primary xIDE channels, and have to run everything off the secondary
> instead (or add extra cards). I see one of these regularly, and note
> it is never able to shut down properly (Win98SE) so this may be a
> cause of that issue as well.
>
>
>
> >-------------------- ----- ---- --- -- - - - -
> No, perfection is not an entrance requirement.
> We'll settle for integrity and humility
> >-------------------- ----- ---- --- -- - - - -

jt3
June 21st 04, 08:56 PM
Odd thing about this is that it does very similarly with a different IDE
adapter (one without >2G BIOS) using another hd (850MB), whether or not I
use the machine BIOS. It's so bad I installed the OS three times before I
could get it to work, and then, during some minor config. changes, it fouled
up the FAT! I'm beginning to wonder if this is some of why VL-bus machines
fell out of favor so rapidly, and not just Intel's marketing power.
Anyhow, curiosity can propel one only so long. :-|
Thanks again,
Joe
"cquirke (MVP Win9x)" > wrote in message
...
> On Thu, 17 Jun 2004 21:15:39 -0400, "Bill Blanton"
>
> >I think it strange that the primary would be required to be
> >disabled and not the secondary.
>
> Just picking up on that: I've seen several PCs that have defective
> primary xIDE channels, and have to run everything off the secondary
> instead (or add extra cards). I see one of these regularly, and note
> it is never able to shut down properly (Win98SE) so this may be a
> cause of that issue as well.
>
>
>
> >-------------------- ----- ---- --- -- - - - -
> No, perfection is not an entrance requirement.
> We'll settle for integrity and humility
> >-------------------- ----- ---- --- -- - - - -