Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results. The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
Thank you -nat
Nat Gross wrote:
I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops.
What normally happens when you install Windows into a drive other than C: is that it puts virtually everything where you asked it to, except for its bootloader, which it puts on C:
So you've probably trashed its bootloader. You'll probably need to create a (small) partition on the first drive that Windows can write to (i.e. FAT or NTFS), make it bootable, and use the XP recovery console to reinstall the bootloader into that partition. As for your FC3 install, I'd re-do it once Windows is happy.
Wait for other suggestions too though; this isn't something I've attempted and others may have better ideas.
Paul.
On Mon, 2005-02-28 at 13:18 -0500, Nat Gross wrote:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results. The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
Thank you -nat
You might want to try hdb1,4 on the rootnoverify line.
My rationale is the idea that your machine was booting from drive "e". Also note that the fdisk output of hdb5 being the ntfs based partition while hdb1 is the FAT32.
By the way, the hd nomenclature is "drive number","partition number" and both start counting from zero. So your first partition would be hd1,0 the FAT partition and hd1,4 would be the ntfs partition. hd1,1 does not actually hold any data, it is an artifact of decisions that MBR partition tables can only define four partitions. So turn one in to an extended partition that can then be divvied up into additional logical partitions.
HTH,
--Rob
Robert Locke wrote:
On Mon, 2005-02-28 at 13:18 -0500, Nat Gross wrote:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results. The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
Thank you -nat
You might want to try hdb1,4 on the rootnoverify line.
I get: Error 18: Selected cylinder exceeds maximum supported by bios.
My rationale is the idea that your machine was booting from drive "e". Also note that the fdisk output of hdb5 being the ntfs based partition while hdb1 is the FAT32.
The reason for this is that once upon a time, Win did in fact use drive C: as its home drive, and the second drive was 'extra'. Then one day, that install of win crashed and burned and cost me two weeks, (and I switched to Linux on my other machine), so when I re-installed Win, I used my second drive as the main guy, and just left drive C:, waiting for Linux.... And here I am.
By the way, the hd nomenclature is "drive number","partition number" and both start counting from zero. So your first partition would be hd1,0 the FAT partition and hd1,4 would be the ntfs partition. hd1,1 does not actually hold any data, it is an artifact of decisions that MBR partition tables can only define four partitions. So turn one in to an extended partition that can then be divvied up into additional logical partitions.
It's interesting that Grub automatically detected the second drive (although the first one had been formatted). I'm wondering if I need to make the ntfs partition 'bootable'. If so, where. Thank you much. -nat ps. To Paul. Your suggestion is (as you say) last resort. Hope I can get it to boot into Win, even from cd, since FC will likely be the main os on this machine as well. (My other machine, is FC3 only.)
HTH,
--Rob
On Mon, 2005-02-28 at 14:06 -0500, Nat Gross wrote:
ps. To Paul. Your suggestion is (as you say) last resort. Hope I can get it to boot into Win, even from cd, since FC will likely be the main os on this machine as well. (My other machine, is FC3 only.)
Actually the last resort might be to reinstall/upgrade Windows, which should result in it putting a bootloader on the first available partition it can write to, which would be your E: drive I think.
Paul.
Paul Howarth wrote:
On Mon, 2005-02-28 at 14:06 -0500, Nat Gross wrote:
ps. To Paul. Your suggestion is (as you say) last resort. Hope I can get it to boot into Win, even from cd, since FC will likely be the main os on this machine as well. (My other machine, is FC3 only.)
Actually the last resort might be to reinstall/upgrade Windows, which should result in it putting a bootloader on the first available partition it can write to, which would be your E: drive I think.
Paul.
The problem with a re-install of Windows is, that my original MS cd is pre-sp2 - sp2 was done via the net. Which renders the original cd useless. (According to an article in pc-mag.)
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:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results. The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
Thank you -nat
You might want to try hdb1,4 on the rootnoverify line.
I get: Error 18: Selected cylinder exceeds maximum supported by bios.
My rationale is the idea that your machine was booting from drive "e". Also note that the fdisk output of hdb5 being the ntfs based partition while hdb1 is the FAT32.
The reason for this is that once upon a time, Win did in fact use drive C: as its home drive, and the second drive was 'extra'. Then one day, that install of win crashed and burned and cost me two weeks, (and I switched to Linux on my other machine), so when I re-installed Win, I used my second drive as the main guy, and just left drive C:, waiting for Linux.... And here I am.
By the way, the hd nomenclature is "drive number","partition number" and both start counting from zero. So your first partition would be hd1,0 the FAT partition and hd1,4 would be the ntfs partition. hd1,1 does not actually hold any data, it is an artifact of decisions that MBR partition tables can only define four partitions. So turn one in to an extended partition that can then be divvied up into additional logical partitions.
It's interesting that Grub automatically detected the second drive (although the first one had been formatted). I'm wondering if I need to make the ntfs partition 'bootable'. If so, where. Thank you much. -nat ps. To Paul. Your suggestion is (as you say) last resort. Hope I can get it to boot into Win, even from cd, since FC will likely be the main os on this machine as well. (My other machine, is FC3 only.)
HTH,
--Rob
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....
That is pretty much my extent of help.... Perhaps others can provide more fruit...
--Rob
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:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results. The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
Thank you -nat
You might want to try hdb1,4 on the rootnoverify line.
I get: Error 18: Selected cylinder exceeds maximum supported by bios.
My rationale is the idea that your machine was booting from drive "e". Also note that the fdisk output of hdb5 being the ntfs based partition while hdb1 is the FAT32.
The reason for this is that once upon a time, Win did in fact use drive C: as its home drive, and the second drive was 'extra'. Then one day, that install of win crashed and burned and cost me two weeks, (and I switched to Linux on my other machine), so when I re-installed Win, I used my second drive as the main guy, and just left drive C:, waiting for Linux.... And here I am.
By the way, the hd nomenclature is "drive number","partition number" and both start counting from zero. So your first partition would be hd1,0 the FAT partition and hd1,4 would be the ntfs partition. hd1,1 does not actually hold any data, it is an artifact of decisions that MBR partition tables can only define four partitions. So turn one in to an extended partition that can then be divvied up into additional logical partitions.
It's interesting that Grub automatically detected the second drive (although the first one had been formatted). I'm wondering if I need to make the ntfs partition 'bootable'. If so, where. Thank you much. -nat ps. To Paul. Your suggestion is (as you say) last resort. Hope I can get it to boot into Win, even from cd, since FC will likely be the main os on this machine as well. (My other machine, is FC3 only.)
HTH,
--Rob
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.
That is pretty much my extent of help.... Perhaps others can provide more fruit...
--Rob
Thank you much, every iota of help is valuable. -nat
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. 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.....
--Rob
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
--Rob
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
Robert Locke wrote:
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...
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.
So, perhaps the bigger issue is that did we (Linux/anaconda) re-write your partition table to confuse Windows.
Since I can mount all the partitions under fc3, and the files look a-ok, I don't think fc3 caused any problem. 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 have heard of a recovery console available from Windows XP but do not have any direct experience with it
I do. It's not fun, and would only use it on a dual boot system if in real emergency.
(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
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote: <snip>
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.
This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
--Rob
On Tue, 2005-03-01 at 01:00 -0500, Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip> > 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. > This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
---- I'm coming in late in the game - NTLDR and BOOT.INI would normally be found in c:\ and they are invisible files - you wouldn't normally see them in Windows unless you set all files visible including system files.
If the 'C' drive was removed, then these files no longer exist.
You can boot Windows Install CD - go to recover console, and type "FIXBOOT"
should fix that problem
another option is FIXMBR but that might be a mistake if you want grub to chain the bootloader - remember though that grub should be chaining to the proper drive hd(?,0) and the ? is likely to be a number like 1 or 2 or 3 depending on how many hard drives are installed
Craig
Craig White wrote:
On Tue, 2005-03-01 at 01:00 -0500, Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
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.
This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
I'm coming in late in the game - NTLDR and BOOT.INI would normally be found in c:\ and they are invisible files - you wouldn't normally see them in Windows unless you set all files visible including system files.
If the 'C' drive was removed, then these files no longer exist.
You can boot Windows Install CD - go to recover console, and type "FIXBOOT"
should fix that problem
The problem is that Windows has been updated to sp2, rendering the original Win cd useless. -nat
another option is FIXMBR but that might be a mistake if you want grub to chain the bootloader - remember though that grub should be chaining to the proper drive hd(?,0) and the ? is likely to be a number like 1 or 2 or 3 depending on how many hard drives are installed
Craig
--On 1. marec 2005 11:14 -0500 Nat Gross natgross.rentalsystems@verizon.net wrote:
Craig White wrote:
On Tue, 2005-03-01 at 01:00 -0500, Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
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.
This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
I'm coming in late in the game - NTLDR and BOOT.INI would normally be found in c:\ and they are invisible files - you wouldn't normally see them in Windows unless you set all files visible including system files.
If the 'C' drive was removed, then these files no longer exist.
You can boot Windows Install CD - go to recover console, and type "FIXBOOT"
should fix that problem
The problem is that Windows has been updated to sp2, rendering the original Win cd useless. -nat
another option is FIXMBR but that might be a mistake if you want grub to chain the bootloader - remember though that grub should be chaining to the proper drive hd(?,0) and the ? is likely to be a number like 1 or 2 or 3 depending on how many hard drives are installed
Craig
Try the following change in your grub.conf: ----------- default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Pingo Linux root (hd0,0) kernel /vmlinuz-xxx ro root=LABEL=/ rhgb quiet initrd /initrd-xxx.img title Windows XP Pro map (hd0) (hd1) map (hd1) (hd0) rootnoverify (hd1,0) chainloader +1 makeactive boot ----------- It works nice for me.
Sasa
Sasa Stupar wrote:
--On 1. marec 2005 11:14 -0500 Nat Gross natgross.rentalsystems@verizon.net wrote:
Craig White wrote:
On Tue, 2005-03-01 at 01:00 -0500, Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
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.
This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
I'm coming in late in the game - NTLDR and BOOT.INI would normally be found in c:\ and they are invisible files - you wouldn't normally see them in Windows unless you set all files visible including system files.
If the 'C' drive was removed, then these files no longer exist.
You can boot Windows Install CD - go to recover console, and type "FIXBOOT"
should fix that problem
The problem is that Windows has been updated to sp2, rendering the original Win cd useless. -nat
another option is FIXMBR but that might be a mistake if you want grub to chain the bootloader - remember though that grub should be chaining to the proper drive hd(?,0) and the ? is likely to be a number like 1 or 2 or 3 depending on how many hard drives are installed
Craig
Try the following change in your grub.conf:
default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Pingo Linux root (hd0,0) kernel /vmlinuz-xxx ro root=LABEL=/ rhgb quiet initrd /initrd-xxx.img title Windows XP Pro map (hd0) (hd1) map (hd1) (hd0) rootnoverify (hd1,0) chainloader +1 makeactive boot
It works nice for me.
Sasa
If this works, you get promoted! Now, which portion of grub.conf are you referring to that I change? Do you have a similar setup with two drives, Linux on the first and Windows on the second? Thanks. -nat
--On 1. marec 2005 13:07 -0500 Nat Gross natgross.rentalsystems@verizon.net wrote:
Sasa Stupar wrote:
--On 1. marec 2005 11:14 -0500 Nat Gross natgross.rentalsystems@verizon.net wrote:
Craig White wrote:
On Tue, 2005-03-01 at 01:00 -0500, Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
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.
This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
I'm coming in late in the game - NTLDR and BOOT.INI would normally be found in c:\ and they are invisible files - you wouldn't normally see them in Windows unless you set all files visible including system files.
If the 'C' drive was removed, then these files no longer exist.
You can boot Windows Install CD - go to recover console, and type "FIXBOOT"
should fix that problem
The problem is that Windows has been updated to sp2, rendering the original Win cd useless. -nat
another option is FIXMBR but that might be a mistake if you want grub to chain the bootloader - remember though that grub should be chaining to the proper drive hd(?,0) and the ? is likely to be a number like 1 or 2 or 3 depending on how many hard drives are installed
Craig
Try the following change in your grub.conf:
default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Pingo Linux root (hd0,0) kernel /vmlinuz-xxx ro root=LABEL=/ rhgb quiet initrd /initrd-xxx.img title Windows XP Pro map (hd0) (hd1) map (hd1) (hd0) rootnoverify (hd1,0) chainloader +1 makeactive boot
It works nice for me.
Sasa
If this works, you get promoted! Now, which portion of grub.conf are you referring to that I change? Do you have a similar setup with two drives, Linux on the first and Windows on the second? Thanks. -nat
Yes. I have linux on first and winxp on second and each one with it'c own MBR but I but from linux and I can choose linux or winxp.
Sasa
Sasa Stupar wrote:
--On 1. marec 2005 13:07 -0500 Nat Gross natgross.rentalsystems@verizon.net wrote:
Sasa Stupar wrote:
--On 1. marec 2005 11:14 -0500 Nat Gross natgross.rentalsystems@verizon.net wrote:
Craig White wrote:
On Tue, 2005-03-01 at 01:00 -0500, Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
> 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. > > > This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
> One key question is, does grub require that I make hdb5 bootable? > > > So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
I'm coming in late in the game - NTLDR and BOOT.INI would normally be found in c:\ and they are invisible files - you wouldn't normally see them in Windows unless you set all files visible including system files.
If the 'C' drive was removed, then these files no longer exist.
You can boot Windows Install CD - go to recover console, and type "FIXBOOT"
should fix that problem
The problem is that Windows has been updated to sp2, rendering the original Win cd useless. -nat
another option is FIXMBR but that might be a mistake if you want grub to chain the bootloader - remember though that grub should be chaining to the proper drive hd(?,0) and the ? is likely to be a number like 1 or 2 or 3 depending on how many hard drives are installed
Craig
Try the following change in your grub.conf:
default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Pingo Linux root (hd0,0) kernel /vmlinuz-xxx ro root=LABEL=/ rhgb quiet initrd /initrd-xxx.img title Windows XP Pro map (hd0) (hd1) map (hd1) (hd0) rootnoverify (hd1,0) chainloader +1 makeactive boot
It works nice for me.
Sasa
If this works, you get promoted! Now, which portion of grub.conf are you referring to that I change? Do you have a similar setup with two drives, Linux on the first and Windows on the second? Thanks. -nat
Yes. I have linux on first and winxp on second and each one with it'c own MBR but I but from linux and I can choose linux or winxp.
Sasa
I tried this along with various variations, but still no go. A key difference I think, is that my second drive does not have an MBR. Also, the second partition of the second drive is the Windows HOME drive (E:). (This is why I also tried (hd1,4) .) Thanks, -nat
Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
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.
This is beginning to sound problematic and more of a Windows thing....
I am guessing that perhaps we would need to "repair" the Windows installation. Offhand, I am not sure how to do this and I think that it will most likely attempt to overwrite the MBR part of the first disk. This is not necessarily a huge problem in that a quick linux rescue followed by a grub re-installation of the first stage bootloader can correct the damage potentially done by the Windows repair....
<snip>
One key question is, does grub require that I make hdb5 bootable?
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I used the 'search for files' applet and turned on the hidden files option.
I think at this stage you may be looking to get some advice on how to repair the Windows partition unless someone else wants to jump in with advice on that side....
Agreed.
--Rob
Thanks again. -nat
On Tue, 01 Mar 2005 10:54:52 -0500, Nat Gross natgross.rentalsystems@verizon.net wrote:
Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip> >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.
[snip]
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I used the 'search for files' applet and turned on the hidden files option.
[snip]
--Rob
Thanks again. -nat
Hidden files in Linux are different from in Windows. Windows has a file attribute that makes a file hidden. In Linux, a file with a filename beginning with a dot "." is hidden. What you need to do is to just mount your windows partitions and then list the contents of each partition. For instance, if you mount your NTFS parition on /mnt/windows/E (this is not a required place, just an example), then open a terminal and type the command: ls /mnt/windows/E If you see ntldr and boot.ini listed in the output, everything is fine. You don't need to search for them as they are necessarily in the root of the partition (this is, they will not be in a folder). Similarly, do the same with your vfat partition, just in case. If you do not find it in either place, then you do have a problem and you will need to restore these somehow. Probably with the recovery console and FIXBOOT as already suggested.
Jonathan
Jonathan Berry wrote:
On Tue, 01 Mar 2005 10:54:52 -0500, Nat Gross natgross.rentalsystems@verizon.net wrote:
Robert Locke wrote:
On Mon, 2005-02-28 at 17:55 -0500, Nat Gross wrote:
<snip>
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.
[snip]
So to speak. GRUB is passing control to the NTLDR and BOOT.INI files. Remember that they are hidden/system files usually, so depending on how you tried to locate them might be why you did not see them (probably a pipe dream)???
I used the 'search for files' applet and turned on the hidden files option.
[snip]
--Rob
Thanks again. -nat
Hidden files in Linux are different from in Windows. Windows has a file attribute that makes a file hidden. In Linux, a file with a filename beginning with a dot "." is hidden.
Thanks for the tip.
What you need to do is to just mount your windows partitions and then list the contents of each partition. For instance, if you mount your NTFS parition on /mnt/windows/E (this is not a required place, just an example), then open a terminal and type the command: ls /mnt/windows/E If you see ntldr and boot.ini listed in the output, everything is fine. You don't need to search for them as they are necessarily in the root of the partition (this is, they will not be in a folder). Similarly, do the same with your vfat partition, just in case. If you do not find it in either place, then you do have a problem and you will need to restore these somehow. Probably with the recovery console and FIXBOOT as already suggested.
Jonathan
I have both Windows partitions mounted, and ntldr boot.ini is nowhere to be found. Furthermore, my previous search found a lnk(shortcut) file that I had named 'bootIniOnCdrive.lnk'! Evidently, after my previous Windows crash, I used that shortcut quite a bit! (That was [relative] eons ago.) Now, in case you are wondering, why I am not *really* paranoid; I have my data mounted on fc3 and usable (Java stuff). Also, I made the decision to re-align everything and go with Linux all-the-way. And for the minor stuff that I would like to boot Windows for, *maybe* it can wait for a cd from MS. (I don't trust the ntfs mount for writing.) And to let the great folks here in on a little secret, my drive C was already crashed (this time around too) and was hoping that the fc3 install/grub will not only give me fc3, but also the Win back. (if grub had ntldr-equivalent code....). whew! off my soapbox. Now, having said this, I am a little afraid to boot the Win CD and run FIXBOOT, because a)some win gurus say that since my system has sp2, the original cd is useless; and b) I want to be assured that it won't blow my fc3/grub away. (too much invested in this, this week.)
So, if I get your vote(s) and assurance that it won't hurt running fixboot, I'll go for it.
THANK YOU ALL. -nat
On Wed, 02 Mar 2005 14:00:28 -0500, Nat Gross natgross.rentalsystems@verizon.net wrote:
Jonathan Berry wrote:
Hidden files in Linux are different from in Windows. Windows has a file attribute that makes a file hidden. In Linux, a file with a filename beginning with a dot "." is hidden.
Thanks for the tip.
What you need to do is to just mount your windows partitions and then list the contents of each partition. For instance, if you mount your NTFS parition on /mnt/windows/E (this is not a required place, just an example), then open a terminal and type the command: ls /mnt/windows/E If you see ntldr and boot.ini listed in the output, everything is fine. You don't need to search for them as they are necessarily in the root of the partition (this is, they will not be in a folder). Similarly, do the same with your vfat partition, just in case. If you do not find it in either place, then you do have a problem and you will need to restore these somehow. Probably with the recovery console and FIXBOOT as already suggested.
Jonathan
I have both Windows partitions mounted, and ntldr boot.ini is nowhere to be found. Furthermore, my previous search found a lnk(shortcut) file that I had named 'bootIniOnCdrive.lnk'! Evidently, after my previous Windows crash, I used that shortcut quite a bit! (That was [relative] eons ago.)
Looks like you won't be able to boot Windows without using the recovery console.
Now, in case you are wondering, why I am not *really* paranoid; I have my data mounted on fc3 and usable (Java stuff). Also, I made the decision to re-align everything and go with Linux all-the-way. And for the minor stuff that I would like to boot Windows for, *maybe* it can wait for a cd from MS. (I don't trust the ntfs mount for writing.)
The new NTFS driver can only do limited writing, and anything it will do will *not* mess anything up, or that is what they say. It was rewritten to be failsafe, but as a result, it doesn't do a whole lot. You can change files as long as the size stays the same. If you need to change files and don't want to use Windows anymore, why not just move the files to a partition that you can write to? If you really don't want Windows, you can then reformat (after you are sure you have *everything* you might want copied elsewhere!!!) your NTFS partition to ext3.
And to let the great folks here in on a little secret, my drive C was already crashed (this time around too) and was hoping that the fc3 install/grub will not only give me fc3, but also the Win back. (if grub had ntldr-equivalent code....). whew! off my soapbox.
Huh? If your hard drive "crashed" (meaning that the drive failed or is beginning to fail) I would not trust it, get a replacement. If there is something wrong with the drive, it won't last no matter what OS you use. If you mean something else, please enlighten us. And no, GRUB cannot directly boot windows, it can only "chainload" ntldr.
Now, having said this, I am a little afraid to boot the Win CD and run FIXBOOT, because a)some win gurus say that since my system has sp2, the original cd is useless; and b) I want to be assured that it won't blow my fc3/grub away. (too much invested in this, this week.)
So, if I get your vote(s) and assurance that it won't hurt running fixboot, I'll go for it.
THANK YOU ALL. -nat
I'm not sure, but I don't think fixboot will touch the MBR. That is what fixmbr does. It should not hurt FC3 as I would think it should only touch the windows partition. Even if you had to run FIXMBR, or FIXBOOT did replace GRUB, you can easily re-install it (you should be able to find instructions with Google or the archives as this has been asked too many times already :)). I think this should be safe, just be sure you know which partition it wants to play with before you do it. I haven't heard anything about using an SP1 disk with an SP2 install, but I haven't looked for it. Could you provide links? I don't think you could make the situation worse, as at worst, Windows won't boot, and you're already in that boat :). If you have a way, back up all the data you want to save. Most things with computers can be undone (you may have to reinstall, of course) and data loss is the worst outcome (this is in general, I'm not making any specific comments about this situation). So if you save everything you might want, go ahead and give it a shot. The most you will lose is time, then :).
Jonathan
Jonathan Berry wrote:
On Wed, 02 Mar 2005 14:00:28 -0500, Nat Gross natgross.rentalsystems@verizon.net wrote:
Jonathan Berry wrote:
Hidden files in Linux are different from in Windows. Windows has a file attribute that makes a file hidden. In Linux, a file with a filename beginning with a dot "." is hidden.
Thanks for the tip.
What you need to do is to just mount your windows partitions and then list the contents of each partition. For instance, if you mount your NTFS parition on /mnt/windows/E (this is not a required place, just an example), then open a terminal and type the command: ls /mnt/windows/E If you see ntldr and boot.ini listed in the output, everything is fine. You don't need to search for them as they are necessarily in the root of the partition (this is, they will not be in a folder). Similarly, do the same with your vfat partition, just in case. If you do not find it in either place, then you do have a problem and you will need to restore these somehow. Probably with the recovery console and FIXBOOT as already suggested.
Jonathan
I have both Windows partitions mounted, and ntldr boot.ini is nowhere to be found. Furthermore, my previous search found a lnk(shortcut) file that I had named 'bootIniOnCdrive.lnk'! Evidently, after my previous Windows crash, I used that shortcut quite a bit! (That was [relative] eons ago.)
Looks like you won't be able to boot Windows without using the recovery console.
Now, in case you are wondering, why I am not *really* paranoid; I have my data mounted on fc3 and usable (Java stuff). Also, I made the decision to re-align everything and go with Linux all-the-way. And for the minor stuff that I would like to boot Windows for, *maybe* it can wait for a cd from MS. (I don't trust the ntfs mount for writing.)
The new NTFS driver can only do limited writing, and anything it will do will *not* mess anything up, or that is what they say. It was rewritten to be failsafe, but as a result, it doesn't do a whole lot. You can change files as long as the size stays the same. If you need to change files and don't want to use Windows anymore, why not just move the files to a partition that you can write to? If you really don't want Windows, you can then reformat (after you are sure you have *everything* you might want copied elsewhere!!!) your NTFS partition to ext3.
There is quite a bit of work to implement this paragraph. And I have to play it safe, just in case I remember some Win specific data/program I forgot about. Also, since I write Java software for a living (why'd you think I can just continue working of Linux with the same data), I need to have the ability to verify stuff (basically gui l&f) under Windows.
And to let the great folks here in on a little secret, my drive C was already crashed (this time around too) and was hoping that the fc3 install/grub will not only give me fc3, but also the Win back. (if grub had ntldr-equivalent code....). whew! off my soapbox.
Huh? If your hard drive "crashed" (meaning that the drive failed or is beginning to fail) I would not trust it, get a replacement. If there is something wrong with the drive, it won't last no matter what OS you use. If you mean something else, please enlighten us.
Not a hardware problem. The machine was not shutdown gracefully, and forgot how to boot properly.
And no,GRUB cannot directly boot windows, it can only "chainload" ntldr.
Now, having said this, I am a little afraid to boot the Win CD and run FIXBOOT, because a)some win gurus say that since my system has sp2, the original cd is useless; and b) I want to be assured that it won't blow my fc3/grub away. (too much invested in this, this week.)
So, if I get your vote(s) and assurance that it won't hurt running fixboot, I'll go for it.
THANK YOU ALL. -nat
I'm not sure, but I don't think fixboot will touch the MBR. That is what fixmbr does. It should not hurt FC3 as I would think it should only touch the windows partition. Even if you had to run FIXMBR, or FIXBOOT did replace GRUB, you can easily re-install it (you should be able to find instructions with Google or the archives as this has been asked too many times already :)).
Let me ask it again....just kidding.
I think this should be safe, just be sure you know which partition it wants to play with before you do it. I haven't heard anything about using an SP1 disk with an SP2 install, but I haven't looked for it. Could you provide links?
http://www.tek-tips.com/viewthread.cfm?qid=1013670 Also if you google 'slipstream sp2'. And I just reread that page. Recovery console will NOT run, after an sp2 upgrade. (unless you slipstreamed a new cd earlier.)
I don't think you could make the situation worse, as at worst, Windows won't boot, and you're already in that boat :). If you have a way, back up all the data you want to save. Most things with computers can be undone (you may have to reinstall, of course) and data loss is the worst outcome (this is in general, I'm not making any specific comments about this situation). So if you save everything you might want, go ahead and give it a shot. The most you will lose is time, then :).
Jonathan
Nat Gross wrote:
The reason for this is that once upon a time, Win did in fact use drive C: as its home drive, and the second drive was 'extra'. Then one day, that install of win crashed and burned and cost me two weeks, (and I switched to Linux on my other machine), so when I re-installed Win, I used my second drive as the main guy, and just left drive C:, waiting for Linux.... And here I am.
This may be the root of the problem.
I think this is what Windows XP does at installation. It scans for active partitions to see if there is another Windows installation. If it thinks it's found one it leaves it active as the default boot partition. Rather than install the bootloader info on the new partition it installs it on the existing, active, partition and configures it to include the newly installed Windows XP.
If you subsequently move the boot disk or overwrite that partition you lose your ability to boot Windows.
Is there a way to fix this? Not sure. Someone else suggested fixboot from rescue mode on the Windows XP CD. It's worth a try.
Nigel Wade wrote:
Nat Gross wrote:
The reason for this is that once upon a time, Win did in fact use drive C: as its home drive, and the second drive was 'extra'. Then one day, that install of win crashed and burned and cost me two weeks, (and I switched to Linux on my other machine), so when I re-installed Win, I used my second drive as the main guy, and just left drive C:, waiting for Linux.... And here I am.
This may be the root of the problem.
No no. The root of the problem is that even though I had this major Windows crash back then, I still went back to it! (i did switch my other machine to Linux though. Should have switched both.)
I think this is what Windows XP does at installation. It scans for active partitions to see if there is another Windows installation. If it thinks it's found one it leaves it active as the default boot partition. Rather than install the bootloader info on the new partition it installs it on the existing, active, partition and configures it to include the newly installed Windows XP.
If you subsequently move the boot disk or overwrite that partition you lose your ability to boot Windows.
This explains it, then.
Is there a way to fix this? Not sure. Someone else suggested fixboot from rescue mode on the Windows XP CD. It's worth a try.
I just hope that it wont blow grub (and drag fc3 with it) away. Thanks, -nat
On Mon, 28 Feb 2005 13:18:04 -0500, Nat Gross natgross.rentalsystems@verizon.net wrote:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results.
You are probably safe. I have seen Windows XP installed on G: and I: with nothing on C:. Unlike previous versions, this is perfectly fine for XP; the one on I: doesn't even have a real C: drive. It's occupied by a card reader :).
The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
It's not listed twice. hdb2 is the extended partition. It can hold multiple logical partitions, but you have just one. hdb5 is the sole logical parition in hdb2, so it looks like a duplicate. This is your problem, see below.
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
This should be rootnoverify (hd1,4) Like I said above, were trying to point it to the extended partition instead of the logical one that actually has the data. Now, you might run into a problem with trying to boot to an extended partition, but it if worked before, then it ought to work again. If not, let us know. You should be able to "repartition" it to where hdb2 is your XP partition. You don't need an extended partition in this case.
Thank you -nat
Hope this helps, Jonathan
Jonathan Berry wrote:
On Mon, 28 Feb 2005 13:18:04 -0500, Nat Gross natgross.rentalsystems@verizon.net wrote:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results.
You are probably safe. I have seen Windows XP installed on G: and I: with nothing on C:.
THIS is solid good news! Now, I recall during the fc3 install *somewhere* I had the option to make partitions bootable, and I selected hda and UNselected hdb. Can this be the problem?
Unlike previous versions, this is perfectly fine for XP; the one on I: doesn't even have a real C: drive. It's occupied by a card reader :).
duh!
The hardware is as follows: Dell Intel 1.6ghz, 768 meg ram, 2 hard drives, 20gig and 60gig. Disk info: hda: hda1 1-33, /boot, 259meg, ext3. hda2 34-164 swap, 1 gig hda3 165-2498, /, 18gig, ext3.
hdb: hdb1 1-3633, 28.4gig, fa32. (not mounted, or touched with Linux.) hdb2 3634-7299,28.7gig, Extended. ( ditto) hdb5 3634-7299,28.7gig,ntfs. (don't know why its listed twice. whatever.)
It's not listed twice. hdb2 is the extended partition. It can hold multiple logical partitions, but you have just one. hdb5 is the sole logical parition in hdb2, so it looks like a duplicate. This is your problem, see below.
Thanks for the clarification.
The /boot/grub/grub.conf: # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 blah title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-1.667.img title WinXP rootnoverify (hd1,1) chainloader +1 ========================= As noted above, I also tried rootnoverify (hd1,0) .
This should be rootnoverify (hd1,4) Like I said above, were trying to point it to the extended partition instead of the logical one that actually has the data. Now, you might run into a problem with trying to boot to an extended partition, but it if worked before, then it ought to work again. If not, let us know. You should be able to "repartition" it to where hdb2 is your XP partition. You don't need an extended partition in this case.
I tried this and Grub complained with error 18: Selected cylinder exceeds maximum supported by BIOS.
Thank you -nat
Hope this helps,
Yes!
Jonathan
TA -nat
Nat Gross wrote:
Hi; I installed FC3 on a WinXP-sp2 system, whose c: drive was NOT being used (for real), or so I thought. And gave the entire drive, hda, to FC3. I reasoned that since my winXP booted into drive E:, the second drive, hdb, Grub would have no issues with booting Windows. However, although it boots FC3 nicely, when I elect to boot xp, it displays 'rootnoverify (hd1,0) chainloader +1' and stops. Due to the partioning of hdb (as listed below), I have tried hd1,1 as well, with the same results.
<snip> Ok folks. We have a partial working solution! Boot from floppy. 1. You need a FLOPPY disk that has been formatted with xp. 2. Copy 3 files, ntdetect.com, ntldr, and boot.ini to it. (Verify the ini file is correct.) 3. Boot from floppy. voila! The Windows logo (from hard drive) appears in less than 8 seconds. Actually it works out better (for me now), when I want Windows, pop a floppy, no waiting to hit a key (catch grub timeout) and then choose xp.
THANK YOU ALL. -nat ps. I might be celebrating tonite, don't know if I'll respond tonight.