kony wrote:

> On Mon, 05 Nov 2007 15:11:08 -0800, Ghostrider
> <-00-@fitron.142> wrote:
>
>
>>kony wrote:
>>
>>
>>>On Mon, 5 Nov 2007 11:41:14 -0500, "DaddyJim"
>>><jj2145@yahoo.com> wrote:
>>>
>>>
>>>
>>>>Guess I've really screwed up now. Took first posts advice, tried repair, now
>>>>I get the Verifying DMI Pool Data with 2 Y's at bottom of screen with crazy
>>>>symbol beside each Y. Have no idea what this means, except messed up drive
>>>>even more I suppose. I have installed another drive, loaded win xp, and
>>>>everything working fine. Point is, I wanted to salvage data on other drive,
>>>>(which I know for a fact was good drive), but I took bad advise. Live and
>>>>learn I guess.
>>>>
>>>
>>>
>>>
>>>I know of no particular issues with your motherboard or
>>>chipset, it should've been fairly straightforward to install
>>>and boot XP. I also wonder if the drive label shows the
>>>jumpering in a confusing way and the jumpers are still
>>>wrong.
>>>
>>>You wrote that you booted the XP CD, it saw the drive and
>>>existing XP installation on it, and it seemed to do a repair
>>>on that installation and complete successfully, but still it
>>>does not boot? Had you yet rechecked the jumpering to be
>>>"single" and disconnected the other drives? Regardless,
>>>if the old XP installation won't boot on the new system then
>>>the current goal is getting the motherboard bios to properly
>>>detect the drive then to just boot to the new drive, new XP
>>>installation and proceed to copy the data off the other
>>>drive.
>>>
>>>If the other/old drive is unresponsive in windows and/or not
>>>properly detected in the bios then it is time to run the HDD
>>>manufacturer's utilities. Having "repaired" XP would not
>>>have done away with your data, it should still be on the
>>>drive as before the repair... unless you really meant you
>>>did a new clean install which included formatting the drive
>>>(chosing specifically to do so) right before beginning that
>>>install to that drive and partition.
>>
>>
>>These are some pretty broad assumptions that would have no consequence
>>had the error reported by the "verifying DMI pool data" message. But the
>>mis-detection or the wrong detection of the track arrangements of a hard
>>drive stems from the corruption of the bios tables. In the plug-and-play
>>bioses, the corruption is so much easier due to the Windows OS being able,
>>in particular, to write to and update the bios tables through the data
>>management interface (DMI). Whilst there are conventions established by
>>the DMTF, an improper write to the bios tables, including a 1-bit frame
>>shift, is enough to corrupt the tables. Think that the PnP Windows OSes
>>are that perfect when sending device data to the system bios?
>>
>>The precaution written by GHalleck should have been taken into advisement.
>>If the bios table data for the hard drive is missing or incorrect, then
>>imagine what the Windows repair did to the drive's existing geometry.
>
>
>
> The entirety of what you have written is exceedingly
> unlikely if not impossible. DMI does not generate a drive
> table used to access the drive before
> booting/causing-failure, DMI is a reporting function
> separate from the main bios functionality.
>
> The message comes up on any system whose bios is designed to
> display it, then simply stays on screen when nothing boots
> to cause the screen to display something else instead.
>
> There is zero evidence there was even windows running when
> the non-booting drive was installed, then subsequently a
> different drive then works to install and boot windows.
>
> There might be a bug in the motherboard bios having nothing
> to do with DMI, that has misdetected or was not set to
> auto-detection and has thus misunderstood the drive
> parameters, but given that this variable then became static
> and XP was writing it, that static variable should allow the
> drive to then be equally accessed upon next reboot attempt
> if it were the only problem.
>
>

The DMI is just an "interface". That is all it is. The issue is what has
happened with the data pool, or the built-in tables that comprise the bios
and its ability to function. I still have my original e-mails with the
original DMTF, when it was known as the "Desktop Management Task Force",
after a particular manufacturer's bios revisions were bringing down all
of our computers of a specific make in the mid-1990's. And the solution
was to shut down the write ability of Windows PnP and stick to the built-
in bios tables and parameters for hardware and avoiding any translational
changes through interpolation by the PnP OS.

Once the corruption has been introduced into the HD bios tables, then it
is not going to be corrected if the hard drive fails to boot, should the
boot sector remains unlocatable. Interesting conumdrum. Even Windows 98
systems were affected but Windows NT systems and their derivatives were
not. We replaced a lot of bioses and, unfortunately, threw away a lot of
good hard drives until someone realized that Windows NT was a non-PnP OS,
meaning that it did not write back to the DMI data pools.

Daddy Jim's motherboard and bios evidently came from a time period when
Windows was being debugged to near-perfection and the DMTF truly came
into being as a significant force for interoperability in computing. This
is why the outcome did not surprise me, especially when a stripped down
bios (? HP) might also have been involved. Been there...seen that.