On Sat, 27 Jan 2007 17:39:45 -0600, philo wrote:
>> I have read that if your drive is NTFS, that you must not use fdisk
>> /mbr and you must use fixmbr instead, as located on Win2k or later
>> install CDs. Otherwise dire consequences will occur.
>>
>> Any truth in this this, or is using the old fdisk /mbr on NTFS OK?
>>
> I have done it and it worked...
> but I don't recommend it as it could cause problems.
>
> I recently installed Win2k (NTFS) on a drive that had SUSE on it.
> Upon the first reboot.. the grub bootloader came up.
> Since it was a fresh install and I had nothing to lose...
> I tried fdisk /mbr from a win98 boot floppy, and all went well.
>
> The safe way is to boot from the CD and use the fixmbr command from the
> repair console
I just did a Google on this and have found nobody who ever had problems. There was one post about one of the security firms recommending not to use fdisk to get rid of viruses in the boot sector, but since I couldn't find the original article, I suspect that was because fdisk might not fully get rid of the virus, as opposed to damaging NTFS per se. (But see below.)
Microsoft itself said for Windows NT that you can use fdisk /mbr to fix the MBR, BUT ONLY if there was no virus infecting the MBR. So my guess is that this applies equally to 2000 and XP.
This Knowledgebase article describes the issues with regard to NT:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q166454
To quote:
"In Microsoft Windows NT, using the MS-DOS FDISK /MBR command is not always appropriate when you cannot boot a computer. The problem is that the command rewrites the master boot record (MBR) only, and not the entire boot record. The FDISK /MBR command rewrites only the first 446 bytes of the master boot record, not the partition table. Windows NT disk signatures used for fault tolerance are also overwritten, and if the drive contained an FT member, it may not be recognized by Windows NT as an FT member afterward.
If a drive is infected with a Stealth virus, the partition table and pointers have been offset. The offset pointer is contained in the MBR. Using the FDISK /MBR command on the computer refreshes the MBR--the
pointer to the partition table is lost, as is the ability to boot. The only possible solution is to reinfect the drive and then try to remove the virus again using Fdisk or anti-virus software.
The only time that the FDISK /MBR command is effective against a virus is if it is a boot-sector-only virus (such as the Stoned virus).
If the sector is infected, recovery cannot be guaranteed. If the FDISK /MBR command is used and a Stealth virus is present, the computer can most likely not be recovered because the offsets are not constant."
It's also possible that later versions of Windows expect certain bytes in the MBR to be thus-and-so and Fdisk may not always write it that way. This is a problem that Fedora Core 2 had with the new Linux 2.6 kernel and
parted. Windows XP and 2000 would not dual-boot after installing FC2. The Windows partition was undamaged, it was just that a couple bytes didn't have values that Windows expected. A one-line DD command reset those values and enabled Windows to boot again.
There ARE differences in Microsoft boot loaders, as this site explains fully:
http://www.geocities.com/thestarman3/asm/mbr/Win2kmbr.htm
But they also say:
"NOTE: Even though we're examining code created by a Microsoft Operating
System, this MBR can also be used to start the boot process for any
operating system's Boot Record on an x86-CPU based (PC) computer as long
as that OS is: 1) on the Primary Master hard drive, 2) set to be the only
Active partition and 3) it has a boot loader in the first sector of that
partition. The Linux OS can install LILO as a Boot Record rather than in
the MBR and following sectors, so even the oldest MBR by Microsoft could
still be used to boot that OS; as long as it was at or under the 1024
cylinder limit that is. Furthermore, the CPU itself must be an 80286 or
later, since some of the opcodes (see Code below) require that.
Windows NT/2000/XP can also boot multiple OSs using their “boot.ini” and
NTLDR files, so for systems with multiple OSs, that would be a more
practical approach than changing the Active partition in the MBR all the
time."