MBR changes in new build

I have an issue about this. I have regularly used a bootmanager ever since XP Pro's bootloader refused to recognize something as simple as my 98SE on an alternative drive. I got tired of drowning in $M Knowlege Bases that didn't provide a quick and reliable correction so turned to a bootloader (PARAGON's!) that could identify AND BOOT! "all" bootable systems on my PC.

Question now arises, new FD202 moves the pre-boot off the MBR, ok fine, but with the previous version where the preboot is located on the MBR, couldn't one just simply disable the FD preboot and still enjoy their third-party boot menu without issue? I mean you could still select other snapshots from the snapshot your booting to WITHOUT the preboot enabled right?

I just want to make things clear for myself about this, before i get too hasty and rush into something that has a potential for conflict. Right now i'm resting rather comfortably in created snaps (7) plus a few Archives here and there (off & on disk). I am totally & all of 100% amazed at this piece of work named FirstDefense so far and like to keep it this way.

 

i myself am also curious about the new changes with build 202- just got a new 320 gig and im wanting to dualboot ubuntu (vmware is fine but i dont have enough ram at this point). im wondering how the ubuntu bootloader will work with firstdefense

 

Personally, I prefer FDR to have priority of the MBR as it is by far the most important program for me. Any other program that upsets that is history for me.
I dont actually understand the need for a seperate boot loader as I thought that could be done using FDR snapshots and the pre-boot screen, but then I am not an expert and could be missing the point.

 

I see your point and hope you can see mine too.
I'm already in a dual-boot situation with 98SE (fat32) and hence necessary for the Paragon bootmanager to get me to 98 since XP Pro can't or won't

In this case, the snapshot wouldn't apply at all, just the neccessity of getting over to the other drive, thats all, and that's why i asked for clarification because to return the preboot after visiting the 98SE, i believe it would just be a simple matter to boot back by first uninstalling that bootloader then booting to the (committed snapshot), then access the Manage FirstDefense-ISR gui to re-enable the preboot again. I should test this myself and i will, but right now having too much interest in fashioning the snaps/archives to my liking.

 

Me interested too

Any users experimented with FDISR 202 and other boot managers yet?

Where does FDISR now load in the boot sequence?

As peter points out if you cant boot windows, where does that leave the "ISR" ?? Unless I'm misunderstanding this?

What is the real practical use for this change??

(another Vista conspiracy function ?? : change my fave to be 'compatible' with Vista boot loader but reduce my safety margin ??)

ANy insights appreciated.

regards.

 

In the linux thread I show you an example of a third party boot manager coexisting with FD-ISR's pre-os.

 

Presumably by changing the pre-boot hook, this means one can now use a defragger of choice without having to worry about excluding the $ISR.bin file, something which PerfectDisk did auto.

 

Why is that

 

Because originally you HAD to exclude that file before using any defragger, especially if they used a boot-time defrag. PerfectDisk was the only one AFAIK that excluded the file in its settings. If using other products, you had to set it yourself.

 

PerfectDisk excludes this file only :

C:\$ISR\0\$ISRBIN

That's the file, that needs to be EXCLUDED in other defraggers than PerfectDisk.

Not $ISR.BIN. This is one dot too many, which makes usually a big difference in the computer world.

 

What I mean is:
Please explain to me how moving the bootcode from the Master Boot Record to the Partition Boot Record makes a difference in finding the mentioned file?

 

My mistake, but my point still stands. Surely now the MBR isn't being used, there's no need for the exclusion.

 

No idea. I'm only going by what we had to do previously. If it applies to the PBR then that's all well and good.

Interestingly, Raxco seem to have removed the FAQ on using boot-time defraggers with FD-ISR. (http://www.raxco.com/support/windows/fdisr/fdisr_faqs.cfm) When there was an issue, their advice was the exclusion of the above file, but as said previously PD did it auto from a later build. Does this mean it doesn't apply now or are we still meant to exclude it?

Even Leapfrog have removed that advice from their FAQs: http://www.leapfrogsoftware.com/support_info/faq/

 

Well PerfectDisk8 is still excluding this file, so it's still valid in build 202 or else they forgot it.

 

Greetings,

Let me see if I can shed some light on this issue. I think it is best to first layout a definition of the MBR and the PBR

What is a Master Boot Record

The MBR is a small program that is executed when the computer boots up. Typically, the MBR resides on the first sector, sector 0, of the hard disk. The MBR program begins the boot process by looking up the partition table, also stored in the MBR sector, to determine which partition to use for booting. It then transfers program control to the boot sector of that partition, which continues the boot process.

What is a Partition Boot Record

The Partition, or Volume, Boot Record is also small program that is executed after the MBR during computer startup. The PBR resides within the partition. The PBR program continues the boot process by reading and accessing more sectors to determine the specific operating systems boot loader application. It then transfers program control to the boot loader, which continues the boot process.

The Windows Boot Strap Process

The Windows bootstrap process (skipping right to the MBR) is as follows:
1. The MBR is loaded, which contains the partition table, partition loader code, default boot partition.
2. The MBR is executed, which loads the PBR
3. The PBR is executed, which locates and executes a Windows system bootstrap file.
4. The Windows system bootstrap file is executed, and the boot process continues…

Note: Windows 2000/2003/XP and Windows Vista MBR’s are the same; however, the Partition Boot Records PBR’s are very different, but the concept of them is the same.

Ok with that being said, we got a lot of folks that wanted to concurrently use the various ISR technologies with boot managers, roll-back products, or other 3rd party apps that force use of the MBR. We also wanted to remove dependency from our MBR Backup and Recovery tool and allow the user to use the Microsoft Windows FixMBR and FixBoot commands (I am working on a quick guide that I will post at our website next week for those that have never used these Microsoft commands). We decided to move our interception code to the PBR. So with one of our ISR technologies installed the boot process is as follows:

The Windows Boot Strap Process with ISR Installed

The Windows bootstrap process (skipping right to the MBR) is as follows:
1. The MBR is loaded, which contains the partition table, partition loader code, default boot partition.
2. The MBR is executed, which loads the PBR
3. ISR pre-OS code is launched ($ISR.BIN). We do what needs to be done, then exit to #4.
4. The PBR is executed, which locates and executes a Windows system bootstrap file.
5. The Windows system bootstrap file is executed, and the boot process continues…

Q: Does this change the pre-OS $ISR.BIN code?
A: No, this does not change how our pre-OS code works, just adjusts where the point of interception is.

Q: Is my system more vulnerable?
A: No, in fact quite the opposite. We are now less susceptible to a 3rd party app overwriting our interception routine, and you can now use intrinsic Windows commands to repair your MBR and PBR.

Q: Do I still need to stop my de-frag application from moving $ISR.BIN.
A: It is still a good idea, but even if you don’t and the $ISR.BIN gets moved, the interception code will simply skip step #3 above and drop to #4. Your system will continue to boot and when the ISRService starts in the background, it checks the location of $ISR.BIN, and adjusts as necessary.

I hope this helps.

 

Hi, thanks for the explanation.

I have alomost never used these commands so that might be the reason that I feel to ask this Q. As I see PBR is executed after $ISR.BIN, so still it is safe to repair PBR or I should ask is there any point of repairing PBR( I mean FDISR will load repaired PBR or the previous pre-repair PBR)?

Thanks

 

Thank you for your clear explanation, Todd.

The reason why it helps that the $ISR.BIN file is not moved is:

the size of the MBR/PBR code is too limited to contain the intelligence that is needed in order to read the structure of the NTFS file system and find the file by itself.

To overcome this problem, the reference to that $ISR.BIN file (probably the first sector of that file?) is written in the MBR/PBR itself.
After you move the file, that reference becomes 'outdated'.

Hope it helps.

 

Copy/Paste!

Excellent and thanks also.

This is always been one of those very sensitive areas that can never get enough coverage IMO to being fully understood, and as vital as it is to successfully getting to the chosen/default GUI eventually, is sure is been one avenue of concern that escaped my own understanding of it completely enough.
Bootloaders have proven enormously beneficial with 98/Me - XP dual-boot set-up in my case and there are yet others who rely on them for the even more exotic boot sequences with Linux etc.

 

That is correct, Peter.

In the area of computer technology I have a strong drive to undestand the information to a detailed level.
(When it comes to cars, I don't care! )

Concerning your first point, would it be possible that the $ISR.BIN file isn't moved during a defragmentation? So, the message at boot time didn't show?
I mean 'not excluded' doesn't mean 'move by mandate', right?