Tutorial on Boot.oss file and how to edit

Thanks for that info. It makes more sense now. However, how come the BOOTWIZ.OSS file didn't have the drive swapped? Was it because of various things you tried or do you have to make this change every time?

XP seems to be a lot less fussy about booting from other drives.

 

No once I set it it works ok from then on. Here are the Reg entries.

 

You drive letter assignments appear to be correct.

If it's not too much trouble, can you post the current BOOTWIZ.OSS file (with the correct settings for Vista32 to boot)?

I'll let you know what I find out on the tests.

 

Here you go. V32 boots with this one and the disk entry should be #1.

 

This is one thing I'm not understanding. Here are the disks as listed in the file (Disks #1-#6 as #128-#133). Disk #129 is the Vista32 drive.

Code:

	<disks>
		<id408505168 bios_num="128" crc="609700928" real_bios_num="128" serial="57147" size="976773167" />
		<id3966377343 bios_num="129" crc="488392058" real_bios_num="129" serial="16344" size="488397167" />
		<id2785510717 bios_num="130" crc="976761414" real_bios_num="130" serial="15871" size="976773167" />
		<id3456510135 bios_num="131" crc="766804970" real_bios_num="131" serial="12686" size="976773167" />
		<id3844003991 bios_num="132" crc="268641939" real_bios_num="132" serial="41414" size="488397167" />
		<id3570171770 bios_num="133" crc="209952014" real_bios_num="133" serial="7136" size="625142447" />
	</disks>

Here are the disk as listed for the Disk Order Vista32 entry:

Code:

			<disks>
				<disk bios_num="128" id="408505168" />
				<disk [B][COLOR="Red"]bios_num="129" id="3966377343[/COLOR][/B]" />
				<disk bios_num="130" id="2785510717" />
				<disk bios_num="131" id="3456510135" />
				<disk bios_num="132" id="3844003991" />
				<disk bios_num="133" id="3570171770" />
			</disks>

As you can see, the order is not changed. Does OSS still show the same "order" as in the screenshot in Post #15? That doesn't show any order change either.

---

Here is the Disk Order for the XP 64 entry. This one shows the XP 64 drive as the first drive (#12 and I assume that OSS also shows this when you look at the Properties of the XP 64 entry.

Code:

			<disks>
				<disk bios_num="133" id="408505168" />
				<disk bios_num="129" id="3966377343" />
				<disk bios_num="130" id="2785510717" />
				<disk bios_num="131" id="3456510135" />
				<disk bios_num="132" id="3844003991" />
				<disk [B][COLOR="Red"]bios_num="128" id="3570171770[/COLOR][/B]" />
			</disks>

 

I have duplicated part of the problem. However, several things are different in my tests:

• I used Vista Ultimate 32bit on three drives (haven't tested with XP on Drive 1)
• I copied the drives instead of restoring the Vista image
• I tested booting into each Vista by setting it as the booting drive
• I installed OSS from the DD CD
• I did the tests in a VM

OSS found all three Vista installations and setup the entries, including the Disk Order settings. However, any attempt to boot Vista 2 or Vista 3 resulted in Vista 1 booting. The solution was to simply uncheck the Disk Order feature.

You previously stated that that didn't work for you, so something is different there. Another difference is that bcdedit will pull up a BCD file when I don't use the /store parameter. It should be noted that in each case the BCD file pulled up is always the Vista 1 BCD file on the booting drive regardless of which Vista is currently booted.

In Post #4, I suggested installing Vista64 to its drive when it was the only drive connected and therefore the booting drive. In Post #7, you said that didn't work, but you didn't go into details. Why didn't it work? Vista64 should have installed normally to the drive just as it did to the XP drive? What went wrong?

Right now, I leaning towards using the imaging restore method as the possible culprit, though it could also be something different with Vista64. I don't currently have Vista64 so I can't run any tests. I'm curious if you tried to put another Vista32 in place of Vista64 if you'd have the same problems.

 

Sorry I'm late getting back, I hit the sack early(sometimes one of the shortcomings of being an "Old Fart").
RE: post #30
Oss always has to be set to Disk #1-( 128 ) for v32 to boot even though it is installed to Disk #2 as you said.
In the case of XP64 Oss is set to Disk#6-( 128 ) and it boots fine. I'm no guru so I haven't figured out the significance of the 128-133 designations because I don't know where they come from and where they figure in the overall scheme of things.The numbers above are what I see when I go to Properties in OSS for those entries.
RE: post #31
1) As I recall when I ran bcdedit in v32 from a command prompt, unless I used the/store parameter it said the command wasn't recognized as an internal command. I think I navigated to the root to execute it.
2) When I installed the v64 I went into the bios and disabled all drives but the one I wanted and it installed ok. In fact I can still set the v64 drive as number one in the bios and it still boots right up.
3) I restored V32 image to the former V64 drive. No matter How I config it in OSS it either hangs, Starts to boot and after the microsoft banner gives me the "autochk program can't be found" and reboots or boots up into the first version of v32 on Drive #2. In OSS the folders/files are different for each(ie: D: and E: )
Sorry I can't be of much help but I'm pretty much lost. If you're confused and would like to start over give me a list of what you need or need me to do in the order you want and we could go from there. I've attached the bootwiz.oss again in case it would be helpful. I am assuming that this file is used by the GUI for OSS to make everything happen.


