Dual boot issues

[type11969]

I got it to work!! Both XP and RT work using the bios switch. I never thought I would be so happy to see the windows login screen. Honestly I am not sure what all I had to do to get it to work but I can tell you what I did. Biggest thing was copying files over to the c: partition that were missing. Again, windows is installed on D:, labview RT is on C:, and the CD drive is G:. I was never able to get bootcfg to work through the XP repair console . . . it always kicked up an error. If I tried to use list under bootcfg it did not find anything.

So I used:

fixmbr (ignored the warnings of doom)

fixboot 😧

copy G:\i386\NTLDR C:\

copy G:\I386\NTDETECT.COM C:\

This got me closer but I realized at this point that I had no boot.ini file. I created one using this text:

[boot loader]
timeout=10
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

Saved it as boot.ini, transfered it over on my USB stick using

copy F:\boot.ini C:\

After this I still could not use bootcfg, didn't think starting it up anyway would work but since I was at a loss I restarted. Boom, windows startup screen! Everything is still there. Ahhhhh, brilliant. Labview RT boots up if I use the software switch in the bios, everything is good.

Thanks everyone for your help . . . now on to why my .VIs will not work when I deploy them to the PXI.

-Chris

[type11969]

Casey-

     Thanks for your help. I have the windows problem sorted now, hooray. The reason I used the USB utility tool was because even with the PXI booted in to labview RT, I could not communicate with it through MAX. I was only able to communicate with it once I installed software from the utility tool. Maybe I was missing something simple, at least it is finally sorted out now!

-Chris

[Caseyw]

Great to hear Chris!

Please let me know if you have any additional issues connecting to your PXI system from MAX. I highly recommend that you use the BIOS to boot LabVIEW Real-Time on your PXI system. You will want to make sure that the IP Reset switch isn't being used, and that your host PC isn't blocking signals from your PXI system with a firewall.

Best Regards,

Casey Weltzin

Product Manager, LabVIEW Real-Time
National Instruments 

Message Edited by Caseyw on 01-08-2010 02:58 PM

[type11969]

Casey-

     The "solution" is a few posts up. Unfortunately, as I mentioned in that post, I am not sure exactly which things I did that were necessary to solve the problem. But I know that copying those files was absolutely necessary.

     Additionally, I found out that the issues I was having with running my .VIs on labview RT was due to using 4gb of ram in the PXI. I dropped it down to 2gb and the .lib deployment issues I was seeing disappeared. 

Thanks again,

Chris

[Josh_KNH]

Chris -

Glad to hear that your problem is fixed.  I think that the reason you had to copy the bootloader files (NTLDR, etc) to your C: partition is because that partition is still flagged as the active partition.   It's likely that those files also exist on your 😧 Windows partition, but since that's not the active partition, the repaired MBR wouldn't attempt to load them from there.

Basically, when you formatted with the RT USB key, the following actions occurred:

(a) RT partition was formatted

(b) Master boot record was updated with the RT-specific version

(c) Partition table was not clobbered but it was updated to set the active partition to the RT partition ("C:") instead of Windows ("D:").

Step (a) doesn't break anything with Windows.  Step (b) and (c) did break your Windows boot.  You essentially fixed (b) with FixMBR, and you worked around (c) by copying the Windows bootloader files onto the active partition.  The Windows boot loader doesn't need to be on the same partition as Windows because it's just going to use whatever it finds in the boot.ini file.

The only reason I bring this up is that if in the future you need to wipe the RT partition, it could break Windows again.  You can prevent this by resetting the 😧 partition to be the active partition like it originally was using any number of tools.  The tool I mentioned in my previous post - MBRWizard can do this.  You can also use that tool to dump out information about the current state of your MBR / partition table to verify the correctness of my speculation.  Also from within Windows you can verify that the bootloader files do in fact exist on your Windows partition already.

I can certainly understand not wanting to mess with it now that it's working again, but changing the active partition back and forth is pretty safe, and less complex than the other hoops you've had to jump through so far!  At the very least, hopefully this clarifies why you had to go through those extra steps to repair your system.

Cheers,

JoshH

Message Edited by JoshH on 01-15-2010 02:06 PM