Preventing Windows installer from writing MBR

Most of the Linux installer includes a partitioner which lets you to choose between the location where the boot loader is to be installed during the time of installation, You can opt to set up GRUB on either the beginning of the physical disk(i.e. MBR) or the beginning of the beginning of the logical volume(i.e. VBR) leaving a scope to chainload it from other multi-boot loader without rewriting them. But this flexibility is missing in Windows installer where it overwrites any loader installed on MBR. That multi-boot loader needs to be installed again to get it to work properly. This is annoying. My question is, is there any way to prevent Windows installer from writing the MBR but VBR only?

I believe that the NTFS boot sector code is written when an NTFS filesystem is formatted; same for FAT.

I believe that MBR code is written when a disk is partitioned.

A disk filter driver could prevent writes to a disk's MBR.

I might recall having seen Microsoft articles which detail the order in which operating system must be installed, in order to support various multi-boot scenarios. If I recall this correctly, then it suggests that each MS OS' installation process assumes it owns the HDD... Anything else requires work-arounds. I could be mistaken.

I believe that the NTFS boot sector code is written when an NTFS filesystem is formatted; same for FAT.

Correct as you so far I believe.

I believe that MBR code is written when a disk is partitioned.

I do not. If you install Grub4DOS on the MBR of a partitioned HDD & then install Windows on an already created partition, Grub4DOS MBR is likely to be overwritten.

A disk filter driver could prevent writes to a disk's MBR.

Is there any way to use a filter driver while installing Windows XP?

I might recall having seen Microsoft articles which detail the order in which operating system must be installed, in order to support various multi-boot scenarios.

• Windows 98
• Windows XP
• Windows Vista/7
• Linux variants

Simply in the order of backward compatibility .

If I recall this correctly, then it suggests that each MS OS' installation process assumes it owns the HDD...

Means?

I do not. If you install Grub4DOS on the MBR of a partitioned HDD & then install Windows on an already created partition, Grub4DOS MBR is likely to be overwritten.

Correction:
It is SURE to happen.

If I may, you are making it more complicated than actually needed.
Save the stoopid MBR BEFORE installing Windows (make sure that it ALREADY contains a disk signature).
Install Windows.
Restore previous MBR.
Or, save just first 440 bytes of the MBR, install windows, restore the 440 bytes.


Wonko

If I may, you are making it more complicated than actually needed.
Save the stoopid MBR BEFORE installing Windows (make sure that it ALREADY contains a disk signature).

"Complication" is a relative term. To me, it's easier to install G4D once again than to backup MBR, possibly verify it to ensure consistency, put it away from the test environment & then again correctly restore it to the proper location.

"Complication" is a relative term. To me, it's easier to install G4D once again than to backup MBR, possibly verify it to ensure consistency, put it away from the test environment & then again correctly restore it to the proper location.

Sure, but that applies ONLY if you have a grub4dos installed and/or you plan to re-install it.
What I suggested is the PROPER way to do things, generally.
Compare with:
http://www.msfn.org/...d-not-be-found/

The advice is/was:
Whenever you are going to do *anything* that may potentially change the MBR, just §@ç#ing save a copy of it BEFORE.

ALWAYS better be safe than sorry.



Wonko

The advice is/was:
Whenever you are going to do *anything* that may potentially change the MBR, just §@ç#ing save a copy of it BEFORE.

If ensuring safety is the aim, then is it safer to backup MBR only? In general, only MBR is tampered during the installation of an OS, but to save the entire disk structure properly, I guess one needs to backup all the partition tables at the beginning of all the extended partitions. I'm saying so because my laptop contains a factory installed recovery partition which lies at the end of the 500GB HDD & a one click recovery button which, according to LENOVO forum guys, operates on the location of the recovery partition. It was reported there by one member that he had an image of the recovery partition, which he restored to a new partition after the HDD structure of his laptop *somehow* getting wiped out completely. But, in spite of the restoration being successful, the recovery button refused to work any more.

Look, if you want to be safe and ANYWAY you should have a backup (image) of the whole disk. (actually two of them, one stored away in another location)

If you are going to install an OS; the ONLY relevant things are those structure that WILL be changed (such as the MBR and the bootsector of the partitions), but of course the more meaningful data you save before making changes, the better.

What happened to that guy, WHY it happened and WHAT emedy there is for it is "a suffusion of yellow".


Wonko

Look, if you want to be safe and ANYWAY you should have a backup (image) of the whole disk. (actually two of them, one stored away in another location)

I don't have enough storage space to backup entire 500GB of HDD. But, do you know any tool to backup the entire HDD "structure" (not the data)? Because, the recovery key I'm talking about relies on the starting sector, as I've said earlier. JFYI, I've a couple of backups of that recovery partition kept in two different locations.

I don't have enough storage space to backup entire 500GB of HDD. But, do you know any tool to backup the entire HDD "structure" (not the data)? Because, the recovery key I'm talking about relies on the starting sector, as I've said earlier. JFYI, I've a couple of backups of that recovery partition kept in two different locations.

