Home AOMEI Products Support

Does OneKey usurp the MBR bootstrap code, add to BCD, or both?

From a pic of OneKey at http://www.aomeitech.com/forum/plugins/ameditor/js/php/upload/20160224/14562967648968.jpg, there are the options:


- Enable the boot menu.

- Add ... to Windows boot manager.


The 2nd option appears to add OneKey to the BCD of Windows to add another entry there.  I already have Windows 7 and Macrium Reflect listed there so presumably OneKey would get added as another selection there.  What I am most interested is the 1st option.  Does that mean in an MBR hardware config (which is what I have) that the 446-byte bootstrap section of the MBR get usurped (replaced) by OneKey's boot code?  Only one bootstrap program can be there so sometimes there is a conflict with who gets to be there.  For example, Acronis TrueImage has their bootstrap program that will usurp the MBR bootstrap area.  If OneKey does the same then I lose that Acronis' rescue method and have to revert to using their bootable CD.  

I may still decide to use OneKey but I need to plan on who gets to usurp the MBR bootstrap.  There have been boot managers that will chain multiple bootstrap programs (by using the unused first track containing the unassignable first sector used for the MBR); however, the vast majority of programs that usurp the MBR bootstrap are are corrosive in that they don't share and they do not chain themselves with whatever code was there before.


Often I try to read online documentation on a product before it gets installed.  Then I know what it does and how it works to determine if it will meld well into my current software configuration.  Nope, no online doc for OneKey.  Nothing available at http://www.backup-utility.com/help/index.html.  An online doc on OneKey might tell me what the first and second options do in the above dialog.  For example, I might decide to enable the 2nd option and have OneKey added as another entry in Windows BCD but not enable the 1st option because I already have a program that usurped the standard bootstrap code that used to be there.  Other info an online doc might tell me is where the OneKey partition could be stored.  Although external media is listed as supported, my recollection is OneKey wants its partition on the same disk as where is the MBR that has the partition tables and bootstrap code that the BIOS loaded into memory and to which it transferred control.  So I have to wonder why external media is listed as supported if the recovery partition cannot be there.  The pic of OneKey's dialog to which I linked has a timeout for the 1st option.  I understand that one as it decides how long to display the option when booting.  I don't understand why there is a timeout setting for the 2nd option.  How is that different than what the user configures in BCD to show its list of selections?  An online doc would probably answer many questions.


