replaced blown board, need RAID update

Discussion in 'MSI' started by tcp_ip_newb, Jun 2, 2010.

  1. tcp_ip_newb

    tcp_ip_newb Guest

    I had a K9N6PGM-F motherboard which suddenly
    started overheating the CPU and shutting down.
    I had a pair of identical disk drives running
    in SATA RAID 1.
    When the board went out, I tried to find an
    exact replacement. They are no longer available.

    So I bought a K9N6PGM2-V2 to replace it. Everything
    worked fine except the RAID array is showing up as
    2 independent disks. I considered copying everything
    off to a USB drive and reinstalling WinXP Pro / SP2
    so that I could install the SATA RAID drivers that
    came with the new board.
    WinXP PRO / SP2 is no longer available and I no
    longer have the WinXP Pro / SP2 setup disk for this
    computer.

    If I try to turn on the RAID operation in the BIOS,
    I get a message: "NTLDR not found. Press Cntrl-Alt-Del
    to restart"

    SO:

    Does anyone know of a trick to getting the new RAID
    drivers installed in place of the old ones from the
    K9N6PGM-F board that was working fine until the board
    failed? The only insructions from MSI say to press the
    F6 key when installing the OS to get the RAID drivers
    installed from a floppy during installation.

    The only copy of WinXP PRo that I have is already on
    the disks and has SATA RAID drivers for the old board.
    I just need to upgrade them.


    Many thanks for any suggestions.
     
    tcp_ip_newb, Jun 2, 2010
    #1
    1. Advertisements

  2. tcp_ip_newb

    Paul Guest

    Looking at the available information for the two motherboards,
    this transition should have "just worked".

    There is a suggestion here.

    http://www.hardwareanalysis.com/content/topic/19312/

    Basically, the theory goes, you need to "Rebuild" the
    array. The question is, how to do this safely.

    You can back up one or both of your RAID 1 (mirror) drives.
    I use a program like "dd", which is a sector by sector
    transfer program. If I had two 250GB RAID 1 disks, I'd take
    my 500GB spare, and copy both disks, something like this:

    dd if=/dev/hda of=disk0_backup.dd

    and that should run, until the entire "hda" drive is copied.
    It would copy the MBR (sector 0), all the way up to the end
    of the drive. So at least, in theory, no user data gets
    lost. The metadata up at the end, may remain hidden, so I
    can't be sure that part would get backed up. But you
    might not need that anyway, as it is a mirror. (Metadata
    is a bit more important with RAID 0, as it might record
    the stripe size, which drive is odd, which drive is even,
    and so on.)

    You can use your own backup techniques, assuming you know
    all the important data will be captured. The nice thing
    about sector by sector copies, is it doesn't matter what
    file systems are there, or even whether they're broken,
    the entire thing gets captured. If one of your experiments
    fails horribly, you can use the same "dd" command, to put
    the drive back as it was before.

    dd if=disk0_backup.dd of=/dev/hda

    Once you have at least one of the disks copied, you can
    go into the RAID BIOS of your new motherboard, and examine
    the array status. If the disks are claimed to not be
    members of an array, you can make them into an array.
    For a mirror, the rebuild process should copy one
    disk (the "master") to the other disk, and then
    declare the array is fully functional. Since you haven't given
    any indication the mirror is "broken" or there is damage
    to either of the disks, my assumption is, you don't really
    have a preference as to which disk is used as master.

    If you examined the disks, while booting something like
    a Linux LiveCD (Ubuntu, Knoppix, or the like), and found
    one of the disks had a damaged file system, then you'd
    probably take more care with which disk is the "master".
    If I had concerns, I'd probably erase the "bad" disk with
    DBAN, so nothing is left to the imagination with regard
    to the second drive. Sometimes, it is hard to have
    a good and unique identifier, to separate one disk
    from the other. (Look for a serial number, for example,
    and perhaps you can tell them apart that way. Maybe
    the serial number will appear in the RAID BIOS screen.)

    The thing is, the RAID driver currently sitting in your
    install, should be ready to work with the new motherboard.
    I think the same file is downloaded from MSI, for the two
    motherboards you name. And that is why this should "just
    work". So once the array status is fixed up, and you have
    a mirror with exactly the same parameters as before, the
    thing should just "boot and take off".

    As long as you have backups, and thoroughly understand
    your backup software, there is nothing to worry about.

    This brings up another of my favorite topics. Any time
    you decide to use RAID, you should experiment with how
    to do "maintenance" on the array. For example, "bust" the
    array on purpose, while there is nothing of value on it.
    Attempt to repair the array, delete the old array,
    create a new array, and see if the data is preserved or
    not. To make the experiment more realistic, you can erase
    one of the disks with something like DBAN, to simulate
    the presence of a replacement disk drive, suitable for
    rebuilding the array. Once you have some experience using
    the RAID BIOS commands, and come to trust them, then the
    above description won't be quite so scary. One of the
    reasons I have to give the warnings about backups, is
    to compensate for the "fear factor" of facing a broken
    array, and not really trusting the RAID BIOS screen to
    do the job. That is why experiments in advance,
    and practice "fire drills", make repairs like this
    second nature.

    That's my best guess,
    Paul
     
    Paul, Jun 2, 2010
    #2
    1. Advertisements

  3. tcp_ip_newb

    tcp_ip_newb Guest

    The RAID BIOS shows the array, but under "boot", it says
    "N/A". The array is shown as "healthy" even though I've been
    using the SATA0 drive for several weeks as an IDE drive with
    the SATA1 drive showing up as drive D and virtually unused.

    When I hit <enter> to display the details, both disks show
    up properly on that screen.

    Thanks for answering.
     
    tcp_ip_newb, Jun 3, 2010
    #3
  4. tcp_ip_newb

    Paul Guest

    For what it's worth, this guide has a couple RAID BIOS screen shots.
    I think they're supposed to include a manual similar to this, on
    the motherboard CD somewhere. I had trouble finding one of these
    for download, so you would not want to lose the motherboard CD.

    Nvidia RAID User's Guide NVRAID 2.0

    http://h50146.www5.hp.com/lib/doc/manual/workstation/hp_workstation/c00379550/c00379550.pdf

    *******

    In a thread here, some of the posters had a problem with the
    "boot" option in the RAID BIOS screen. They were not able to
    make their array marked as bootable.

    http://forums.nvidia.com/lofiversion/index.php?t36862.html

    This is purely a guess on my part. Setting the RAID "boot flag",
    means the RAID BIOS should consider registering the array as
    an Extended Int 0x13 option for the popup boot menu. For
    example, somewhere in your main BIOS screen, you set the boot
    order. Normally, every storage device would be a candidate
    for the boot order (or perhaps offered in a BIOS popup boot
    menu). I don't think the intention of the RAID boot flag,
    has to do with the MBR. The array you create, is a
    "virtual disk", and should be able to hold multiple
    partitions. The MBR of the virtual array (sector 0), should
    have its own boot flag per partition, and it would also
    be possible to not mark any of the MBR entries with the
    0x80 boot flag.

    So the reason you'd want to set the boot flag in the RAID BIOS
    screen, is so the array will be listed as a candidate in the
    boot order. If it isn't listed as an item in the boot order,
    then perhaps you won't be offered an opportunity to boot from it.

    Now, that forums.nvidia.com thread, doesn't have a solution to
    the problem. They can see a greyed out "Set boot" option.
    The interface design is such, that you define the array first,
    and using the "Set boot" in the RAID BIOS, is a separate step.
    And that means, it should be offered to you as an option any time
    you want it. It isn't like it is some option you forgot at
    original definition.

    The advice here, is to ignore that boot flag. As long as the
    array shows up in the Boot priority BIOS settings area,
    you're OK.

    http://forums.nvidia.com/index.php?showtopic=13944&st=0&p=129481&#

    ( http://forums.nvidia.com/lofiversion/index.php?t14169.html )

    Something is still not right about the state of your disks, and
    what you're seeing in the Nvidia RAID BIOS screen. I mean, you
    should see an array declared in the RAID BIOS screen. If
    you were to go to Windows Disk Management (diskmgmt.msc),
    the array should show up as a virtual "Disk 0". You
    could have four primary partitions on there if you wanted,
    with one of them set as the boot partition.

    When you say you see a "C:" and a "D:" as in two separate
    partitions in the OS, are the contents of the disks the
    same ? Or are they radically different. For example, your
    mirror array might be working, but have two partitions on it.
    In Disk Management, it would look like this.

    +---------+ +-----------+--------------+-----------------+
    | Disk 0 | | C: | D: | Unallocated |
    +---------+ +-----------+--------------+-----------------+
    Basic
    xxx GB
    Online

    Since it is a mirror, it means each of the two disks, has a copy
    of the partitions, like this. This would be the physical contents
    of the two mirrored disks, used to make that "virtual" disk in
    the above Disk Management example.

    +-----------+--------------+-----------------+
    | C: | D: | Unallocated | Physical disk 0
    +-----------+--------------+-----------------+
    +-----------+--------------+-----------------+
    | C: | D: | Unallocated | Physical disk 1
    +-----------+--------------+-----------------+

    If you're seeing the following in Windows, it would imply the OS is no longer
    using the RAID driver. Since you've enabled the RAID BIOS in the
    BIOS setup screen by enabling RAID, that should cause the RAID BIOS
    module to load at POST. And when Windows tries to boot, the
    VEN/DEV should match a RAID driver and not a regular SATA driver.
    If for some reason, the RAID driver isn't loading in Windows, maybe
    then you'd see this in Disk Management.

    +---------+ +-----------+--------------+-----------------+
    | Disk 0 | | C: | Unallocated |
    +---------+ +-----------+--------------+-----------------+
    Basic
    xxx GB
    Online

    +---------+ +-----------+--------------+-----------------+
    | Disk 1 | | D: | Unallocated |
    +---------+ +-----------+--------------+-----------------+
    Basic
    xxx GB
    Online

    In the BIOS setup screen, where you have the option to "Enable RAID",
    have you enabled RAID on all the RAID disks. In a Foxconn manual for
    your chipset, I see this kind of menu in the BIOS screen. You'd want
    at least three "enables" here, so the drives would be checked for
    their metadata.

    RAID Enable [Enable]
    SATA 1 Primary RAID [Enable]
    SATA 1 Secondary RAID [Enable]
    ...

    If what you're seeing is the two separate disks (Disk 0, C: and
    Disk 1, D:), then the question is, why has Windows used what looks
    like a regular SATA driver, rather than the RAID driver that had been
    installed with the previous motherboard ?

    I'm no RAID wizard here, I'm just working through the logic of the thing.

    Paul
     
    Paul, Jun 3, 2010
    #4
  5. tcp_ip_newb

    tcp_ip_newb Guest

    The second scenario is what's happening. If I unplug the second
    drive (SATA 1) before turning on the computer, all that I see in
    Windows is Drive C:
    I'll look for the 3 enables. That is new to me. I didn't see
    where they were available just in passing. I only found the first
    one.

    Again, thanks for the help.
     
    tcp_ip_newb, Jun 10, 2010
    #5
  6. tcp_ip_newb

    tcp_ip_newb Guest

    My CMOS BIOS only allows setting the RAID to "RAID" or "IDE".
    The second 2 enables aren't available either in CMOS nor
    RAID BIOS. "RAID enable" is not there. In the RAID BIOS,
    the array shows up as "healthy" (although that's not possible
    at this point: C: has been added to while D: has been untouched).
    When I press "ENTER to see details", both disks show up as RAID
    but it is an info-only screen: the only option is to "Hit ENTER
    to Return".
    Incidently, the first page of the RAID BIOS even tells me that
    it is a mirroring array.

    So I return to the original question: how do I install the new
    RAID drivers over the old ones without reinstalling Windows XP
    which I can't purchase anymore?

    Again, many thanks for answering.
     
    tcp_ip_newb, Jun 10, 2010
    #6
  7. tcp_ip_newb

    Paul Guest

    I can think of a couple things to check first.

    Look for the "setupapi.log" file on your C: drive. It shows newly
    detected hardware, and the response in the way of drivers. The
    file "rolls over" and the OS starts a new one, so you may see
    several of those files.

    The RAID download from the MSI site, is the same for both those
    motherboards. 3,078,697 bytes.

    http://download2.msi.com/files/downloads/dvr_exe/NVIDIA_MCP61_sataraid_XP.zip

    Inside the WinXP/sataraid folder, I can find nvrd32.inf .

    When the OS has a driver installed, the example of an INF
    there, is anonymized as something like "OEM23.inf". If
    you look in the INF folder, you'll see a collection of
    OEM items, and they're the result of driver installations.

    So in principle, if you do a text search in that folder, one
    of the OEMxx.inf files should match the nvrd32.inf .

    When you look in nvrd32.inf, you'll see lines like this. A portion
    of this text, would be suitable in a text search of the INF folder.

    %NVSTOR_DESC%=Crush11_Inst,PCI\VEN_10DE&DEV_03F6&CC_0104

    The CC thing is a "Class Code", as defined in the ACPI spec.
    I presume somewhere, the various numbers are documented.
    It would seem that "0104" stands for RAID, while "0106"
    might be AHCI. Not really sure though.

    The other part, the VEN and DEV, is Plug and Play bus
    information. Each "PCI bus" device has a VEN and DEV.
    That includes the controllers inside the chipset.
    And those numbers, if there is a "hit" in an INF, help
    determine what driver to load. The "setupapi.log" file
    records the installation of a driver (or reinstallation,
    in cases where a user has been flicking controls on and
    off in the BIOS).

    Other interesting parts of that INF file, include down
    near the end, where there is mention of a "Service" being
    installed. Now, if you managed to disable a service like
    that, chances are your OS would be dead in the water.
    A program like Sysinternals Autoruns could possibly be
    used to disable one of those "services", but then you'd be
    screwed, as far as I know.

    And that's the part that doesn't make sense to me.
    Normally, systems *hate* driver changes, like SATA to RAID,
    or RAID to SATA, and you'll get an error at bootup, stating
    the system disk can't be accessed. The Plug and Play should
    have helped prevent the system from changing from one
    driver type to the other.

    If you use a tool like the free version of Everest, you can
    investigate the various VEN/DEV values of devices on the
    bus. What you're looking for here, is whether there is
    something like

    VEN_10DE&DEV_03F6&CC_0104

    being declared by the hardware or not. The "setupapi.log" file
    should also help you in this regard. Between the values
    in Everest, the setupapi.log file, the OEMxx.inf files,
    you may be able to figure out what is going on.

    (Last free Everest - the latest version can be purchased from Lavalys.com)

    http://majorgeeks.com/download4181.html

    *******

    So, say you're sitting in the OS right now. You think a
    "non-RAID" or nvstor driver of some sort is running.
    You download a Mediashield driver and try to install
    it. The theory is, the VEN/DEV/CC value would not
    match the value in the driver, and the driver would
    refuse to install. That's why I can't just say to you

    "why don't you reinstall the driver"

    I have no faith that is going to work. You can certainly
    try it, but based on the fact your system seems to be
    running in a non-RAID mode, I don't see a reason for that
    to do anything good.

    The above 3,078,697 byte download I mentioned, is for
    an F6 floppy to be used while Windows is being installed.
    It has a SATA_IDE and a SATA_RAID folder. Each folder
    has its own TXTSETUP.OEM file. That file is normally
    at the root level of an F6 floppy, which is a way of
    telling you, you'd copy the contents of the SATA_RAID
    folder to a floppy, such that there are about 30+ loose
    files on the floppy.

    That is not a suitable installer for installation while
    you're in Windows. So that download is not the one to
    use to experiment with installing Mediashield.

    If I look at a random example of a chipset driver package
    from Nvidia, I see things like this listed as being a
    component part of the package. One of those chipset driver
    packages should be on your motherboard CD. If you want
    to download one, they can be many times the size of a
    focused one for your chipset. I've seen some "jumbo"
    packages, supporting many OSes, that are 200 or 300MB.
    (Note - this isn't the one you want necessarily, it's
    just the first example I could find. Your chipset is part
    of the MCP61 family.)

    http://www.nvidia.com/object/winvista_32_15.08.html

    This WinXP 32-bit nForce UDA driver package for
    MCP51, MCP61, MCP72, MCP73, MCP78, and MCP7A consists <--- MCP61
    of the following components:

    * Ethernet Driver (v67.58) "WHQL"
    * Network Management Tools (v67.61) "Sedona"
    * SMBus Driver (v4.60) "WHQL"
    * Installer (v5.62)
    * SataRAID Driver (v9.95) "WHQL" <----- Driver
    * SataIDE Driver (v9.95) "WHQL"
    * RAIDTOOL Application (v9.99) "Sedona" <----- Raid Management ?
    * SMU Driver (v1.31) "WHQL"

    OK, I just finished downloading this chipset package from MSI. 165,592,423 bytes

    http://download2.msi.com/files/downloads/dvr_exe/mcp_x32_mb.zip

    I suspect the SataRAID Driver and RAIDTOOL are in the
    IDE folder. The RAIDTOOL is stored in RAIDTOOL.cab .
    The overall installer (Installshield ? - I can't open it),
    probably has "tick boxes" for controlling the drivers
    you want to install.

    If you want to find the latest, go to the Nvidia download page.
    I think this is the one you'd want for your board. I'm assuming
    WinXP in this example.

    http://www.nvidia.com/Download/index5.aspx?lang=en-us

    Legacy

    nForce 4 Series

    nForce 430 / GeForce 6150SE

    Windows XP

    English (US)

    and that will offer a 162MB chipset package similar to the
    MSI one.

    # SATARAID Driver (v10.3.0.46) WHQL
    # RAIDTOOL Application (v10.3.0.46)
    # Installer (v6.69)

    As always, you should have a "backup", before performing brain
    surgery. Because your driver situation seems to be screwed up,
    I don't have a lot of confidence you won't be seeing a blue screen
    and a 7E on your next reboot.

    Good luck,
    Paul
     
    Paul, Jun 11, 2010
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.