Regarding the 128-133 designations, I understand that the drives need id's for the system and apps to work. What is the basic id and where does it come from and are the other id's(ie: <disk bios_num="130" id="2785510717" />)shown assigned by the apps and/or the system? if this is to complicated to answer in a sentence or two can you point me to info that explains the way it's done?

 

Not a problem. I was done for the night anyway.

Okay. That is consistent with my results.

XP boots differently than Vista.

I'm not a BIOS expert either. Whether the BIOS starts at number 128 or not really doesn't matter. What matters is the order of the numbers is the order of the drives as seen by the BIOS.

This still bothers me. You shouldn't get an error that the command is not recognized unless the path isn't found.

Okay. This means that Vista64 is working properly on its drive.

This seems to indicate that the problem is not releated to Vista32 vs. Vista64.

I've still got some thinking to do on this.

OSS uses this file to keep track of the disks, partitions and OS installations. OSS also "tags" partitions on the system with their info. This helps it adjust when changes are made.

As far as I know, OSS just uses a random number. It just needs a unique value to identify the disk, partition, os, etc. OSS then just matches an ID value to the BIOS disk number.

---

Would it be hard to do the following test? Put Vista64 back onto its partition and make sure it boots okay when set as the booting drive (as previously stated). Then enter the BIOS, disable the Vista32 drive and set the XP drive back as the booting drive. Now, boot back to OSS and check your Vista64 entry. Make sure it looks okay, uncheck the Disk Order option (if checked) and try to boot Vista64.

 

Will do and get back in awhile.

 

1) Changed bios to boot from V64, worked fine.
2) Disabled V32 in bios
3) Set XP as boot in bios
4) Checked V64 in Oss, all ok, unchecked Manual Order option
5) When I rebooted I got the following message

"Booting Windows Vista
ACPI Vista Loader 2.1.2
Done
Fallback 1
find__set-root /bootmgr"

It locked up there. I also tried to boot V32 from OSS with Drive disabled and got the same message.

 

I noticed something curious. Even with the V32 drive disabled in the bios it shows up in DD and "My Computer in XP? Is that normal?

 

No, the drive shouldn't show up. You may have to physically disconnect it.

Also, are all of the drives SATA? If so, are all using the same controller (some boards have four on one controller and two on another, for example)?

 

Here we go
1) The disable action in the bios must work because with the V32 drive disabled neither the V32 or V64 boot. I get the same message as posted in the second last post. With the Drive enabled I can boot to V32 and when I boot to V64 it also boots to V32 successfully.

2) The reason I didn't just unplug the drives is because I don't know which is which without tearing everything apart and doing a lot of experimenting and I'd like to avoid that if possible.

3) All drives are SATA. four of them are on the built in Nvidia NForce 4 controller on the MOB(including the #1XP and #2V32 drives), one is plugged into the ESATA socket on MOB using SI3132 controller which is built in, and the last one is plugged into a Standard Dual Channel card plugged into a PCI slot. XP64 is on one of the last two.
4) I don't remember the details of how they all got there because it's been working for quite a while and once I get hardware working I usually don't mess with it although I think I went to a PCI card to get all 6 drives SATA.

I think your probably correct in thinking that it is somehow related to the software side since the only system acting up is V64 other than the fact that V32 needs Disk #1 pointed to in OSS when it's installed on #2.

 

How about reinstalling both Vista installations onto the Vista32 drive?

If you try this, do the following:

1. Set the Vista32 drive as the booting drive.
2. Hide all other OS partitions on the other drives.
3. Install Vista32 on a Primary/Active NTFS partition.
4. Hide the Vista32 partition.
5. Setup the partition for Vista64 (Primary, Active, NTFS).
6. Install Vista64 to its partition.
7. Change the XP drive back to the booting drive and boot back to OSS.
8. OSS should pick up both the Vista installations.
9. Check the Disk Order option and turn it off on each one.
10. Do they boot?

