Robert Locke wrote:
On Mon, 2005-02-28 at 15:46 -0500, Nat Gross wrote:I thought so, too. But I just mounted both (vfat and ntfs) partitions under FC3, and there is no boot.ini file. At this point I am certain that for some reason (maybe due to an earlier install of Windows) Windows kept the boot.ini on C, hda, and used that to boot from E.
Robert Locke wrote:
On Mon, 2005-02-28 at 15:18 -0500, Nat Gross wrote:
Robert Locke wrote:
On Mon, 2005-02-28 at 14:06 -0500, Nat Gross wrote:
Robert Locke wrote:
On Mon, 2005-02-28 at 13:18 -0500, Nat Gross wrote:
<snip>
I guess you need to define which "partition" contains the "WINDOWS" directory. That is the one that you would be "booting" from. So is that on hdb1 or hdb5.....
But I must admit that my Windows boot process knowledge is getting mighty rusty, now that I use VMWare to run it.
As I recall, the Windows bootloader is mighty cheesy.... It simply pointed to the first sector of the "active" partition.... I wonder if playing with hide and unhide in grub might help. Can you hide a whole drive or just a partition, haven't had to do one myself? But that way you might be able to allow Windows to think it is the only drive again which is perhaps what it is expecting? Windows may be trying to interpret the first drive's partition table and getting itself confused as it tried to boot....
Grub intercepts the boot.
Well, that's open for a little interpretation....
chainloader is essentially just passing control back to Windows to boot
itself.
Oh.
One minute. So, the boot.ini might have been on C:?<gasp>The Windows MBR component is what is replaced/intercepted by GRUB. But the chainloader line is execute sector +1 on the rootnoverify line. Generally Windows has historically held the NTLDR executable there that then reads the boot.ini file and performs it's boot.....
On the other hand, it should not be too hard to write a boot.ini, if I recall correctly from my last win crash. But, where should I stick that file? Or, maybe I should try to mount the the ntfs partition (via the 3rd party driver) just to look for boot.ini...
<sigh>
Mr. Gates, I ain't going back to you!!!! (after I'm thru with this.)
-nat
I would think that it would be on the partition that you are booting Windows from, which I presume is hdb5, which houses the boot.ini....
Presuming that hasn't been changed...
So, perhaps the bigger issue is that did we (Linux/anaconda) re-writeSince I can mount all the partitions under fc3, and the files look a-ok, I don't think fc3 caused any problem.
your partition table to confuse Windows.
After all, I told the installer to format hda (since I assumed that all win boot stuff is on the second drive.
This has happened in the past,
but was with FC2. But have you changed any BIOS parameters related to
LBA (Logical Block Addressing) since you last booted Windows
successfully?
No.
Perhaps Windows interpretation of the drive size and what is written in the MBR of the second drive are confused, and that might be affected by the Fedora/anaconda installer or by changes in the BIOS related to how to interpret CHS (Cylinders, Heads, Sectors)....
One other thought... have you moved the drive? Was it originally the
primary drive but now you have moved it to be secondary? That might
account for a confused boot.ini file.....
Nope. Hardware, bios, etc., untouched.
I do. It's not fun, and would only use it on a dual boot system if in real emergency.I have heard of a recovery console available from Windows XP but do not have any direct experience with it
(I always equated it with "linux rescue"). You could also try to boot one of the Live CDs that includes the NTFS driver to at least view the boot.ini, but I wouldn't try to launch it in writable mode. For that you want to figure out the Windows Recovery Console.
One key question is, does grub require that I make hdb5 bootable?
I'm off for the next several hours, but good luck...<sigh> and I'm off *after* that. But, hey, I have the data, so I guess I can wait.
--Rob
Thank you! -nat
