Archived from groups: microsoft.public.windowsxp.hardware (
More info?)
"Gordon Airporte" <uce@ftc.gov> wrote in message
news:w56dndsIZolm5APcRVn-gQ@comcast.com...
>I have a drive with an NTFS primary partition with windows installed,
>and a FAT32 data partition. Currently GRUB is installed in the MBR so I
>can access Linux on a second harddrive. I want to move the Linux drive
>out, which means I'll be able to let Windows handle the booting.
> If I run fixmbr on the windows/data drive, will it lose track of the
> data partition, or will it work perfectly so I can boot windows
> directly and see everything on the disk?
> I think it will, but this always makes me nervous, so I'm checking
> first
🙂
FIXMBR (or "FDISK /MBR" for DOS) will write only into the bootstrap
program area (first 460 bytes) of the MBR (master boot record, and which
is not in any partition). It does NOT write the entire MBR (sector 0).
That means the partition table, wherever it is located in the MBR, is
untouched by these utilities. Only the bootstrap program area gets
overwritten to place a standard bootstrap program there. The standard
bootstrap program is hardcoded to expect the partition table to start at
a specific byte offset within the MBR and to be organized in a specific
structure.
If the MBR bootstrap got infected with a virus then the virus might have
moved the partition table or used a different structure. That means the
standard bootstrap program will still try to read from the standard
location for the partition table (which is now wrong because the virus
moved it) using the standard structure (which the virus might have
changed). I don't know if multiboot managers also alter the standard
offset for the partition table or its structure, but I would doubt it.
If a multiboot manager provides more features than available with the
standard bootstrap program, like allowing more than 4 primary
partitions, booting from a partition on a drive physically separate from
the partition table, then it might use the rest of track 0 for an
"extended" partition table and may even occupy the unused track 0 for
the remainder of its program code rather than requiring that code reside
in some partition.
You might want to save an image of your partitions so you can restore
them if the partition table gets screwed up (or the standard bootstrap
program cannot use the partition table or find it). Then you could
delete the partitions, recreate them (so the partition table and its
structure are at the standard offset and in the standard structure), and
then restore the image(s) to the partition(s). There are utilities
around that will let you save and restore the MBR (and can separate the
bootstrap program area from the partition table) but you'll have to know
what you are doing, especially if you screw up and end up having to use
a partition editor to fix the partition table.
If you've been infected with a bootstrap virus, using FIXMBR or "FDISK
/MBR" can result in losing your partitions. I don't know how GRUB
works. If it only resides wholly in the 460-byte bootstrap area of the
MBR and doesn't modify the offset or structure of the partition table
then there should be no problem in stepping on the 460-byte bootstrap
program area in the MBR to put a different [standard] bootstrap program
there. You might want to ask your Linux community what GRUB touches in
the MBR.
--
_________________________________________________________________
******** Post replies to newsgroup - Share with others ********
Email: lh_811newsATyahooDOTcom and append "=NEWS=" to Subject.
_________________________________________________________________
Facebook
Twitter
Instagram