Not that I can remember, no.

You mean a tool capable of saving:

• MBR
• bootsectors of Primary partitions
• EPBR's (whole chain of it)
• bootsectors of logical volumes

right?

It would be a good exercise for you to write one.



Wonko

Not that I can remember, no.

You mean a tool capable of saving:

• MBR
• bootsectors of Primary partitions
• EPBR's (whole chain of it)
• bootsectors of logical volumes

right?

EXACTLY . Those who can't follow the term "EPBR" as Wonko has mentioned, it is nicely explained here.

I do not. If you install Grub4DOS on the MBR of a partitioned HDD & then install Windows on an already created partition, Grub4DOS MBR is likely to be overwritten.

I hadn't commented on whether or not Windows installation also does this, but I think that's what you were interested in.

The Initialize and Convert Disk Wizard in Microsoft Windows XP pops up for a blank disk, and must be run through as part of being able to partition the disk. I just verified that after completing this step, MBR code is written.

Is there any way to use a filter driver while installing Windows XP?

I would expect so. Drivers can be loaded with F6 during Windows XP installation, for example. Even a filter driver that only filtered the boot code portion of the MBR ought to accomplish your goal, it seems.

Means?

It makes sense that an end user expects that after installing Windows XP, they are able to boot that Windows XP. Perhaps the only "means" to guarantee that is for new MBR code to be written. Whatever code was there before the installation (such as GRUB4DOS) cannot be guaranteed by Microsoft to do the trick.

The Initialize and Convert Disk Wizard in Microsoft Windows XP pops up for a blank disk, and must be run through as part of being able to partition the disk. I just verified that after completing this step, MBR code is written.

Yes/No.
The "Initialize" is triggered by a missing 55AA Magic bytes:
http://reboot.pro/12253/
And this pertains ONLY to the "Disk Management" anyway.

The point is whether in the case of an ALREADY partitioned disk (and with ALREADY a Disk signature) and with ALREADY some MBR code, the latter is replaced during an INSTALL.
(and the answer is YES , ALWAYS)

If you prefer:
when a disk is accessed in Windows, its MBR must have:

• Magic bytes 55AA
• Disk Signature

If #1 is missing, the disk is initialized (and the MBR CODE is written)



if #2 is missing, only a new disk signature is written

When you install, no matter if:

• the disk has already been initialized or not
• the disk has been already partitioned or not
• the disk already has a disk dignature or not

the INSTALL process writes the MS MBR code, overwriting whatever code was there, ALWAYS.

As often happens, I lied , since a few days we do have a "queer" case when this didn't happen (but it wasn't the "normal" XP install anyway) :
http://www.msfn.org/...-after-install/


Wonko

UP.
Is there any ready-made filter driver or maybe some hack to grub4dos/firadisk tools setup to prevent Windows installer from overwriting the MBR?
I recall once there was an option in the older BIOSes to 'protect' the MBR from changes, but that also did prevented Windows from installing, and you had to disable the 'protection' before installing.
So I guess Windoze installer does not only writting the MBR, but reading it back to be sure what it had written. The filter driver has to handle that situation as well. Is there any out there?

some hack to grub4dos/firadisk tools setup to prevent Windows installer from overwriting the MBR?

Donate a virtual disk (hd0). MBR at (hd0) is written.
But core boot files (ntldr, boot.ini, ntdetect.com) are written to active partrition at (hd0). Prepare core boot files yourself.

Donate a virtual disk (hd0). MBR at (hd0) is written.
But core boot files (ntldr, boot.ini, ntdetect.com) are written to active partrition at (hd0). Prepare core boot files yourself.

I like this, it should be also cheap .


The files can be copied from (hd0) to the "real" drive, but when/how can it be done?
A copied BOOT.INI would need to be subjected to the (z-1) correction.
Or is there a way to add NTLDR/NTDETECT.COM/BOOT.INI in TXTSETUP.SIF so that they are copied "additionally" to the same "real" drive?

BUT if you have the install boot media actually booting grub4dos, it seems to me easier to boot from it and make a backup of the MBR beore starting the install (say to sector 62) then after text mode, reboot to the install media and restore the backup.


Wonko

The files can be copied from (hd0) to the "real" drive, but when/how can it be done?

This decision is up to the user. There are different choices.

First install to a logical partition and use a donate virtual disk: boot_xp.img
http://reboot.pro/15...post__p__137793

Booting is possible with grub4dos and boot_xp.img.
This can be the final solution, there is no need to copy files from (hd0) to the "real" drive.

Or boot XP, extract files from boot_xp.img.
Reconfigure boot configuration and adjust hidden sectors at partition boot sectors.
This depends at current situation, e.g. number of hard disks.
Or at BIOS possibilities (48 bit LBA and logical partition at end of big hard disk).

Or is there a way to add NTLDR/NTDETECT.COM/BOOT.INI in TXTSETUP.SIF so that they are copied "additionally" to the same "real" drive?