If there are problems, you can try hiding the Vista partitions from each other.

I suggest reinstalling (not restoring images) as a test since you have your image backups and it may also clear up the problem with Vista32 not working correctly with bcdedit.

 

Will try tomorrow and let you know.

 

Before I begin the test I want to make sure I'm doing it correctly and some of it is a little confusing;

1) Create two partitions on drive

2) go to bios and set that drive as boot

3) boot into DD CD and set all other OS partitions hidden

4) make chosen Partition Prim-Act

5) install v32 to partition

6) boot back to DD CD

7) Hide V32 just installed and make other Part Prim-Act

8 ) Install V64 to the partition

9) go to bios and set XP to boot

10) boot to DD CD and set all Partitions to unhidden

11) Reboot and check OSS performance

If this is correct I'll proceed.

BTW does installing V32 first or V64 first matter?

 

You have the steps correct. It shouldn't matter which you install first. You may also want to have the Windows installer format the destination partition as part of the installation. Sometimes Windows will fuss at how DD formats them (this usually causes an error on the reboot during the installation).

 

Thanks, I'll get back when done.

 

Well I followed instructions and installed both systems, both booted ok when drive set to boot in bios and partition set active with dd. When I set boot in bios back to XP and tried OSS I can boot into V64(first system installed) but when I try to boot to V32 (second system installed I can only boot to V64. No matter how I try to set OSS for V32 It either will not boot or it will boot into V64. I've attached the Bootwiz.oss file as it now stands. I tried hiding the V64 part like you said but if I do That it starts to boot but like before after the microsoft banner I get the "autochk program not found...." message and it hangs. It appears to be exactly the opposite of what it was before ie: can only boot into first system installed.

 

I still haven't tested with XP on the first drive and I'm beginning to think that may be the problem. You're right that Vista is just booting the first installation it finds.

If you want to test it, what happens if you leave the booting drive as the Vista drive and then reactivate OSS? When you do this, make sure the XP drive is connected and running so OSS can find its installation.

 

I'm still not making progress. Thanks for all your time and effort I really appreciate it but it seems that at least in my case it doesn't like both V systems at once. I've decided to use one at a time, if necessary I can restore the other for use. The vast majority of the time I'd use XP anyway. Actually after all the playing around with this issue I've noticed that either v is way slower than XP and I'm not sure I'd want to switch permanently. Thanks again.

 

I have tested with XP on drive 1 and Vista on drives 2 and 3. I could still boot either of the Vista installations okay as long as the Disk Order feature was turned off (just as before). However, neither Vista installation could find the BCD file without using the store path (this is the same problem you had). To me, this seems to point to a Vista problem and how it's looking for the BCD file.

Hiding the XP partition results in Vista2 booting regardless of whether I selected Vista2 or Vista3. This is consistent with your results if I remember correctly.

Hiding the Vista2 partition (XP partition not hidden) and trying to boot Vista3 results in the autochk program not found - skipping AUTOCHECK error and the computer reboots after several seconds. To me, this make it seem like Vista3 is trying to boot correctly but it's actually using some of the files on drive 2 (Vista2's partition).

So... I am able to duplicate the problem with XP and Vista32 and since this is in a VM it pretty much eliminates your computer as the source of the problem (at least from a basic level).

It's been my experience that when using OSS, Vista likes to be on the booting drive. Putting it anywhere else may or may not work properly, especially if multi-booting Vista.

I'm going to try a different boot manager and see if I get the same results.

---

Are you using Vista SP1 for both your Vista installations? I forgot to ask before. I'm using SP1 so if you're not, that's another difference.

 

Yes I'm using SP1.

 

Well, I tested with BING and Grub4DOS and neither had any problems booting Vista2 or Vista3 with XP on drive 1. Swapping was not maintained (as with OSS), but it also didn't cause any problems (the correct Vista booted). Also, there were no problems hiding any of the non-booting OS partitions (the correct Vista booted).

I also did some "clean start" tests with OSS and was successful with hiding the other OS partitions and still have the correct Vista boot. I was not able to reproduce the autochk error with these tests so I'm guessing it was produced by switching from Vista1/Vista2/Vista3 to XP/Vista2/Vista3 instead of using the same "base" starting point.

I realize that none of this really helps you solve your problem, but it does seem to point to OSS doing something different with the booting process than how BING and Grub4DOS handle it.

 

In case I want to play around with this some more, what VM product do you use? I tried Vmware and it won't install on a Virtual Machine. Thanks