Grub HD install on SATA destroys Windows MBR?
Posts: 38
I previously installed 3.4.2-rc1 on an Athlon XP system with a single PATA drive, and while I had problems with starting x, it didn't do anything particularly strange, and dual-boot worked fine. BUT on my new Athlon 64 system, disaster!
I've just built a new system, an Atlon 64 with a Geforce 6150/nForce 430 (Foxconn/Winfast) mobo. Its main hard drive is a Hitachi Deskstar 160 GB SATA drive. But I also had an older PATA drive installed, to copy my old (retired) system's files from. The PATA drive had an old Win2k partition (from a previous computer) and a couple of Linux partitions.
I initially installed Windows XP Pro SP2 on a 20 GB system partition (/dev/sda1) on the SATA drive, without the PATA drive yet attached. (I always keep my data, and most programs, on a "D" partition.) It worked fine. I added the PATA drive, and it worked fine. Windows saw both disks and continued to boot from the SATA drive (C, D) while seeing the PATA drive (E, G).
Live-booting 3.4.2-rc1 didn't work too well -- the 6150's Ethernet and sound were missing, but nVidia posted a Linux driver for them. I really wanted kernel 2.6.14, not .12, because it should work better with new hardware, but figured it was worth a try.
Note that I also tried Kanotix, with 2.6.14, and it had the same problem. The Kanotix HD installer would not work at all -- its QTparted saw the PATA drive (hda) but didn't even see the SATA drive to partition it.
So I tried the MEPIS -rc1 HD installer. Its QTparted worked fine, allowed me to cteate three partitions (/, /home and swap) in the space I had left on /sda, and it installed to / just fine. But I discovered that it needed kernel sources to install the nVidia 430 driver, so I rebooted to Windows to get back to the Internet...
GRUB came up with the image background, showed me /sda6 (MEPIS), /hda2 (old Windows 2000), /sda1 (Windows XP, what I wanted) and /hda7 (an old Linux install). I selected Windows XP. GRUB then came right back with its own text menu. Selecting Windows did nothing. It wouldn't boot Windows XP at all.
I put in the Windows XP disk, booted the Repair Console, did FIXMBR and FIXBOOT, rebooted, and got the BIOS error NO SYSTEM DISK FOUND or whatever it says. Oh yeah, FIXMBR warned about a non-standard partition table.
I then tried a bunch of other things to get Windows to run, each time redoing FIXBOOT and FIXMBR. I deleted the Linux partitions. No go. I unplugged the PATA drive. No go. I did a repair-reinstall. No go.
Finally, I got Windows to install by doing a "new" install, creating a new /WINDOWS directory (blowing away the old one with the updates and drivers installed, as well as the registry). At least it left the D partition alone. So now I've got a semi-virgin Windows box again that I'll be re-finishing later. All because the HD installation tools in MEPIS did not like this configuration, and did something to the SATA MBR.
I suggest further testing before this goes into general release. Thanks.
I've had the same problem
Posts: 1109
I've had the same problem with Mepis with my Dell Dimension 8300.
If you try to install it, the MBR is trashed in such a way that Windows will no longer load.
The problem with mine seems to arise from the fact that the Dell Bios is not recognizing an IDE drive at bootup time (no matter what your drive settings, etc.), yet it is recognized by operating systems (both Linux and Windows) after you boot from the newer SATA drive.
If you remove the other non-SATA drives first, then Mepis installs OK using dual boot with Windows on a single drive with more than one partition. If you don't remove the older drives first, keep your XP Recovery disk handy (at least my Dell 8300). LOL
After trashing my MBR a few times (every time I tried to install MEPIS on this Dell, you can't load it from the boot menu), I found the following allows fast recovery if you do run into a problem. There may be easier ways, too.
Run Ramish Partition Manager from Ultimate Boot CD (search and you'll find it). After you boot, you'll find Ramish under the File System Menu Choices. Make sure your NTFS partition is bootable (it wasn't after my last Mepis install before I figured out that the other drives were causing it).
I personally avoid QTParted (my experience with it has not been good, with errors/problems trying to change partions with this Dell).
Ramish doesn't understand NTFS. But, it can make the partition bootable again.
Then, go to a Windows Recovery Console (boot from your Windows CD).
Log into your Windows under recovery console (hopefully, it will find it).
Run Fixmbr (this alone may not fix the problem when you get a NTLDR not found error after a Mepis install).
Run Fixboot (sometimes this won't fix the problem either).
Make a copy of your boot.ini (copy it to bootini.old or something) just to be safe.
Run bootcfg /rebuild and make sure your Windows install is there.
Reboot and Windows will load again (at least that works for me).
If none of the above works, try installing Suse 10.0. For some reason, it managed to get Windows working again on my wife's laptop after a Mepis install wouldn't let it load Windows after some kind of "fluke" with GRUB.
Of course, as you found out, just leave off the older drive and Mepis will install OK to your SATA boot drive without the need to "jump through hoops" trying to get your Windows working again. 
Jim C.
some good ideas
Posts: 38
Thanks for those ideas. I think GRUB does get confused when there is more than one disk, especially if they are not the same type. I should have removed the PATA disk before installing MEPIS on the SATA disk, and then reinserted it later. Of course who knew?
I can't check to see what the GRUB configuration file looks like, because I deleted the whole partition in one attempt to get the MBR to work.
Thanks for the pointer to Ramish and Ultimate Boot CD; I may try that if it happens again.
From googling around, it seems to me that one alternative would be to use NTLDR as the boot manager, rather than GRUB. If GRUB only installs itself onto the Linux root or, if separate, boot partition, not the MBR, then there should be a way for NTLDR to load it. (It involves using DD to grab that 512-byte boot record and copy it to the Windows partition, as a file named in boot.ini. I saw this hack on gentoo-wiki! With Gentoo, everything is done by hand.)
LILO is ugly but also seems to have an easier time coping with this sort of configuration.
You can also choose not to
Posts: 534
You can also choose not to install Grub to MBR, then install it to a floppy with grub-install '(fd0)', then, once the /boot/grub/menu.lst configuration is able to boot everything successfully from the floppy, install Grub to MBR of the first disk with grub-install '(hd0)'.
Floppy?
Posts: 38
I did stick my old floppy drive into my new computer -- funny how modern cases are silver/black and the floppy is a hint of the old beige -- though I'm slightly aghast at booting from it. I suppose, though, that it is safer than touching the MBR! And perhaps easier than mucking with dd to create an NTLDR image. Thanks for the insturctions how to do it. I hope the MEPIS installer doesn't force me to do something dangerous. I'm downloading the new MEPIS RC now, and I will hunt down 2.6.15 kernel sources too, so I can install the Ethernet drivers.
disk access auto -> LBA
Posts: 2299
I'm not really sure about this, but it might be an issue with the bios setting of the hard drive. I had a problem that windows would no longer boot after installing grub in mbr on a normal IDE drive. The fix was to change the BIOS disk access setting for the hard drive from auto to LBA.
Newbie or not Newbie, there's always a question
Normally, Mepis will install
Posts: 534
Normally, Mepis will install Grub to the MBR, as it did here. But it looks like the grub configuration in /boot/grub/menu.lst that Mepis wrote wasn't quite right for booting the Win partition, or there was some other problem. It's possible you may have been able to boot the Win partition manually from the Grub command line, with the right modifications to the commands in menu.lst. Or have booted back into Mepis and fixed menu.lst so that grub would properly boot windows. Would be interesting to see the menu.lst file that Mepis wrote in this instance. The problem could have to do with drive sequence, if the SATA drive is not seen by the BIOS as the first drive, because windows wants to boot off the first drive. If the SATA drive was the second drive, then these commands at the grub prompt may have made it boot:
root (hd1,0)
# or rootnoverify (hd1,0)
map (hd0) (hd1)
map (hd1) (hd0)
makeactive
chainloader +1
boot
The commands in menu.lst would be the same, except that the boot command isn't needed there, it's implicit at the end of a menu entry.