On Mon, 2005-02-28 at 15:46 -0500, Nat Gross wrote: > 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. > > >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..... > > > > > > > One minute. So, the boot.ini might have been on C:?<gasp> > 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-write your partition table to confuse Windows. 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? 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..... 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. I'm off for the next several hours, but good luck... --Rob