I don't know.

[WinntDirectories]
1 = "\"

It seems to be possible to copy NTLDR and NTDETECT.COM to root. But how to configure boot.ini?

BUT if you have the install boot media actually booting grub4dos, it seems to me easier to boot from it and make a backup of the MBR beore starting the install (say to sector 62) then after text mode, reboot to the install media and restore the backup.

Well, it's a user decision: should MBR changed at all?

It seems to be possible to copy NTLDR and NTDETECT.COM to root. But how to configure boot.ini?

Is it actually *needed* to "configure" it?
I mean if a BOOT.INI is copied to the root and it already contains some lines (example, NOT actually "thought upon" ):

multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Debug boot rDisk 0 partition 1" /fastdetect

multi(0)disk(0)rdisk(0)partition(2)WINDOWS="Debug boot rDisk 0 partition 2" /fastdetect



multi(0)disk(0)rdisk(1)partition(1)WINDOWS="Debug boot rDisk 1partition 1" /fastdetect

multi(0)disk(0)rdisk(1)partition(2)WINDOWS="Debug boot rDisk 1partition 2" /fastdetect

This should "remain" and the user should have the chore to choose the "right one" until the "installed XP" is up and running, and then *anything* can be run, like a batch or .vbs, or the BOOT.INI can be "fixed" manually.


Wonko

Is it actually *needed* to "configure" it?

Which timing does setup uses?
Are files copied first and boot.ini edited next?
Are files copied first and boot.ini edited next?

[WinntDirectories]
1 = "\"

False assumption, I've to correct
\ refers to %SystemRoot% in that case. Not to root directory.

[WinntDirectories]251 = \..
[SourceDisksFiles]
WinVBlk.INF = 1,,,,,,,251,0,0

results to: "could not create \windows\..." Yes, three dots.

Break. Bart did used

; winbom.ini=30000

A

WinVBlk.INF = 1,,,,,,,30000,0,0

fails still. 30000 is rejected by setup.

How to write to "%SystemRoot%\.." ?

I mean if a BOOT.INI is copied to the root and it already contains some lines (example, NOT actually "thought upon" )

That's a nice approach.

Contrary could be a dangerous approach. A existing boot.ini may be overwritten.
:

This should "remain" and the user should have the chore to choose the "right one" until the "installed XP" is up and running, and then *anything* can be run, like a batch or .vbs, or the BOOT.INI can be "fixed" manually.

Well, previous menthioned approach does finish XP installation. No need to fix.
System directories like \Windows and \Winnt does work.
A user may adjust boot environment in addition, fix boot.init manually or by a batch.

In non-English XP (namely Italian) there is a file, bootfont.bin, that is copied to root .
Snippets of TXTSETUP.SIF:

.....



[SystemPartitionFiles]

Bootfont.bin,""

....

[SourceDisksFiles]

.....

bootfont.bin = 1,,,,,,_x,1,3

Wonko

I've just tried to use whole partition as a separate (hd0) with map --in-situ (hd0,2)+1 (hd0) command, and grub4dos just created a duplicate HDD with original MBR (all three partitions I have) in it, which looks very nasty in windows setup.
Was it supposed to work like this?

I'll try to use trick with boot_xp.img later, to f#ing sick of it right now.

I'll try to use trick with boot_xp.img later

Can you clarify requirements?
Why do you like to keep MBR?
Which boot loader do you use?
Which partitions do you use? Primary, primary active, logical?
Do you use one, two or more hard disks?

In non-English XP (namely Italian) there is a file, bootfont.bin, that is copied to root .
Snippets of TXTSETUP.SIF:

[SystemPartitionFiles]

Bootfont.bin,"\"

....

[SourceDisksFiles]

.....

bootfont.bin = 1,,,,,,_x,1,3

http://gosh.msfn.org/txtsetup.htm How to read the SourceDisksFiles entry?

SystemPartition refers to system partition, primary active partiton at hd0. That's ntldr/boot.ini
Windows may reside at another partition. How to write to root of windows partition?

Break: what's current testing conditions?
Do we hunt two different approaches?

Break: what's current testing conditions?
Do we hunt two different approaches?

Right now I am not after *anything* specific, just throwing some ideas on the table and having a look at other people's (yours) ideas, I would call this "goalless brainstorming"

And yes, that should mean "system" (please read as "boot" ) partition, but that is where we actually want the three files NTLDR/NTDETECT.COM/BOOT.INI (I mean we don't want them on the logical volume - if we are having Windows on that one).
But I think I see what you mean , there is the risk that the "" is the donated hard disk active partition.

Some experiments are needed.

About syntax of [SourceDisksFiles] or more generally TXTSETUP.SIF, there is always some confusion (at least in my mind) with it, the best explanation/doc I could find are these:
http://www.msfn.org/...urcedisksnames/
http://www.msfn.org/...tinf-reference/
http://www.msfn.org/...etupsif-syntax/


Wonko