Post by AntPost by AntPost by AntPost by AntWhen I boot it up, I quickly get this error: "Windows Boot Manager (text
I made a bootable Ubuntu and Windows 95 DOS separarely, and had no
problems using them. It seems like a problem with Windows 7 PE which is
so weird.
FYI, flash drives were formatted as FAT32 with whatever tools supplied.
Even Ubuntu and Windows 95's DOS were FAT32.
W7 PE was built from WAIK v3.0.
Ubuntu was built from
http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ ...
Windows 95's DOS boot was from
http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ tool
with an old 3.5" Windows 95 boot disk in A: drive.
Weird. I tried with 32-bit Vista b6000 RTM and it can't boot that
either.
http://images2.store.microsoft.com/prod/clustera/framework/w7udt/1.0/en-us/Windows7-USB-DVD-tool.exe
(help: http://store.microsoft.com/Help/ISO-Tool ).
Source: d:\w7rtm\minkernel\boot\environ\app\bootmgr\bcd.c
Line: 226
I don't even see this file. I assume WinPE boots it up, extracts,
and run it? Or maybe something else?
I haven't a clue what the problem is.
http://en.wikipedia.org/wiki/Bcdedit#Boot_Configuration_Data
Vista and Windows 7 use a "Windows Boot Manager", according to
that article. The reference to \Boot\BCD tells you what it was
up to, when the failure occurred. All OSes switch over, at some
point, from extended INT 0x13 for storage access, to some
other means. You'd need to research what the Windows Boot Manager
uses, and when.
http://en.wikipedia.org/wiki/INT_13#INT_13h_AH.3D0Ah:_Read_Long_Sectors_From_Drive
I've had problems before on my computers, that were BIOS related.
It had to do with how the boot order selection, affected the
way that drives are enumerated. Then, the OS would make a poor assumption,
using the BIOS "dynamically assigned" drive identity as if it was
absolute. The end result on one computer, was an attempt to install
Linux, caused the wrong disk to have Grub written to it. (I had to
"fixmbr" to correct it later.)
I had another case, where I used Grub on a floppy, to boot Debian stored
on a disk partition. Grub would fail, unless I went into the BIOS, and selected
a particular hard drive as the drive to boot from. Even though, the BIOS is
booting from a floppy, the hard drive selection in the BIOS still was affecting
the drive enumeration. I was also able to edit Grub, and change some
number in the command in there, and succeed at booting that way. But
I would have to randomly try numbers until I succeeded, one way or
another.
The only reason I'm bringing up that behavior, is I have a suspicion
the Windows Boot Manager is attempting to access the wrong drive,
looking for \Boot\BCD. So rather than this being a problem with the
device you've prepared, it has something to do with how storage
access is handled. To me, it seems the BIOS writers are overly clever,
and seem to be "outguessing" the OS people. And then the OS falls
for it, and ends up grabbing the wrong disk.
It is bad enough on some of my LiveCDs, that I actually have to use
a command line option to tell it where the CD is. Even though the
stupid thing begins booting from the CD just fine - at some point
it loses its mind. By adding a "fromhd=" type option, I'm able to
get it to boot fully. So there is some lack of agreement between
what the BIOS is doing, and what the OS thinks it is doing.
And I can't give you a sure-fired recipe for fixing it. All I
can suggest, is the problem has to do with the boot options in
the BIOS. It could even be, that Award and AMI handle this
issue differently, so perhaps not everyone is seeing this.
Since I just changed motherboard recently, all of my hacks have
been undone. For some of my LiveCDs, I'm going to have to go
through all the "/dev/hda1" type references, until I stumble
onto the right handle to use to make them boot. Some of my older
LiveCDs, boot without all this drama. It is the more recent ones
that have a problem.
Good luck,
Paul