Comments

  • If I can add OneKey only to the BCD (to add it as another in the list of OSes to load) then I will use it that way rather than usurp the MBR's bootstrap area.  Hopefully OneKey lets me create bootable rescue media (and perhaps with WinPE to ensure it can read the partitions and device types versus a Linux boot CD).  Tough to tell how OneKey can be used without documentation available beforehand.

  • edited February 2016

    The bootable media of OneKeyRecovery is that of Backupper, it is PE. There is no OKR backup medium.

    Yes after you did the OKR backup, in the "gear wheel" options you can uncheck "Enable the boot menu". As far as i know it will restore the previous MBR, on a BIOS firmware. It will remove the bootloader from the firmware bootorder, on a UEFI firmware. And it is independent of the second checkbox, Windows Boot Manager (aka BCD).

  • OneKey isn't listed at http://www.backup-utility.com/help/index.html for online documentation.  However, I found some OneKey documentation at http://www.backup-utility.com/onekey/help/index.html.  Reading that now.

  • Oh, I was also looking at BackUpper but the free version does not have any storage capacity management (AOMEI calls it "Backup disk space management").  That is, when the backup destination is full then subsequent backups will fail (not enough free space) until the user gets around to deleting old backup chains.  Macrium Reflect Free lets me manage the backup location not directly by amount of free space (as does Acronis TrueImage payware) but does let me specify the retention for backups either by their age or by the count (of full and differential backups to keep).  I don't want to schedule backups and have them go merrily along until suddenly they fail without warning and only when I happen to look at the log would I see the failures.


    So I'll probably continue using Macrium Reflect Free which does have "Backup disk space management" and perhaps add OneKey to save a backup image into a hidden partition (much like Paragon's Backup Capsule and Acronis' Secure Zone) missing from Macrium Reflect Free.  I've used both Paragon's Backup Capsule and Acronis' SecureZone (similar because programmers left one company to go work for the other) and neither proved reliable for restores.  More than half the time the bootable rescue media (Linux or WinPE) would complain they could not find the backup location (hidden partition) or the restore would fail after awhile with some error about accessing the backup location.  It might take several times of starting a restore job or several restore jobs before I could get a restore to complete okay.  No problem if the backup files were on a non-hidden partition (i.e., one with a drive letter assignment).  Hopefully OneKey doesn't have the same problems trying to find, access, and read from the backup file stored in its hidden partition.



  • edited February 2016

    restore the partition exactly is not a problem for OKR or for Backupper. However see my #1

    Be careful, AOMEI Restore does its restore magic in a way that Windows
    first needs to repair the BCD and the firmware boot menu (verified on an UEFI firmware computer). A
    BIOS firmware computer restore would be less susceptible.


    There are certainly reasons that Windows has nearly abandoned system images (called now Windows 7 system image and quite hidden) and prefers to "refresh" the computer, that is re-install Windows including all updates up-to -before-30-days, keep user data, and throw out 3rd party programs. And there are reasons that backups of C: are so difficult (difficult to restore) such that all fill forum stories (except Macrium). I have to blame Microsoft for the incredibily troublesome mechanism about Windows booting and Windows Recovery, now vss is mastered.

  • edited February 2016

    "AOMEI Restore does its restore magic in a way that Windows first needs to repair the BCD and the firmware boot menu."


    I'm not sure that you mean that statement as a positive, like AOMEI makes sure drive letter assignments remain the same after a restore as they were before.


    Or you mean that statement as a negative, like AOMEI corrupts the BCD so the user has to use "bootrec /rebuildbcd" in Recovery Console mode to repair the BCD (and also may have to do something to repair the UEFI table).


    I certainly would not use a backup program, free or paid, whose restore function that corrupts the BCD and/or UEFI data that requires repairing that corruption.  I've been hunting around for your reported BCD/UEFI corruption issue (e.g., https://www.bing.com/search?q=aomei+restore+bcd+repair) but haven't found mention of it other than:


    http://support.fccps.cz/download/adv/frr/repair_BCD_on_EFI_partition.htm



    With UEFI, a crypto key (product key aka secure boot key) is assigned to the OS to make sure only that entry in the UEFI table can load only that instance of the OS; i.e., the bootstrap code gets locked down so malware cannot replace it.  Perhaps AOMEI is corrupting that product key or its hash with something within the Windows 8 install get out of sync (which still means AOMEI is corrupting the product key associated with the bootstrap code in UEFI).  I know that multi-boot users that want to use both Windows and Linux on the same host have to figure out how to bypass the product key so they can use their GRUB loader.


    Luckily I am still using Windows 7 and won't be upgrading to a later version of Windows (until Microsoft amends their rude behaviors in their licensing and Win10) plus I am still using a BIOS (MBR) hardware platform.  While UEFI was to eliminate some hardware limitations, like the maximum size of a partition, I don't need partitions to be larger than 2 TB.  I'll just add more disks or removable media to increase data storage.


  • edited February 2016

    dear potentialuser

    nothing gets corrupted, it is much easier, it goes as this.

    Every partition has its unique identification. It consists of (disk GUID, partition GUID) or (disk GUID, partition first LBA address), or (disk signature, partition first LBA address). These are the three ways of it, as far as I found. The unique identifications are used in UEFI firmware, BCD, and ReAgent and are used to tell where things are located in the computer: the Windows Boot Manager, the Windows Loader, the Windows Resume Loader, the Windows Recovery Environment.

    On any restore to the same disk, the partition GUIDs are surely new ones. The LBA's are the same, usually. On restore to a different disk, disk GUID/disk signature, partition GUIDs are different. LBA may be different. On a resize of partitions, partition GUID may be different and first LBA is usually the same.


    Example in UEFI firmware. The windows boot manager is located at

    (disk GUID, partition GUID, file path)

    {11111111-0000-0000-0000-5555555555} {11111111-2222-0000-0000-5555555555} \efi\microsoft\boot\bootmgfw.efi


    Example in ReAgent.XML. The recovery environment is located at

    (disk GUID, partition first LBA, folder path)

    {11111111-0000-0000-0000-5555555555} "129415249920" \Recovery\WindowsRe\

    (where 129415249920 is hex 1e21c00000, or around 130GB)

    The same recovery environment, in BCD, is located at

    (disk GUID, partition GUID, file path)

    {11111111-0000-0000-0000-5555555555} {11111111-2223-0000-0000-5555555555}

    \Recovery\WindowsRe\WinRE.wim


    These internal structures of Windows need be adjusted after restore, but recovery software restores them exactly as they were before and does not adjust. ReAgent is the most extreme of them, how should software know. The partition identifications are the only thing that needs be adjusted, everything else is fine. On MBR systems it is a bit easier, as partitions are by LBA, but disk signature may change.


    After a restore, UEFI firmware doesn't find the windows boot manager, for example. It therefore does a fallback boot from (where x64 is the architecture, could be ia32)

    (try all disks, efi system partition, \efi\boot\bootx64.efi  )


    As far as I know, but I'm not sure, AOMEI restore does adjust the entries in BCD it knows of, but does not adjust UEFI firmware.


    Hope this information helps.

Sign In or Register to comment.